I have a postfix mail server that accepts these cipher suites:
tls_high_cipherlist=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384: ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305: DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
I noticed that when accessing this from macOS 12.3 with an Apple Silicon CPU over TLSv1.3 (i.e. client can choose suite), it selects the
ECDHE-ECDSA-CHACHA20-POLY1305 suite, even though it's listed after the AES suites. I'm just (idly) wondering why – does Apple Silicon not have AES hardware acceleration?
Further to @foreverska's comment, I had thought that TLSv1.3 had reversed the older policy of only allowing the server to choose a cipher suite, however, it's apparently not quite like that. I found a discussion which clarified things. It's not so much that TLSv1.3 allows for client choice, but that TLSv1.3 suites are considered equal weight, effectively letting the client choose from a shortlist. A TLSv1.3 client connecting to a 1.3 server should only select from 1.3 suites, even if they are listed after 1.2 suites. This is borne out by the Qualys SSL labs results on one of my own sites, which is served from nginx with server-side suite ordering enabled:
However, while that's good to know, why macOS would select ChaCha20 over AES if it has acceleration remains a mystery...
Further confirmation of client ordering of cipher suites in TLSv1.3 from RFC8446's definition of ClientHello:
cipher_suites: A list of the symmetric cipher options supported by the client, specifically the record protection algorithm (including secret key length) and a hash to be used with HKDF, in descending order of client preference.
and in ServerHello:
cipher_suite: The single cipher suite selected by the server from the list in ClientHello.cipher_suites.
So it appears that the concept of server-side cipher suite ordering doesn't exist at all within TLSv1.3.