3 ms·

Sounds like the TLS-SNI-01 challenge that had a fatal flaw in some circumstances: https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-share

by kardos 7y ago

Sounds like the TLS-SNI-01 challenge that had a fatal flaw in some circumstances: https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996 https://community.letsencrypt.org/t/2018-01-09-issue-with-tl...

tialaramex 7y ago
The problem with tls-sni-01 is that it assumed nobody would be crazy enough to let you configure their HTTP-only web server to answer HTTPS requests for their names. So logically if a server answers HTTPS requests for a name, on an IP address that DNS says is the right address for that name, that must be the right server, no? But it turns out cheap bulk hosting sites, especially using Apache HTTPD often did this because it worked fine by default. The symptom for ordinary users would be you try to visit https://cat-videos.example/ https://cat-videos.example/ and it gives a certificate error saying the site has a certificate only for aaa-microwave-repairs.example do you want to continue? If you say "Yes" you get an error page. Eventually you remember it was http://cat-videos.example/ http://cat-videos.example/ no need for the 's' and that works. Weird but ultimately harmless. What has happened is the Microwave repairs people paid for working HTTPS, with a valid certificate for their name, the Cat Video people didn't bother. But both set the bulk hosting site as the correct IP address for their servers. Now, when you connect to that IP address and ask for cat-videos.example using SNI, the remote server should go "Er, no?" and you just get an error. But Apache's default behaviour instead figures you want the default web site and default certificate, which will typically be alphabetically first on that server. This destroys the security assumptions for tls-sni-01, because "it's safe unless people use cheap bulk hosting" is essentially identical to "it's not safe" and getting Apache to fix things was too late. Bad guys could sign up for a bulk host used by their target for non-TLS sites, and add a bogus site named like aaaaaaa.bad-guys.example and use this to attack the target with tls-sni-01 challenges. So, the replacement ACME challenge doesn't rely on SNI it uses ALPN instead. Also some people actually tested to check that Apache isn't also dumb enough to go "Um, I don't recognise this ALPN, I guess that means I should press on anyway and cause breakage" which fortunately it is not.
- drcongo 7y ago
  Excellent explainer, thanks.
- blattimwind 7y ago
  This kind of behaviour also enables DNS rebinding attacks. An nginx with a default_server returning "403 Get Lost" helps. (As does only allowing TLS).

by kardos 7y ago

tialaramex 7y ago

The problem with tls-sni-01 is that it assumed nobody would be crazy enough to let you configure their HTTP-only web server to answer HTTPS requests for their names. So logically if a server answers HTTPS requests for a name, on an IP address that DNS says is the right address for that name, that must be the right server, no? But it turns out cheap bulk hosting sites, especially using Apache HTTPD often did this because it worked fine by default. The symptom for ordinary users would be you try to visit https://cat-videos.example/ https://cat-videos.example/ and it gives a certificate error saying the site has a certificate only for aaa-microwave-repairs.example do you want to continue? If you say "Yes" you get an error page. Eventually you remember it was http://cat-videos.example/ http://cat-videos.example/ no need for the 's' and that works. Weird but ultimately harmless. What has happened is the Microwave repairs people paid for working HTTPS, with a valid certificate for their name, the Cat Video people didn't bother. But both set the bulk hosting site as the correct IP address for their servers. Now, when you connect to that IP address and ask for cat-videos.example using SNI, the remote server should go "Er, no?" and you just get an error. But Apache's default behaviour instead figures you want the default web site and default certificate, which will typically be alphabetically first on that server. This destroys the security assumptions for tls-sni-01, because "it's safe unless people use cheap bulk hosting" is essentially identical to "it's not safe" and getting Apache to fix things was too late. Bad guys could sign up for a bulk host used by their target for non-TLS sites, and add a bogus site named like aaaaaaa.bad-guys.example and use this to attack the target with tls-sni-01 challenges. So, the replacement ACME challenge doesn't rely on SNI it uses ALPN instead. Also some people actually tested to check that Apache isn't also dumb enough to go "Um, I don't recognise this ALPN, I guess that means I should press on anyway and cause breakage" which fortunately it is not.

drcongo 7y ago
Excellent explainer, thanks.
blattimwind 7y ago
This kind of behaviour also enables DNS rebinding attacks. An nginx with a default_server returning "403 Get Lost" helps. (As does only allowing TLS).