first of: as I’m not sure what’s causing this issue I’ll post this question on these locations:
opensuse official forums
apache httpd mailing list
openssl mailing list
As OpenSuSE 15.2 recently released with openssl 1.1.1 in its repos it’s now possible to use TLSv1.3 with Apache2 out of the box. As I use the TLS test on ssllabs.com as a reference I encountered some issues I’d like to ask for help to fix.
First of, as most important, the used versions:
And here’s the config (only used ssl-global.conf for this test):
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLOpenSSLConfCmd Curves secp521r1:secp384r1
There were no other changes made to any other conf.
As one can see I only enabled AES with 256 bit keylength and ordered chacha20 preferred over AES. But when testing with ssllabs.com server test it shows two issues I’m unable to solve myself:
- although not enabled the server test also shows AES with only 128 bit keylength enabled and working - hence capping the score to only 90% for cipher strength (only ciphers with an equivalent of at least RSA 4096 give one full 100%)
- the order doesn’T match the config - it shows AES256 as the most preferred one, then followed by the chacha20 and finally the AES128
As I don’t know if this is an issue with apache, openssl or opensuse I posted it on all three to reach most group of people, so, if you’re member of more than one of the mentioned I apologize if you get this topic multiple times.
Thanks in advance to anyone,
SSLCipherSuite TLSv1.3 TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384
SSLCipherSuite SSL ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384
Note that AES128 is mandatory in TLS 1.3, so strictly speaking this makes your server non-compliant.
You can also verify it using OpenSSL:
$ openssl ciphers -v -ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384 ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
And please, use [noparse]
[/noparse] tags when posting computer output.
Got the same advice on the openssl mailing list, just a few hours later.
Anyway, it did in fact “fixed” my “issue”. As I dug further down on “AES128 is mandatory for TLSv1.3” I found some “argues” on ssllabs’ github issue list: In fact they had a penalty in place when a server was configured to only support AES256 but not the mandatory AES128, but that was changed as it turned out that this very design “flaw” caused either a penalty for not supporting AES128 - or for supporting it. Hence both, a correctly configured server and a non-compliant one, only resulted 90%. I guess the ssllabs’ team may decided to disable the penalty for not supporting AES128 to give admins back their “all four 100% bars”.
As for why TLSv1.3 “requires” AES128 and only has AES256 and CHACHA20 as “should” - well, I guess we all can think about a three-letter reason (in fact: several of them) without shouting them out loud.
Thanks for the fast reply.
I’ll report back on the two mailing lists to let anyone know this is “solved” as for now.