Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Issue with TLS-ALPN-01 Validation Method

community.letsencrypt.org

Post reply on HN
Print view View original

61–70 of 92 posts

Re: Issue with TLS-ALPN-01 Validation Method

#61

Post by tialaramex »

phicoh wrote: post #56
tialaramex wrote: post #53

Earlier quoted context omitted.

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…

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.

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.

Re: Issue with TLS-ALPN-01 Validation Method

#62

Post by phicoh »

hannob wrote: post #59
phicoh wrote: post #56

Earlier quoted context omitted.

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.

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

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."

Re: Issue with TLS-ALPN-01 Validation Method

#63

Post by sebiw »

hannob wrote: post #43
Aissen wrote: post #42

Small feedback for the letsencrypt folk: I got the email saying that I have two ACME accounts ids affected. It would have been nice to know which domains are (even if it's just the first ~10 or so per account).

They made the same mistake with the SNI deprecation and got plenty of feedback about it... It's disappointing that they haven't learned from this.

I understand your pain. Maybe keep in mind what operation they are running (complexity and scale) and that feedback may take time to implement. To put this into perspective think about what replacing certificates (or say obtaining new certificates) felt like before Let's Encrypt an ACME were a thing. ;-)

Re: Issue with TLS-ALPN-01 Validation Method

#64

Post by xg15 »

octoberfranklin wrote: post #16
LukeLambert wrote: post #7

This is the second security issue with a TLS-based challenge [1]. This was a good reminder to switch to the HTTP challenge for the one remaining server I had that was affected. [1] https://letsencrypt.org/docs/challenge-types/#tls-sni-01

That might work for you, but ALPN needs to exist because there's more to the Internet than just HTTP, and TLS can be used for those non-HTTP protocols. Some of those protocols are more fundamental than HTTP, and making them depend on HTTP would create a circular dependency. HN is choking again, so I must reply with edits *sigh* @tialaramex, you're confusing policies of one CA (LE) with the ALPN protocol. Lets Encrypt…

> Good heavens, no.

It's not exactly the most elegant solution, but I don't understand the aversion either. A "web server" that is only intended to serve the challenge file can be as simple as a thread that writes a static blob of bytes to a socket. That's nc -l stuff.

If you're already modifying your TLS backend to understand the ALPN challenge, I don't see why it would be that hard to add logic for one specific GET/200 OK pair.

Re: Issue with TLS-ALPN-01 Validation Method

#65

Post by xg15 »

What I don't quite get with all the certificate automation: Doesn't this all effectively just shift the "source of truth" to DNS?

Back when certificates were issued manually, a CA was also verifying that the requesting party was actually who they were claimed to be IRL - hence EV certificates and all that.

What LE and friends verify on the other hand is simply that the entity that requests a certificate also controls the DNS entry at that point in time - or at least controls some of the servers that are listed in the A/AAAA records.

For one of the infamous Authoritarian Governments, it should be no problem at all to obtain an LE certificate for any domain under their ccTLD. Just use the DNS challenge, then instruct the country's registrar to change the DNS record for the domain of interest.

Isn't that a massive centralisation compared to the old system?

Re: Issue with TLS-ALPN-01 Validation Method

#66

Post by tialaramex »

octoberfranklin wrote: post #16
LukeLambert wrote: post #7

This is the second security issue with a TLS-based challenge [1]. This was a good reminder to switch to the HTTP challenge for the one remaining server I had that was affected. [1] https://letsencrypt.org/docs/challenge-types/#tls-sni-01

That might work for you, but ALPN needs to exist because there's more to the Internet than just HTTP, and TLS can be used for those non-HTTP protocols. Some of those protocols are more fundamental than HTTP, and making them depend on HTTP would create a circular dependency. HN is choking again, so I must reply with edits *sigh* @tialaramex, you're confusing policies of one CA (LE) with the ALPN protocol. Lets Encrypt…

It's not about the ALPN protocol it's about the Baseline Requirements. Unless I'm gravely mistaken it certainly isn't the intention that you're allowed to accept tls-alpn-01 validation from some random service on say, port 8080 or 6697 as suitable for the purpose of validating control over a name for the Web PKI and I'd be grateful if you know of a public CA offering this that you'd say which ones and how you're aware of that.

That's why I listed three other ports, 80, 25 and 22. Those three are Authorized in the BRs for the purpose of validation because it does indeed seem unlikely that I can spin up a server on those ports if I do not control the machine they're answering for. Let's Encrypt does not use them for tls-alpn-01, and certainly doing so for ports 80 or 22 would seem really weird, but the rules aren't intended to prohibit it.

Re: Issue with TLS-ALPN-01 Validation Method

#67

Post by discreditable »

xg15 wrote: post #65

What I don't quite get with all the certificate automation: Doesn't this all effectively just shift the "source of truth" to DNS? Back when certificates were issued manually, a CA was also verifying that the requesting party was actually who they were claimed to be IRL - hence EV certificates and all that. What LE and friends verify on the other hand is simply that the entity that requests a certificate also controls…

It was always DNS. Unless you are getting EV the CAs usually verify ownership via email. Email can go anywhere the current MX record in DNS says it goes.

Re: Issue with TLS-ALPN-01 Validation Method

#68

Post by hannob »

phicoh wrote: post #62
hannob wrote: post #59

Earlier quoted context omitted.

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

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."

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

Re: Issue with TLS-ALPN-01 Validation Method

#69

Post by zauguin »

vbezhenar wrote: post #23
octoberfranklin wrote: post #15

Earlier quoted context omitted.

If they didn't fail open, every time a CA's website went down every single website that used their certificates would go offline as well. You can imagine the DDOS-ransomers licking their lips at this possibility. No, "fail open" has always been the only possible way to implement this. Which is why it's a broken idea from the start.

> If they didn't fail open, every time a CA's website went down every single website that used their certificates would go offline as well. That's not correct. OCSP stamps exist to prevent that kind of a problem.

OCSP always seemed a bit absurd to me: Instead of sending a OCSP stamp, the CA could also issue a very short lived certificate on demand. It would have the same effect of asserting that the CA currently considers the server to be verified and it doesn't need a separate format.

Re: Issue with TLS-ALPN-01 Validation Method

#70

Post by r1ch »

xg15 wrote: post #65

What I don't quite get with all the certificate automation: Doesn't this all effectively just shift the "source of truth" to DNS? Back when certificates were issued manually, a CA was also verifying that the requesting party was actually who they were claimed to be IRL - hence EV certificates and all that. What LE and friends verify on the other hand is simply that the entity that requests a certificate also controls…

That "manual verification" back in the day was an email verification link, so again, back to relying on DNS. I don't think there's a way around it, but at least with certificate transparency we'll know if it happens.
Post reply on HN