crypto/tls: make cipher suite preference ordering automatic · golang/go@9d0819b
github.com
We now have a (well, two, depending on AES hardware support) universal cipher suite preference order, based on their security and performance. Peer and application lists are now treated as filters ...

cross-posted from: https://lemmy.ml/post/171118

On the account that “we are better equipped”, Go will now ignore the order of the CipherSuite option, starting with Go 1.18, due this month.

The sorting logic is detailed in the code.

Several choices seem strange to me:

  • “SHA-256 variants of the CBC ciphersuites don’t implement any Lucky13 countermeasures.” leading to CBC-SHA1 being favored over CBC-SHA256.
  • “AES comes before ChaCha20”, on the account that AES-NI is faster. They use heuristics to determine whether both ends support AES-NI and whether to prefer ChaCha20 over AES.
  • “AES-128 comes before AES-256”, on the account that AES-256 is slower.

The static nature of the sorting algorithm also leads to security conundrums such as the fact that updating the Go library and recompiling programs will be required if a vulnerability is found in an algorithm implementation (e.g. Lucky13 for the CBC-SHA256 Go implementation); you won’t be able to just reduce its priority by updating a config file.

What’s your take on this? Can you explain some of the choices that feel strange to me?