There's a curious situation regarding dual ECDSA/RSA certificates, where some ECDHE_RSA ciphers are not detected. I'm working on this in the context of writing my own server cipher order preference detection, which I am cross-checking with the SSLlabs scan, and with openssl s_client. I think there is an incomplete detection in the SSLlabs scan.
Specific example: github.com. According to me TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 and TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 are both supported on TLS 1.2. The former is preferred over the latter, which in my ruleset is bad, as any CBC should be less preferred than CHACHA20. Confirmed here with openssl s_client. I am certain that both cipher suites are enabled, because openssl s_client -tls1_2 -cipher ECDHE-RSA-CHACHA20-POLY1305 -connect github.com:443 also succeeds.
However, in the ssllabs scan result, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 is entirely missing. Several ECDHE_RSA ciphers are detected, but CHACHA20 is only detected with ECDSA.
This may be related to another oddity. When offering TLS_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, negotiation fails entirely:
openssl s_client -tls1_2 -cipher 'AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA' -connect github.com:443
Connecting to 140.82.121.3
CONNECTED(00000006)
00906AD901000000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:ssl/record/rec_layer_s3.c:865:SSL alert number 40
Even though TLS_RSA_WITH_AES_256_GCM_SHA384 is enabled, and exclusively offering it will succeed. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA is not supported, but in my understanding, that should not typically be an issue when offering multiple options. However, this request lead to the false conclusion that neither cipher is supported. I don't have a full list of which combinations are or are not accepted. Interestingly, ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-CHACHA20-POLY1305:AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA is accepted for example. But something odd is happening.
TLDR: on github.com TLS 1.2, ciphers that are definitely supported do not all seem to be detected, possibly related to github.com rejecting negotiation, even when at least of the ciphers offered by the client are definitely supported. It is possible I am overlooking something, or that this behaviour is so strange the test is not expected to support it.
There's a curious situation regarding dual ECDSA/RSA certificates, where some ECDHE_RSA ciphers are not detected. I'm working on this in the context of writing my own server cipher order preference detection, which I am cross-checking with the SSLlabs scan, and with openssl s_client. I think there is an incomplete detection in the SSLlabs scan.
Specific example: github.com. According to me TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 and TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 are both supported on TLS 1.2. The former is preferred over the latter, which in my ruleset is bad, as any CBC should be less preferred than CHACHA20. Confirmed here with openssl s_client. I am certain that both cipher suites are enabled, because
openssl s_client -tls1_2 -cipher ECDHE-RSA-CHACHA20-POLY1305 -connect github.com:443also succeeds.However, in the ssllabs scan result, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 is entirely missing. Several ECDHE_RSA ciphers are detected, but CHACHA20 is only detected with ECDSA.
This may be related to another oddity. When offering TLS_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, negotiation fails entirely:
Even though TLS_RSA_WITH_AES_256_GCM_SHA384 is enabled, and exclusively offering it will succeed. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA is not supported, but in my understanding, that should not typically be an issue when offering multiple options. However, this request lead to the false conclusion that neither cipher is supported. I don't have a full list of which combinations are or are not accepted. Interestingly,
ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-CHACHA20-POLY1305:AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHAis accepted for example. But something odd is happening.TLDR: on github.com TLS 1.2, ciphers that are definitely supported do not all seem to be detected, possibly related to github.com rejecting negotiation, even when at least of the ciphers offered by the client are definitely supported. It is possible I am overlooking something, or that this behaviour is so strange the test is not expected to support it.