Detect standard ALPN protocol IDs

[Delicates]

Which version are you referring to 3.2rc2 (default 3.1dev branch)

Describe your feature request (if it's a technical feature) testssl.sh should detect all standard ALPN Protocol IDs.

If your feature request otherwise is related to a usage problem, please describe it Currently it doesn't detect ALPN Protocol IDs for many commonly used protocols such as HTTP/3, IMAP, POP3, IRC, DoT, etc. When a server supports a standard ALPN Protocol ID which testssl.sh doesn't recognise, it incorrectly reports:

 ALPN/HTTP2 not offered

The reported heading also seems to incorrectly assume that the sole purpose of ALPN is for HTTP/2.

Describe the solution you'd like Implement detection for all standard ALPN Protocol IDs: https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

Don't assume ALPN exists only for HTTP/2. More than 25% of websites are already using HTTP/3, and there are many other widely used protocols that rely on TLS which have their own ALPN Protocol IDs.

[drwetter]

Good point. Shouldn't be difficult to implement.

[dcooper16]

It certainly seems like a good idea to compare https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids to the current value of ALPN_PROTOS, and add ones that are missing, as appropriate. However, it seems that we won't be able to detect HTTP/3.

I tried connecting to several servers that supposedly support HTTP/3, sending an ALPN extension with "h3", and always got the response "No ALPN negotiated" (sending "h2" worked, however). I think I understand why now. According to Wikipedia, HTTP/3 only works over QUIC. So, it would make sense that HTTP/3 cannot be negotiated over TLS.

[drwetter]

oh, ok. Thanks. That was also my first idea trying but didn't get to it today.

Then probably is to do "best effort approach" -- i.e. add missing protocols. A possibility to test against some servers would be great though.

[Delicates]

Oh, just adding Protocol IDs to ALPN_PROTOS is a simple enough change. I chucked a few of them in onto my TLS Proxy's ALPN for testing and all get detected fine as long as ALPN_PROTOS has them:

Agree, real-world HTTPS/3 and DoQ would always be inside of QUIC. I'm not sure if TLS server (or client) ALPN-advertising h3 or doq over TCP is necessarily bad, I couldn't find anything forbidding it. You could argue that ALPN-advertising h3 over TCP may indicate to the client that HTTP/3 is available on standard UDP port?

I think it's a much broader protocol stack issue, with QUICv2 being drafted already, as was discussed by IETF a few years ago: https://datatracker.ietf.org/meeting/106/materials/slides-106-quic-alpn-00

[drwetter]

I tried to add all the protocols which IANA specified, additionally to the "specials" from facebook and google.

The thing is that the execution time was longer (up to ten seconds) and the outcome was little. Not sure we should add those check in any case. Alternatively we could add some magic and restrict the protocol to the ones which make sense for the port and add a a switch. It's not nice though.

I chucked a few of them in onto my TLS Proxy's ALPN for testing and all get detected fine

Any hint for a public server which offers more than h2 and http/1.1?

[Delicates]

Any hint for a public server which offers more than h2 and http/1.1?

Some DoT severs specify dot in their ALPN, for example: dns.quad9.net:853

You can easily set up a TLS server with any protocol IDs for testing by using the alpn option in HAProxy: https://docs.haproxy.org/2.7/configuration.html#5.1-alpn

Here are some examples showing how it's done: https://www.haproxy.com/documentation/hapee/latest/load-balancing/protocols/http-2/