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](https://github.com/golang/go/commit/9d0819b27ca248f9949e7cf6bf7cb9fe7cf574e8#diff-fa1ebabc009bcc9a9f27168612adf5b4d56f9f40d613a62f86830861acb85803R215-R270
> ) 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?