4 ms·
> 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
by 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]