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/
_______________________________________________
nginx mailing list -- nginx@nginx.org
To unsubscribe send an email to nginx-le...@nginx.org
