Currently Let's Encrypt acme challenges arrive on HTTP port 80. Many sites do not want to open port 80 at all whatsoever for security reasons. What is the possibility of using HTTPS port 443 for challenges if no connection can be made by HTTP?
1 Like
Welcome to the Let's Encrypt Community, Rob 
4 Likes
You can use a TLS-ALPN-01 challenge if you prefer using port 443.
8 Likes
Opening port 80 is not a security risk - it's the thing that's listening on port 80 that's the potential risk.
My own preference is to use DNS validation if port 80 can't be used but keep in mind there is generally no requirement to run a webserver on port 80 just for http validation, many/most acme clients can run their own temporary "standalone" validation server.
6 Likes
This is by definition a misconception.
There is negligible security benefit from blocking port 80 [inbound].
Everything that can be accessed via HTTP can be accessed via HTTPS, so "security" is essentially equal from that perspective. Block HTTP and they can still access the exact same "flaws" via HTTPS.
I do understand that some ISPs block port 80 [beats me why].
And in those cases, DNS-01 or, as @maxh pointed out, TLS-ALPN-01 (which uses port 443) can be used.
7 Likes
Agreed. I think it's highly unlikely that the port 80 code has some exploitable bug which would not be exploitable using HTTPS. It's probably the other way around: the TLS code has a bug which can potentially be exploited, while the non-TLS (i.e.: port 80) does not have that bug.
So I would urge to those "Many sites" where OP refers to, to educate themselves better.
8 Likes
To answer this a bit more directly than the others:
-
LetsEncrypt removed the TLS-SNI-01 ACME Challenge Mechanism in 2019 because it was insecure and could lead to the mis-issuance of tickets, especially in shared hosting scenarios. see March 13, 2019: End-of-Life for All TLS-SNI-01 Validation Support
-
As @Maxh stated, you can use the TLS-ALPN-01 challenge to verify over HTTPS - however it is a technically more advanced challenge for webservers to implement, and therefore most webservers do not, or can not, support it.
Because of those two situations, there is essentially zero chance of a more accessible HTTPS verification challenge in the foreseeable future. Everyone supports the idea, but there are technical and security restraints that are preventing it from happening in a method other than TLS-APLN-01.
If your concerns are over having to manage another service and you do not want to run port 80 all the time, you can use the pre/post hooks in certbot - or other clients - to only turn on Port80 during the ACME process. You can also choose to have Certbot handle the port80 responses via the included "standalone" option, proxy that traffic to your https server, or serve a redirect to your https server.
5 Likes
Unless your domain is on the HSTS preload list (to which I provided a link above), whenever someone types/pastes/whatevers your domain name into the address box of most standard browsers without specifying HTTPS as the protocol, the default protocol that will be used is HTTP. If you keep port 80 closed and service public requests, you present a broken service to your visitors and murder your search engine ranking.
3 Likes
Well, browsers are working on moving to checking https by default, and only falling back to http if https isn't working.
6 Likes
Hi @rrip!, and welcome to the forum!
The other piece that hasn't been mentioned here is that Let's Encrypt cannot initiate the HTTP-01 validation connection directly to port 443. This behavior is standardized by RFC 8555, Section 8.3, which states:
This request MUST be sent to TCP port 80 on the HTTP server.
While it is possible (and common!) for that initial request to result in a 3XX status code which redirects to an HTTPS URI, the initial connection is required to be on port 80.
10 Likes
Why is that actually? What's wrong with a http-01 challenge actually using HTTPS on port 443? If a redirect is allowed, connecting directly using HTTPS should be fine to, right?
4 Likes
I imagine you will end up encountering TLS-SNI-type issues again, unless you also require certificate validation.
4 Likes
Also, I don't think Boulder remembers if you served an HSTS header on a verification. That could be a way to tell it to use port 443 (but... how do you tell it to go back to 80?)
3 Likes
Why wouldn't that be an issue when it's after a redirect?
4 Likes
Imagine a shared server with 1000 virtual hosts.
One of those (under httpd's and nginx's default behaviors) gets to be the default non-SNI virtual host.
If one was able to trigger an http-01 challenge directly on port 443 for any of those domains, then the lucky tenant who is the default SSL virtual host, would be able to complete the challenge for any of those 999 other domains. (Or rather, the proportion of those 999 domains that don't have certificates yet).
In the case of a redirect, the user has to intentionally shoot themselves in the foot first.
7 Likes
That also applies to port 80, if you point a random domain to that machine.
The default virtualhost is a problem, but I'm not sure it's our problem.
3 Likes
To me, it's a chicken-and-egg problem. If one could request a specific protocol to be used for validation then it might be possible. Remembering that there might not yet exist a valid certificate for the domain name being validated (because the upcoming validation is bootstrapping the certificate), it seems unreasonable to me to default to HTTPS when there often might not yet be a webserver serving port 443 at all.
Our implementation of the HTTP-01 challenge follows redirects, up to 10 redirects deep. It only accepts redirects to “http:” or “https:”, and only to ports 80 or 443. It does not accept redirects to IP addresses. When redirected to an HTTPS URL, it does not validate certificates (since this challenge is intended to bootstrap valid certificates, it may encounter self-signed or expired certificates along the way).
4 Likes
I understand the first part, but the latter (quoted) part is still a little bit too vague for me. Do you mean a manually inserted redirect would mean it's the users fault if there is a redirect without a working HTTPS virtualhost?
If a user manually would request the http-01 challenge over HTTPS, isn't that sort of the same?
4 Likes
Yes. They have effectively delegated their domain to whatever website is sitting on the default SSL vhost.
Well, any random person could create a new order and choose the "https-01 challenge", doing an end-run around port 80.
It is assuming that the HTTP response which is received on port 443 for that domain, is from the same website. This is not a safe assumption, as far as I can tell.
6 Likes
Hm, that's true. But that's also true for any non-configured HTTP site with the A/AAAA record pointing to a certain server. Although you could argue it's the users fault they have their DNS pointing to an incorrectly configured server.
That said, we can put the blame for any exploitable misconfiguration on the user and with that sweep these issues under the rug. But IMO it's a grey area. Where can we blame the user for exploitable configurations and keep using those potentially exploitable challenges and where do we stop blaming the user and not use a certain potentially exploitable challenge? Grey area.
4 Likes