Hacker News Reader

Comment by LukeLambert | Hacker News Reader

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

View on HN

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 isn't the only CA out there. Even so, you can do TLS-ALPN on any port. You can do TLS-ALPN on port 443 without using the HTTP protocol in any way. To ALPN, 443 is just an arbitrary number, like the IP address of Lets Encrypt's server.

> If you actually want certificate issuance unrelated to web servers you should either hook up a web server

Good heavens, no.

Although "TLS can be used for those non-HTTP protocols" the tls-alpn-01 validation can only be used on the authorised ports, which for Let's Encrypt is port 443, aka HTTPS.

Now, Let's Encrypt would technically be allowed to enable this validation on a few other ports, 80 (HTTP), 25 (SMTP) and 22 (SSH) under current Baseline Requirements, but understandably they have no plan to do that.

If you actually want certificate issuance unrelated to web servers you should either hook up a web server explicitly for issuance or use DNS proof of control.

> Good heavens, no.

You skipped the second part of the argument. And what "no" means in that context. What's your alternative?

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

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.

TLS doesn't have a fixed port number. Ergo, TLS-ALPN doesn't either.

It is the intention of the ALPN spec that you can do tls-alpn-01 on whatever TCP port the two parties (issuer and recipient) care to use.

Reply on news.ycombinator.com