On Wed, Jan 10, 2018 at 10:39 AM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On Wed, Jan 10, 2018 at 11:24 AM, Gervase Markham via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > I don't think that's true. If your hosting provider allows other sites > > to respond to HTTP requests for your domain, there's a similar > > vulnerability in the HTTP-01 checker. One configuration where this can > > happen is when multiple sites share an IP but only one gets port 443 > > (i.e. the pre-SNI support situation), and it's not you. > > > > > There's a significant difference here. At a minimum the original request > arrives on port 80 and with a proper Host: header identifying the target > website to be validated. Yes, it's possible that your host redirects that, > but presumably you the website at that address have some say or control > over that. Furthermore, at a minimum the target being forwarded to still > has to have knowledge of a calculated challenge value to return to the > validator which the validator does not reveal in the process of raising the > question. A fact which arises from this is that the target was being > manipulated by the requestor of the validation -- a fact which some modes > of failure of the TLS-SNI-01 mechanism would not be able to assert. The > TLS-SNI-01 validation process never even surfaces to the hosting > infrastructure just exactly what domain label is being validated. > > Although the BRs allow method 6 to be performed over TLS, my understanding is that Let's Encrypt only supports the HTTP-01 mechanism on port 80 in order to prevent the exploit that Gerv described. Similarly, my understanding is that the updated TLS-SNI-02 mechanism prevents the attack that Matthew described. > > > Or, if an email provider allows people to claim any of the special email > > addresses, there's a similar vulnerability in email-based methods. > > > > Clearly those mechanisms have that well known risk for a very long time > now. Certainly, I have no doubt that one can still today bootstrap their > way to a bad certificate via these mechanisms. I note that LetsEncrypt > and ACME chose to eschew those methods. I admit to merely presuming that > those chose not to implement, at least in part, due to those risks. > > > > The "don't allow acme.invalid" mitigation is the easiest one to > > implement, but another perfectly good one would be "don't allow people > > to deploy certs for sites they don't own or control", or even "don't > > allow people to deploy certs for sites your other customers own or > > control". Put that way, that doesn't seem like an unreasonable > > requirement, does it? > > > > Here again, I think we have a problem. It's regarded as normal and > acceptable at many web host infrastructures to pre-stage sites for > domain-labels not yet in use to allow for development and test deployment. > Split horizon DNS or other in-browser or /etc/hosts, etc, are utilized to > direct the "dev and test browser" to the right infrastructure for the > pending label. It will be an uphill battle to get arbitrary web hosts to > implement any one of the mitigations you've set out. Especially when it > reduces a functionality some of their clients like and doesn't seem to get > them any tangible benefit. > > I agree with this point. It's common and by design for shared hosting environments to allow sites to exist without any sort of domain name validation. > In the course of adopting the 10 blessed methods, did any of the methods > move forward with the expectation that active effort on the part of non-CA > participants versus the status quo would be required in order to ensure the > continuing reliability of the method? > In my opinion, adoption of the 10 blessed methods was only an effort to document what CAs were already doing in practice so that the catch-all "any other method" could be removed. There is more work to be done, as can be seen in the current discussion of method #1 on the CAB Forum Public list. > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
