On Fri, Feb 23, 2018 at 03:04:46PM +0000, Doug Beattie wrote: > > Oh yes, right. The scope of attack is only those domains that point to the > same IP address. But, this still relies on web hosting companies to have > secure configurations such that User A cant get a cert for user B's domain > when they share the same IP address. > > As a CA I like this and would be able to get method 9 added back, but it > still has a dependency that the web hosting company is doing the right > thing, and that might be a concern (we'd be depending on a web server > configuration to enforce accurate domain validation).
Assuming that: - The hosting provoder has dependent HTTP and HTTPS (most do). - The hosting provoder supports sharing IP addresses between customers with HTTPS enabled, or maps each customer to dedicated address (AFAIK, all nowadays do either of these). - The hosting provoder is not vulernable to unauthorized certificate replacements (which is fundamentally exploitable for Denial of Service). Then this mechanism is secure against misvalidation. These two conditions are not sufficient for TLS-SNI-0x, because this method also requires assumption that the attacker can not claim arbitrary names. However, there are some provoders with indepedent HTTP and HTTPS. For example, the first provoder from the TLS-SNI misvalidation blogpost (which was not identified, and has probably fixed this already). Names hosted by these provoders can be attacked if the legimate owner does not have HTTPS set up. Specifically: Claim the name and then just validate it using some method related to HTTPS, the hosting provoder thinks it is yours. One can notice that the definition of method 6 has no provisions to not be vulernable in such context (method 6 is also vulernable to misvalidation if the victim has set up HTTPS but not HTTP). -Ilari _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
