On Wed, Jan 10, 2018 at 4:37 PM, Matthew Hardeman <mharde...@gmail.com> wrote: > > In the exact text above, what I meant by "create the proper zone in > .acme.invalid" was to create that web hosting context (or actually set of > web hosting contexts) and bind to the Host names that are the > z(i)[0...32].z(i)[33...64].acme.invalid labels that the attacker knows to > be the set of those which may arrive in the TLS SNI name values for the > validation calls from the CA to the TLS infrastructure. I clarify again > that I'm not speaking of any real DNS mapping at all. I'm speaking of a > mapping between a received TLS SNI label to a web hosting context on the > hosting infrastructure. >
Got it. Yes, a large number of web hosting providers allow for potentially binding names not yet bound to DNS. This becomes an issue iff they share the same IP (which is a far more varied story) and they allow control over the SNI<->certificate mapping (which is also far more variable). So the lack of a binding to a 'real' name in and of itself is not an issue, merely the confluence of things. > If this is the case, I can only conclude that all presently proposed > enhancements to TLS-SNI-01 and TLS-SNI-02 validation, including my own > rough sketch recommendations, are deficient for improvement of security and > all of these TLS-SNI validation mechanisms are materially less secure and > less useful than the other ACME methods that Let's Encrypt presently > implements. > Note that the presumptive discussion re: .well-known has ignored that the Host header requirements are underspecified, thus the fundamental issue still exists for that too. That said, there absolutely has been both tension regarding and concern over the use of file-based or certificate-based proofs of control, rather than DNS-based proofs. This is a complex tradeoff though - unquestionably, the ability to use the certificate-based proof has greatly expanded the ease in which to get a certificate, and for the vast majority of those certificates, this is not at all a security issue. I think the apt comparison is about introducing a 'new' reserved e-mail address, in addition to the ones already in the Baseline Requirements. The conversation being held now is a natural consequence of removing the 'any other' method and performing more rigorous examination of the application in practice. For comparison of "What could be worse", you could imagine a CA using the .10 method to assert the Random Value (which, unlike .7, is not bounded in its validity) is expressed via the serial number. In this case, a CA could validate a request and issue a certificate. Then, every 3 years (or 2 years starting later this year), connect to the host, see that it's serving their previously issued certificate, assert that the "Serial Number" constitutes the Random Value, and perform no other authorization checks beyond that. In a sense, fully removing any reasonable assertion that the domain holder has authorized (by proof of acceptance) the issuance. > All the recommendations and guidance in the world is unlikely to timely > change the various (and there are so many) hosting providers' behavior with > regards to allowing creating of web hosting contexts for labels like > "*.*.acme.invalid". The CAs are beholden to the CABforum and root > programs. The various web hosts are not. > Agreed; although, pragmatically, I hope that the visibility of the issue, and the excellent documentation provided by Let's Encrypt, may allow us the opportunity to provide a graceful transition into a more robust implementation and a more restrictive version of .10 over the coming months. > That being the case, I would recommend that the proper change to the > TLS-SNI-0X mechanisms at the IEFT level would be the hasty discontinuance > of those mechanisms. > I'm not sure I agree that haste is advisable or desirable, but I'm still evaluating. At the core, we're debating whether something should be opt-out by default (which blacklisting .invalid is essentially doing) or opt-in. An opt-in mechanism cannot be signaled in-band within the certificate, but may be signalable in-band to the TLS termination, such as via a TLS extension or via the use of an ALPN protocol identifier (such as "acme"). End-users (e.g. those who are not cloud) with full-stack control of their TLS termination can 'simply' add the "acme" ALPN advertisement to signal their configuration. Cloud providers that provide a degree of segmentation and isolation can similarly allow the "acme" ALPN protocol to be negotiated, and complete the enrollment (either themselves, as some providers do, or allowing their customers to do so) Providers in that proverbial 'long tail' that don't update to explicitly advertise the TLS extension or ALPN identifier (or equivalent TLS handshake signal) would otherwise fail the ACME challenge, since it wouldn't be clear that it was safe to do so. As long as the web hosting infrastructure does not automatically create new > contexts for heretofore never seen labels, it won't be possible to fully > validate in an automated fashion whether or not a given hosting > infrastructure would or would not allow any random customer to create some > blah.blah.acme.invalid label and bind it to a certificate that said random > customer controls. Because of the various incentives and motivations, it > seems almost inevitable that it would eventually occur. When a > mis-issuance arises resulting from that scenario, I wonder how the > community would view that? > I'm not sure I'd classify it as misissuance, no more than those who were able to get certificates by registering mailboxes such as 'hostmaster' or 'webmaster' on free email providers (despite the RFC's that reserve such names). While I admit that .invalid (and needing to blacklist) is unquestionably a backwards-incompatible change to the 'real world' and, unfortunately, did not turn out to be as safe as presumed, the method remains itself in the BRs, and as the example showed, can be creatively used (or is it abused?) while fully complying with the BRs. Much in the same way a cloud provider that allowed unrestricted access to .well-known across hosting accounts, or web messaging boards that allowed direct file upload into .well-known, at some point, we need to acknowledge that what happened was fully permissible, question whether or not it was documented/acknowledged as risky (which both the TLS-SNI and .well-known files are called out as such, in the ACME draft), and what steps the CA took to assuage, mitigate, or minimize those risks. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
