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. > 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. 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? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
