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 can’t 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

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

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).


Acme mailing list

Reply via email to