Support for SSL_OP_PRIORITIZE_CHACHA

[dennisbaaten]

People are reporting issues with internet.nl and HAproxy. The preferred cipher order for TLS 1.3 is not detected properly and results this subtest to fail. This is related to the SSL option SSL_OP_PRIORITIZE_CHACHA. On openssl.org (https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_clear_options.html) the documentation states the following about SSL_OP_PRIORITIZE_CHACHA:

"When SSL_OP_CIPHER_SERVER_PREFERENCE is set, temporarily reprioritize ChaCha20-Poly1305 ciphers to the top of the server cipher list if a ChaCha20-Poly1305 cipher is at the top of the client cipher list. This helps those clients (e.g. mobile) use ChaCha20-Poly1305 if that cipher is anywhere in the server cipher list; but still allows other clients to use AES and other ciphers. Requires SSL_OP_CIPHER_SERVER_PREFERENCE."

When setting up a connection, internet.nl detects that the client (in this case a HAproxy instance) prefers a ChaCha20 cipher and as a result temporary reprioritizes the cipher preference. While this works as exptected, this unfortunately results in a failed test, because the expected cipher order (without the SSL_OP_PRIORITIZE_CHACHA option set) is not detected by the internet.nl test engine.

This problem is already recognized by HAproxy (haproxy/haproxy#455) and for this option to work, adjustments need to be made to our test engine. SSL Labs already implemented changes for supporting SSL_OP_PRIORITIZE_CHACHA: ssllabs/ssllabs-scan#657.

Examples of domains where this is happening (and where HAproxy is used): croit.io and mattermost.coosto.com.

While NCSC states in their TLS guideline that AES-256 is preferred over ChaCha20, it also states in footnote 23: "some choose to trade-off server performance against client battery life by preferring ChaCha20 over AES". And since ChaCha20 is also considered (Good), I think we should also pass the test if (due to the use of SSL_OP_PRIORITIZE_CHACHA) the order is temporary reprioritized and ChaCha20 is on top.

SSLlabs already introduced a fix for this: ssllabs/ssllabs-scan#657.