-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Client simulations send inappropriate ALPN to non-http services #2410
Comments
Hi Geert, Looks like we want to remove the extension under some, to be defined, circumstances. If we don't want to remove that completely in ./etc/clientsimulation,txt it needs to be handled somewhere e.g. in The circumstances though are not quite clear to me. The best which popped up in my mind so far was to exclude port 995, 993, 465 and the like. The handshake would be not correct though when those ports are HTTPS. It might be an issue with STARTTLS too. Thanks! Dirk |
I am running testssl.sh 3.2rc2 from https://testssl.sh/dev/, commit f0e1540.
I am running testssl.sh against a mail service (POP3 and IMAP) behind nginx as a reverse proxy. Since nginx 1.21.4, this results in incorrect "No connection" for many client simulations. This is because several client simulations include ALPN in their client hello with services "http/1.1" and "h2", which is not appropriate for non-http services, and recent nginx rejects this to mitigate an ALPACA attack (behaviour recommended by RFC 7301).
A minimal nginx config to reproduce this: (doesn't need an actual working auth_http backend)
And run
testssl -c localhost:995
against this:This produces connection failures even if the server is configured with protocols/ciphers that in reality allow these clients. The simulation only fails because of the incorrect ALPN extension issued by testssl when using sockets.
The generic OS clients in client-simulation.txt should probably omit the ALPN extension in their handshake, or have an alternative handshake without ALPN for non-https testing (or with an application-specific ALPN if a mailclient eg. Thunderbird is observed to send it).
For comparison,
testssl --ssl-native -c localhost:995
does not issue ALPN, and gives a more correct view on the client handshakes (within the limitations of the used openssl version).Other mail servers (eg. postfix, dovecot, ...) ignore ALPN and can be tested just fine, only nginx recently added this extra check for security.
The text was updated successfully, but these errors were encountered: