Cipher suite choice on macOS on Apple Silicon

Question

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?

Update

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.

Answer 1

Apple has an AES engine as part of the Secure Enclave subsystem. It provides:

a boot ROM to establish a hardware root of trust, an AES engine for efficient and secure cryptographic operations, and protected memory

The AES Engine is a separate component from both the Secure Enclave and the Secure Enclave AES Engine, but its operation is closely tied to the Secure Enclave

The Secure Enclave hardware feature is listed in the reference to be on Mac computers with Apple silicon (and a several other Apple devices).

I couldn't find any definitive reason why an Apple silicon device would choose Chacha20 over AES. The link below provides speculation but nothing definitive.

References
Apple Secure Enclave
What's the appeal of using Chacha20 instead of AES

Answer 2

Which cipher suite is chosen by the server, irrespective of what accelerators a client has. The client can submit a preference list, but the server is free to ignore it.

The key would be to check the postfix server's preference list. If Chacha happens to be high on it's list (maybe it's in a VM without accelerator support), that may just be what it chooses.