4 ms·
Interesting, definitely looking forward to the details, and great to see Let's Encrypt react this quickly even though this might cause a small amount of disrupt
by pfg 9y ago
Interesting, definitely looking forward to the details, and great to see Let's Encrypt react this quickly even though this might cause a small amount of disruption to users.
The latest ACME draft - mostly referred to as what will become ACME v2, which Let's Encrypt supports on the staging environment as of a few days ago - has a slightly revamped version of the TLS challenge (tls-sni-02). The TLS-SNI challenge works roughly like this: The validation (CA) server sends a "fake" SNI hostname, generated by the CA server, to the IP behind the domain the CA is trying to validate. Domain control is assumed to be given if the server responds with a certificate that contains the CA-generated hostname in its SAN extension (where certificates store the domains and other identifiers they're valid for).
One of the concerns people had with tls-sni-01 is that it made it possible for a TLS server to "solve" such a challenge by effectively echoing back the requested SNI value blindly. This was changed in tls-sni-02 - just taking the SNI value and putting it in the SAN field is no longer enough to pass such a challenge. Until now, there was no reason to believe anyone was running TLS servers that showed this behaviour, so the was no real rush to deprecate tls-sni-01 right away (as opposed to just rolling out ACME v2, which only has tls-sni-02). I wonder if someone's found a lot of TLS servers that turned out to do this, or if there's some other vulnerability in the design or implementation.
- regecks 9y ago> TLS server to "solve" such a challenge by effectively echoing back the requested SNI value blindly I would be mildly surprised if they pulled tls-sni because of this, since it is basically a client vulnerability, and both http-01 and dns-01 suffer from similar scenarios (e.g. I tricked a major email provider into serving /.well-known/acme-challenge/ for a domain I shouldn't have been able to, and a friend managed to get a wildcard for a ccTLD).
- pfg 9y agoI think we're talking about slightly different scenarios. HTTP-01, for example, cannot be solved by just echoing back the file name the validation server requests because the client is supposed to return "token || '.' || base64(JWK_Thumbprint(accountKey))", but the file name is just "token". dns-01 is not affected either because the requested label is always just "_acme-challenge.<FQDN>".
- regecks 9y agoAny links to discussions on this topic? Sounds suspiciously like SNI proxies.
- pfg 9y agoI'm not aware of any public discussion of the ongoing incident. This[1] is the thread on the ACME WG mailing list that lead to tls-sni-02 being introduced. [1]: https://mailarchive.ietf.org/arch/msg/acme/s8gaZ6ev-iqoSQjOZWUpZ41mA0M https://mailarchive.ietf.org/arch/msg/acme/s8gaZ6ev-iqoSQjOZ...
- AdamJacobMuller 9y agoThe best way of explaining tls-sni-01 is that its broken such that it allows the user to shoot themselves in the foot in a bad way. When I wrote an implementation of LE with tls-sni-01 I was quite shocked that it worked that way when dns and HTTP were done "correctly". I would be very surprised if this was related to their reason for pulling tls-sni-01.
- deleted 9y ago[deleted]