Why do newer versions of Chromium favor RSA certificates over ECC certificates?

[Maxim Dounin]

Hello!

On Sun, May 22, 2022 at 02:55:29AM +0800, wordlesswind via nginx wrote:

> I noticed that after Chromium 594356 build (71.0.3563.0) it favors RSA 
> certificates over ECC certificates.

[...]

> I don't get the idea from the changes in the source code. I'm curious to 
> know why, since obviously ECC certificates are smaller than RSA 
> certificates.
> 
> 
> Let’s Encrypt
> 
> ECC 384 (E1)
> 
> RSA 4096 (R3)
> 
> nginx.conf:
>          ssl_stapling         on;
>          resolver             8.8.8.8 1.1.1.1 valid=300s;
>          ssl_stapling_verify  on;
> 
>          ssl_session_cache    shared:SSL:10m;
>          ssl_session_timeout  1d;
> 
>          ssl_protocols        TLSv1.2 TLSv1.3;
>          ssl_ciphers 
> ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256;
>          ssl_ecdh_curve       secp384r1;
> 
>          ssl_early_data       on;

First of all, you may want to get rid of the "ssl_ecdh_curve" in 
your nginx configuration.  Or at least add "prime256v1" and 
"x25519" to the list.  Using only "secp384r1" severely limits what 
can be used during the handshake, and can affect ciphers and 
certificates being used.

For example, in current versions of Chrome the preferred signature 
algorithm for TLS 1.3 ciphers is "ecdsa_secp256r1_sha256", so it 
won't work in your configuration.  And the only key share group is 
"x25519", so your configuration will require HelloRetryRequest.

Secondly, given the signature algorithms order as used by Chrome 
and assuming Chromium's is the same, you'll likely have to switch 
to prime256v1 (AKA secp256r1) certificates (and probably from R3) 
to make sure they are being preferred over RSA:

            Extension: signature_algorithms (len=18)
                Type: signature_algorithms (13)
                Length: 18
                Signature Hash Algorithms Length: 16
                Signature Hash Algorithms (8 algorithms)
                    Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)
                        Signature Hash Algorithm Hash: Unknown (8)
                        Signature Hash Algorithm Signature: SM2 (4)
                    Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
                        Signature Hash Algorithm Hash: SHA384 (5)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Algorithm: rsa_pss_rsae_sha384 (0x0805)
                        Signature Hash Algorithm Hash: Unknown (8)
                        Signature Hash Algorithm Signature: Unknown (5)
                    Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
                        Signature Hash Algorithm Hash: SHA384 (5)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Algorithm: rsa_pss_rsae_sha512 (0x0806)
                        Signature Hash Algorithm Hash: Unknown (8)
                        Signature Hash Algorithm Signature: Unknown (6)
                    Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
                        Signature Hash Algorithm Hash: SHA512 (6)
                        Signature Hash Algorithm Signature: RSA (1)

Note that ecdsa_secp384r1_sha384 comes after rsa_pkcs1_sha256.  
Overall, it looks like signature algorithms are ordered based on 
the hash function bits, and this results in RSA with sha256 
signature being preferred over ECDSA with secp384r1/sha384.  The 
question "why to use such order" should be addressed to the 
Chromium developers, as already suggested.

Just in case, on nginx side you can force the order you prefer by 
using the ssl_prefer_server_ciphers directive 
(http://nginx.org/r/ssl_prefer_server_ciphers).  I wouldn't 
recommend doing this though, as in most cases clients know better 
which ciphers they can handle more efficiently and securely.

-- 
Maxim Dounin
http://mdounin.ru/