On Thu, Jan 11, 2018 at 2:46 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On 11/01/2018 01:08, Ryan Sleevi wrote: > > On Wed, Jan 10, 2018 at 6:35 PM, Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > >> > >> Agree. > >> > >> Hence my suggestion that TLS-SNI-0next use a name under the customer's > >> domain (such as the name used for DNS-01), not a name under .invalid. > > > > > > I thought it had been pointed out, but that doesn't actually address the > > vulnerability. It presumes a hierarchal nature of certificate/account > > management that simply does not align with how the real world and how > real > > providers work. > > > > There are TWO related vulnerabilities at work here: > > 1. A lot of hosting providers allow users to provision certificates for > whatever.acme.invalid on SNI capable hosts, even though those users > are not owners of whatever domain was issued a challenge for the > number in the "whatever" part. Other than adding code to specifically > block "acme.invalid" to every software stack/configuration used by > hosting providers, this is almost unsolvable at the host provider end, > thus it may be easier to change the TLS-SNI-xx method in some way. > > 2. A much smaller group of hosting providers allow users to set up > hosting for subdomains of domains already provisioned for other users > (e.g. user B setting up hosting for whatever.acme.example.com when > user A is already using the host for example.com). This case is not > solved by changing the SNI challenge to be a subdomain of the domain > being validated. But since this is a smaller population of hosting > providers, getting them to at least enforce that the parent domain > user needs to authorize which other users can host a subdomain with > them is much more tractable, especially as it has obvious direct > security benefits outside the ACME context. This is categorically false. It is, itself, more complex, more error prone, and more complexity (for example, due to the nature of authorization domains) and that, at the end of the day, fails to achieve its goals. The simplest way I can try to get you to think about it is to consider a cert for foo.bar.example.com being requested by Iser C, and preexisting domains of www.example.com (User A) and example.com (Iser B). Think about how that would be “checked” - or even simply who the authorizors should be. I assure you, it both fails to address the problem (of limiting risk) and increases the complexity. Put simply, it doesn’t work - so there is no value in doubling down trying to make it work, especially given that it also fails to provide a solution for the overall population (like blacklisting does). Finally, the assumption there will be fewer of X so it’s easier to fix is, also, counterintuitively false - the fewer there are and the more baroque and complex the solution is, the harder it is to make any assumption about adoption uptake. (Hosting providers who allow uploading certificates for the specific > DNS/SNI names of other users are a security problem in itself, as it > could allow e.g. uploading an untrusted exact domain cert to disrupt > another user's site having only a wildcard certificate). Not really. You say this but that is the reality today and can and is mitigated. On the other hand, such providers will often (included or at extra fee) > allow provisioning arbitrary subdomains that are then typically added to > the HTTP(S) vhost configuration and the hosted DNS configuration, which > is good enough for TLS-SNI-modified-to-use-subdomain and HTTP-01, but > won't allow users to respond to the DNS-01 and may or may not allow or > users to respond to TLS-SNI-01 challenges (the feature allowing > responding to TLS-SNI-01 challenges is likely to suffer from security > issue #1). The problem in your thinking, which I wasn’t clear enough about I suppose, is that those use cases are already met by other validation means and there’s no assumption nor need for TLS-SNI, and while you pose your solution as an improvement, in no way makes it easier or more widespread, and simply limits what it can do and overlaps with other methods. In any event, I think if you want to continue to explore that line of thinking, you’re more than free to within the IETF, where you can learn more directly about the requirements rather than construct hypothetical environments. Just reread RFC7301. While it does say that servers SHALL reject such > connections (or at least not send back an ALPN indicating a selected > value, as if not implementing the extension), I find it likely that some > combinations of TLS implementation and application implementation will > blindly accept whatever unknown protocol identifier a client lists as > the only option. That is completely unproductive speculative strawmanning that doesn’t allow for productive dialog. More specifically, I do not think it all useful for this Forum for the “if I was king, and we assume it works like x, here’s what I would do” is actually at all productive or appropriate. The right venue would be ACME if you wanted to discuss designs, and what is relevant here and appropriate is merely a critical evaluation of comparative risk to _what the Baselines permit_. “I think we shouldn’t allow X, because it introduces condition Y, where if met would result in Z, and that is new and unique to this method” is useful. > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
