On Fri, Feb 23, 2018 at 01:17:53PM +0000, Doug Beattie wrote:
> I'm probably not understanding a key piece of technical info about the
> protocol, but when I see this statement it makes me think it has similar
> issues to tls-sni-01. If we're relying on the hosting provider enforcing
> certain constraints like this, then we're delegating a critical piece of
> domain control back to the hosting provider which would be a no-go.
>
> 4. Security Considerations
>
> The design of this challenges relies on some assumptions centered
> around how a server behaves during validation.
>
> The first assumption is that when a server is being used to serve
> content for multiple DNS names from a single IP address that it
> properly segregates control of those names to the users on the server
> that own them. This means that if User A registers Host A and User B
> registers Host B the server should not allow a TLS request using a
> SNI value for Host A that only User A should be able to serve that
> request. If the server allows User B to serve this request it allows
> them to illegitimately validate control of Host A to the ACME server.
>
> Please let me know what I'm missing.
The assumption that users can only influence HTTPS names they own
probably holds in practice. The entiere security of entiere methods 9
and 10 relies on exactly that. Exploiting TLS-SNI-0x did not require
answering for the name in question.
What I am more worried about is hosting providers which treat HTTP
and HTTPS independent from each other. These are not common, but there
are some. And judging from Globalsign ("oneclick") issue, either these
hosting provoders are relevant, or everyone just misunderstood the
issue.
-Ilari
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
