I work on Let's Encrypt and Certbot and I'll offer the following summary for people who aren't familiar with the history of this.
TLS-SNI-01 is one of several validation methods for getting a Let's Encrypt certificate. It was originally the only method that worked on port 443 (other methods use port 80 or ask you to create DNS records).
In January 2018, Frans Rosén (the author of the article linked here) discovered that, on some shared hosting environments, one shared hosting customer could pass TLS-SNI-01 challenges for a different customer's domain. This problem only affects users of particular shared hosting services, but there was no apparent way that Let's Encrypt could get every shared hosting provider to fix this. (Let's Encrypt already knew about a related problem in a proposed-but-never-implemented validation method called HTTPS-01, but had missed the issue that Rosén discovered.)
Let's Encrypt then temporarily disabled TLS-SNI-01 entirely, and later allowed it for certificate renewals but not for initial issuance, as well as for specific hosting providers that had specifically confirmed that they were not affected by the vulnerability.
At the same time, the eventual deprecation of TLS-SNI-01 was announced.
In preparation for the deprecation, the Certbot client improved its support for HTTP-01 (the challenge that uses port 80), and, in recent releases, switched to preferring HTTP-01 over TLS-SNI-01 even if the certificate authority offers both. (Certbot originally preferred TLS-SNI-01 over HTTP-01.) This change means that recent renewals for people who have moderately up-to-date versions of Certbot will default to HTTP-01 and simulate what will happen after TLS-SNI-01 isn't available at all.
Recently, Let's Encrypt has also been e-mailing people who performed recent renewals using TLS-SNI-01 and warning them that this option is going to be eliminated permanently in March.
There is a newer validation method that works on port 443 called TLS-ALPN-01; this is supported by Let's Encrypt but not in Certbot. Some other clients do support it, although they may require that you shut down your web server temporarily.
Some people have been frustrated by this change because they have blocked port 80 entirely. Let's Encrypt has published a document noting that this isn't a good idea; in particular, it doesn't protect against active SSL stripping attacks.
Nothing related to the article or your response but I wanted to take a moment to say that as someone who is just getting started with learning Linux administration Certbot and Let's Encrypt made it stunningly easy to get SSL enabled for my site, your work and dedication is immensely appreciated!
I want to second this. With only a little effort initially, I've been able to have fully automated SSL-by-default for all of my "backyard hosting" customers, at no extra cost for them or for me. You folks are wonderful.
I'm adding my voice: Let's Encrypt and Certbot have made my life much easier. We manage somewhere around 100 websites where I work, and we were probably no more than 4 out 5 to monitor certificates, and renew them actively. It's a million times easier now.
Kindly convey my thanks too. You're the actual guys who are making web secure. Browsers just say, your site is not secure, but that doesnt help at all. Having cheap and easy way to solve problem, can only make it work.
Interestingly, many CAs are charging lot for certs. And lot of them don't know how to validate user's info. Many business guys just burn cash on certs told by CA's support team for 'security'.
I would also like to give thanks! I just use in on my home-hosted site for personal use, but it was such a breeze to set up. I could have used a self-generated cert but I feel this is much safer, and saves me from having to install the cert on every device.
Want to give out to https://traefik.io/ as one of the few reverse proxies that has full native support for TLS-ALPN-01. Easy way to add this in front of older servers, and it supports reading config from Consul, Redis, or even Docker/Kubernetes tags. Very nice product, it also supports DNS-01 validation for wildcard certs with many providers, unfortunately you have to set it to either DNS or ALPN mode, it can't choose which one to use based on context.
Is there somewhere in the Let's Encrypt documentation that lists what the supported methods are and what the requirements for using them are? I set up Let's Encrypt for a few somewhat bizarrely configured domains of mine, and I couldn't find anything at letsencrypt.org/docs that explained it.
IMO adding this type of documentation would be great. If I want to see what type of challenges there are, I don't want to browse through all the client choices and see what each of them supports. I want to know what Let's Encrypt supports and then pick a client that serves my needs.
It could be as simple as adding something explicit to the how-it-works page:
Let's Encrypt currently supports the following ACME mechanisms to validate your domain:
- HTTP-01: the Let's Encrypt client receives a challenge from Let's Encrypt and serves its response to the challenge at /.well-known/whatever on HTTP port 80 on each of the domains to be listed on the certificate. Let's Encrypt will load that URL to validate the request. This mechanism does not support wildcard certificates.
- TLS-ALPN-01: etc.
Something like this would have saved me about 45 minutes of fiddling around trying to figure out what I needed to do. I can't be the only person whose setup is more complicated than just a simple web server instance that I can blindly run certbot on. I had to make changes to my network, and I needed to know what changes to make.
If port 80 is open and there's been a mistake with cookie marking, then you can passively leak your critical cookies over an insecure connection. Having "seen this in real life", it's better to just not accept 80 to protect against developers making that mistake (along with other mitigation strategies).
If you have misconfigured cookies, having your server accept port 80 or not wont matter to a non-passive man-in-the-middle.
They will just accept port 80 traffic and read the cookies.
It's clear that there's a difference between an active and a passive attacker here. Closing port 80 protects against the passive attacker, but not against the active attacker (with regard to SSL stripping, insecure submission of old forms, and cookies not flagged as secure). Both kinds of attackers are real.
I just tested this and I was able to confirm your suggestion with Firefox, watching with a packet sniffer while connecting to my own site with http://example.com:443/ after previously setting a cookie over https://example.com/. The cookie was clearly visible in the packet log.
A friend of mine mentioned they got that email but we're not sure what specific cert it was for. I told him he must have missed that part of the email. Is there any chance you are sending those emails out without specifically identifying what certificate the email is for?
They resent the emails yesterday, or at least started to, which included the domains. I asked about this in the forums and they were pretty quick to agree it was a good idea.
>Recently, Let's Encrypt has also been e-mailing people who performed recent renewals using TLS-SNI-01 and warning them that this option is going to be eliminated permanently in March.
My ISP blocks port 80; I can't use HTTP-01. I'm forced to use DNS-01 which certbot won't automate for my DNS provider. Why can't webroot run optionally over https?
Years ago, an HTTPS-01 challenge was proposed that would have operated like HTTP-01 except using port 443. However, concerns were raised about the safety of this challenge.
I can't find the relevant discussion thread at the moment, but I believe this was because the default configuration in some shared hosting environments would have allowed users to receive certificates to others' websites.
PRs to add support for new DNS providers have been slow to merge, in part because the support story is complex[0].
However, plugins need not live in the main Certbot repository. Maintaining a plugin yourself may be the lowest-friction way to build one right now (or may have its own challenges; I haven't tried that approach).
Lexicon supports he.net[1] and Certbot provides a class for building Lexicon-based providers[2] with very little effort (although perhaps more effort and duplication than would be ideal[3][4]).
TLS-SNI-01 is one of several validation methods for getting a Let's Encrypt certificate. It was originally the only method that worked on port 443 (other methods use port 80 or ask you to create DNS records).
In January 2018, Frans Rosén (the author of the article linked here) discovered that, on some shared hosting environments, one shared hosting customer could pass TLS-SNI-01 challenges for a different customer's domain. This problem only affects users of particular shared hosting services, but there was no apparent way that Let's Encrypt could get every shared hosting provider to fix this. (Let's Encrypt already knew about a related problem in a proposed-but-never-implemented validation method called HTTPS-01, but had missed the issue that Rosén discovered.)
Let's Encrypt then temporarily disabled TLS-SNI-01 entirely, and later allowed it for certificate renewals but not for initial issuance, as well as for specific hosting providers that had specifically confirmed that they were not affected by the vulnerability.
At the same time, the eventual deprecation of TLS-SNI-01 was announced.
In preparation for the deprecation, the Certbot client improved its support for HTTP-01 (the challenge that uses port 80), and, in recent releases, switched to preferring HTTP-01 over TLS-SNI-01 even if the certificate authority offers both. (Certbot originally preferred TLS-SNI-01 over HTTP-01.) This change means that recent renewals for people who have moderately up-to-date versions of Certbot will default to HTTP-01 and simulate what will happen after TLS-SNI-01 isn't available at all.
Recently, Let's Encrypt has also been e-mailing people who performed recent renewals using TLS-SNI-01 and warning them that this option is going to be eliminated permanently in March.
There is a newer validation method that works on port 443 called TLS-ALPN-01; this is supported by Let's Encrypt but not in Certbot. Some other clients do support it, although they may require that you shut down your web server temporarily.
https://community.letsencrypt.org/t/which-client-support-tls...
Some people have been frustrated by this change because they have blocked port 80 entirely. Let's Encrypt has published a document noting that this isn't a good idea; in particular, it doesn't protect against active SSL stripping attacks.
https://letsencrypt.org/docs/allow-port-80/