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