Chicken-or-egg on port 443 vs 80 on challenge

Help
21

Apache mod_md supports TLS-ALPN-01.

4 Likes
22

That page is stale. Apache has supported TLS-ALPN in its built-in ACME module mod_md since Apache v2.4.30 (like 6 years ago).

The ACME Client lego supports it. I am sure there are others. It is not rare.

First, Let's Encrypt does not require port 80. It also supports TLS-ALPN and DNS Challenges. It is up to you to choose an ACME Client that can do the things you need.

You should review the reply by Aaron Gable and the link to the RFC. Those are the specs for the ACME protocol. It is not decided by Let's Encrypt but by the CA/Browser members and community at large. The RFC link described why standard HTTPS was not included in the spec for the HTTP Challenge.

They could not. It is not allowed by the ACME spec.

7 Likes
23

As others stated, this is not allowed due the RFC and the CA/B Forum Baseline Requirements.

The reason for this, is because there is a known Security Risk. The TLS-SNI-01 method was deprecated in January 2018, and entirely removed in March 2019. See:

TLS-ALPN-01 was specifically designed to allow HTTPS only authorization, and works around the known security risks.

The common ways to handle your situation (in descending order or popularlty) are to use HTTP-01 and redirect or proxy the port-80 traffic, utilize DNS-01, or utilize TLS-ALPN-01.

5 Likes
24

You know, I am not disagreeing with the arguments here regarding ACME requiring the use of port 80 (@Kurt, that is not changing, you're gonna have to suck it up on that one and either fix port 80 or use another challenge type), but saying that the RFC describes why HTTPS was not included is a bit ... well, "misleading" is the best word I can come up with.

I have read my fair share of RFCs, and they are really intended to define a protocol completely to insure interoperability. They don't always go into an exhaustive backstory about why particular technical decisions are chosen, and to be fair that isn't their job. A lot of time that explanation happens on the working group mailing lists, but wading through THOSE many times feels like trying to cure a headache by self-administration of a sledgehammer.

In this specific instance, as far as I can tell the explanation given here consists of a single sentence, from §8.3 of RFC 8555:

And I will freely admit that I don't quite understand that sentence! I mean, yeah, it consists of words in the English language and they're all arranged in the correct order to make a grammatically consistent sentence, the actual MEANING eludes me. The part about "particular low-privilege tenant user in a subtle and non-intuitive manner" is the particular sticking point for me. You could read it as, "We require the use of port 80 because the Apache documentation sucks and many hosting companies don't understand it", which seems like a lousy reason to limit things to port 80.

Considering the experience level of the people involved with the ACME specification, I am 100% confident that the reasons that HTTP-01 is limited to port 80 are well thought out. More to the point, I personally don't really care that much and I'm not that invested into this to dig up the complete technical backstory. But saying that RFC 8555 explains why things are this way isn't quite fair.

1 Like
25

That is accurate.

The technical backstory is in the two links I provided in the comment above yours.

The reason why this is only a single sentence, is the RFC Drafts previously contained a section on TLS-SNI-01 (HTTPS) authorization. This last appeared in draft 09 (December 2017) and was removed in draft 10 (March 2018) after the January 2018 security disclosure. There were 18 public drafts before the RFC was finalized, so they basically removed one section and did a brief comment as to why the challenge must be completed over HTTP and not HTTPS. The process to fully iron out and implement a replacement was expected to take some time, so they finalized RFC 8555 as it was secure and comlpete, and started RFC 8737 to implement a custom ALPN protocol during the TLS handshake. That's why there is no TLS option in 8555, even though an extension was immediately developed and deployed prior to the finalization of both RFCs.

3 Likes
26

Thanks! However ... I hate to be a nitpicker but the timeline doesn't QUITE match up.

Respectfully, that is not my read of the draft history.

Specifically, draft-00 included a simpleHttp validation protocol (see §7.1) that could run over port 80 or port 443, depending on what the ACME client choose. This was replaced in draft-01 with http-01 (§7.2) and tls-sni-01 (§7.3) plus other verification protocols. It was at this point that the sentence I referenced earlier was inserted into the draft and it looks like it remained unchanged to the final issuance of the RFC. draft-01 was published in 2015, way before any of the security issues with the SNI-based protocols were discovered. So clearly there was some issue discovered with simpleHttp and that led to the creation of tls-sni-01, but the exact issue was clearly something other than the issues discovered in 2018. It's entirely possible that it is RELATED to the issues with tls-sni-01, but that's not clear to me given the above information.

1 Like