[hannob]

Can anyone make sense of what they're trying to tell there?

They found some issue ("irregularities") and made 2 changes, but the changes are merely restricting the TLS version to 1.2 and deprecating an old OID identifier. While TLS < 1.2 certainly is not ideal, I don't see how this would impact the ACME validation, and the old OID should be irrelevant as well.

(I have been somewhat concerned about the security properties of the acme/alpn validation for unrelated other reasons, but haven't been able to pin that down to a specific threat - notably the RFC implies that the security is improved due to strict ALPN validation, which in practice usually does not happen.)

Update: RFC 8737 (the ALPN validation method) says "ACME servers that implement "acme-tls/1" MUST only negotiate TLS 1.2". So maybe this is "just" a policy issue?

[jaas]

Head of Let’s Encrypt here. This is a compliance issue, there is no security or validation integrity risk.

[cryptofistMonk]

Damn, unfortunate that you will revoke all these certificates if there is truly no security risk. This is likely going to break a lot of our users, or require manual intervention within the next 42 hours.

[Kesseki]

It is unfortunate. It's required: https://github.com/cabforum/servercert/blob/main/docs/BR.md#...

[tialaramex]

I have absolutely no insider knowledge.

However, we have seen lots of incidents where the actual problem is that we'd relied upon something that seems like it should be true and actually isn't. So what about a situation where an HTTPS server accepts tls-alpn-01 validation attempts but actually it has no idea what tls-alpn-01 validation even is ? Maybe it takes some (or all?) TLS extensions and just pretends to accept them.

On a bulk host I think you could abuse that to get "validated" despite having only a very tangential relationship (sharing an IP address) to the validated name, similar to the problem with previous TLS based validation methods.

The draft RFC for tls-alpn-01 says TLS 1.2 is mandatory, so, while that might be unrelated, it also might be that there's a bunch of servers out there which get this wrong but don't speak TLS 1.2 and the expectation is that nobody will upgrade them to speak TLS 1.2 but still get this wrong (or maybe for other reasons their misbehaviour means they'll catch fire in TLS 1.2)

[phicoh]

Just a random guess.

The security of TLS-ALPN-01 relies on TLS implementations rejecting a connection if an unknown ALPN is present.

It is possible that TLS 1.1 and earlier do not require this behavior leading to exactly the SNI confusion that this mechanism was meant to prevent.

[tialaramex]

I think tls-alpn-01 doesn't need you to reject the connection, my understanding is that successful validation requires three things:

The server agrees this SNI matches its name

The server agrees it offers this ALPN protocol

The server provides the tls-alpn-01 magic certificate agreed via ACME

Unfortunately none of these three steps requires affirmative work by the server to get it wrong, they can just passively nod along. "Yeah, I'm abandoned-server.bank.example, whatever you say", "Yeah, sure I can talk alpn/1 protocol, whatever that is", "Yeah, this certificate I was given by some bozo is definitely my certificate"

We know from previous incidents that just because something is obviously a bad idea, or even explicitly forbidden, doesn't mean it won't get done unless we also make it difficult so that it's easier not to.

[hannob]

> The security of TLS-ALPN-01 relies on TLS implementations rejecting a connection if an unknown ALPN is present.

I hope it does not, because the majority of servers don't reject unknown ALPNs. (See: ALPACA attack)

[phicoh]

RFC 8737, Section 5: "The second assumption is that a server will not violate [RFC7301] by blindly agreeing to use the "acme-tls/1" protocol without actually understanding it."

RFC 7301, Section 3,2: "The server SHALL NOT respond with a selected protocol and subsequently use a different protocol for application data exchange."

[hannob]

I know what the RFCs say. RFC 7301 also says: "In the event that the server supports no protocols that the client advertises, then the server SHALL respond with a fatal "no_application_protocol" alert." It's not what happens in reality. You may try:

openssl s_client -connect google.com:443 -alpn foobar

Now if you come up with a way to exploit this behavior I'm interested to hear that. (I was at that point a few weeks ago, but I haven't gotten around doing a thorough analysis how relevant that property is for the ALPN method.)

(There's a subtlety here I should note: It seems many servers will accept garbage ALPN identifiers, but will not answer with those identifiers. Instead they will allow a connection with their default protocol and not answer ALPN at all. This likely makes this nonexploitable in the ACME case, but still feels problematic that they rely on such subtleties.)

[perlgeek]

It seems the reasoning here is: the TLS handshake might have used an insecure TLS version, and so they cannot be sure that the handshake worked the way they thought, and so the certificates could have been issued to the wrong party.

I don't have a deep understanding of the TLS-ALPN-01 validation nor of the vulnerabilities they might be concerned about, but that would be the only reason for revoking certificates (unless it's more of a political statement, "we revoke certs when we screwed up!").

[walrus01]

The population of browsers and things that don't understand TLS1.2 is miniscule now, so there should be no impact in disabling tls1.1 and below anywhere possible.

[YPPH]

Browsers aren't to the point here, it is referring to servers seeking to verify control of a domain, by conducting a “acme-tls/1” handshake initiated by the Let's Encrypt issuance server.

If such a server only supports TLS 1.1, then TLS-APLN-01 validation will fail after this change is implemented.

[walrus01]

Nobody should be running tls1.1 only (and incapable of opportunistically negotiating for 1.2 or 1.3 instead) on their public facing httpd in 2022, I disabled everything below 1.2 on some rather high traffic websites several years ago with zero impact.