Hi -again,
I was wondering if there is a way, with Caddy, to disable the “server” preferred order for the cipher suites? (and take what the client prefers)
For example, since Android 7 (if I don’t make mistake), when there is no server-preferred order, Google Chrome will pick up one of the AES based cipher “only” if the CPU has AES instructions, otherwise it will use CHACHA20 which is then faster.
Is it possible to do this with Caddy?
Thank you,
No, not yet possible. This would be easy to add to the Caddyfile, however, right now the TLS config is optimized for server performance: if the server hardware supports AES, it will prefer AES cipher suites, if not, then ChaCha.
There are some subtle complications with disabling this or making it configurable, so I’m not quite ready to go that route yet. In general, users aren’t able to perceive the performance difference between ChaCha and AES, if one is hardware-accelerated and the other isn’t. This is because the external network is almost always the bottleneck, and client machines (including low power devices like phones) generally only have one or just a few TLS connections going at a time, where a server can have thousands
So, before enabling this, I’d want to 1) be convinced that it is actually faster in a significant number of cases, 2) be convinced that clients aren’t still asking for cipher suites without PFS, and 3) be convinced that the clients are updating their cipher suite preferences more regularly than Caddy is/will.
Thanks for your question. 
Thank you for your explanations.
NB: I noticed something, I didn’t know If I had to open a new topic just for it.
I have the impression that the use of QUIC, changes the cipher; is it the case?
ciphers ECDHE-ECDSA-WITH-CHACHA20-POLY1305 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-CBC-SHA
The first request (http/2), shows:
The connection to this site is encrypted and authenticated using a strong protocol (TLS 1.2), a strong key exchange (ECDHE_ECDSA with X25519), and a strong cipher (CHACHA20_POLY1305).
The following requests (QUIC), have :
The connection to this site is encrypted and authenticated using a strong protocol (QUIC), a strong key exchange (X25519), and a strong cipher (AES_128_GCM).
Is it the normal behaviour ?
Sorry, if this is a silly or obvious question (and I know that QUIC support is experimental)
I think the QUIC library we use has different cipher suite requirements than standard HTTP/2. But I’m not sure. But that’s my guess.
Okay, thank you for all!
Have a nice week-end.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.