[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.)