Client Cipher Order Preference not being honored with golang 1.17+

[Diana Tuck]

Since upgrading to 1.17 in which the cipher order is determined by the golang lib, clients that previously negotiated with more secure ciphers are now using less secure ciphers. 

We see that Windows 7 and 8 clients can no longer negotiate using xc027 and are instead using 0x9c, which is lower in both of their preference order.

On 1.16, using testssl.sh, for example:

 IE 11 Win 7         TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH (P-256)
 IE 11 Win 8.1       TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH (P-256)
 IE 11 Win Phone 8.1 TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH (P-256)
 IE 11 Win 10        TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)

And since upgrading to 1.17 (and 1.18):

IE 11 Win 7         TLSv1.2 AES128-GCM-SHA256, No FS
IE 11 Win 8.1       TLSv1.2 AES128-GCM-SHA256, No FS
IE 11 Win Phone 8.1 TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH (P-256)
IE 11 Win 10        TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)

Win 7 and Win 8.1 prefer 0xc027 over 0x9c, but now both negotiate using 0x9c.

We could theoretically solve this by removing 0x9c from our supported cipher suites to force the selection of 0xc027, but  unfortunately we need to keep supporting these older clients.

I wanted to check here to see if anyone has any suggestions before filing a bug, because in my opinion, the client cipher suite order preference should be honored at the very least even if the server preference is no longer honored.

[Sean Liao]

This is intentional, see https://go.dev/issue/45430

- sean

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/726cacb3-ddf3-4602-8455-4eae9889f236n%40googlegroups.com.

[Diana Tuck]

Yes, I'm aware it's intentional, but it causes a lower security grade on SSLLabs.

You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/EqtkbU9nXHE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGabyPrJ56%3DPd0Du1ooVd9dx-CA3N%3DNkHN46OaHfFTC7S%2B_x1A%40mail.gmail.com.

--

Thank you,

Diana Tuck

Software Engineer

+1 (919) 270-9838

diana...@elastic.co

[Diana Tuck]

I guess I need to clarify what I was trying to say here - golang 1.17+ claims that TLS_RSA_WITH_AES_128_GCM_SHA256 is more secure than TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 CBC-SHA256 doesn't have any countermeasures against Lucky13, but all of the SSL tools: testssl.sh, SSLLabs, etc. claim the other way around because of ECDHE.

So in intentionally handling the cipher ordering, it seems like this change unintentionally made things less secure, at least according to several other reputable security resources. Who's correct here?

[Sean Liao]

Given that Lucky 13 and other CBC attacks are more real (common, practical), Go's decision to lower their priority didn't seem unreasonable.

Collapsing a multi dimensional protocol into an ordering requires some value judgement on how heavily to weigh each component, there isn't a single correct answer.

- sean

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7384e49b-bf7e-4343-b0a9-fa5503cc9905n%40googlegroups.com.

[Nate White]

Hi Diana,

I found this question interesting, and so wanted to share some code pointers.

First, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 is included in the list of ciphers returned by crypto/tls.InsecureCipherSuites(): https://github.com/golang/go/blob/3d6ba27f4ffef372d9a41bc488ca329c2786187f/src/crypto/tls/cipher_suites.go#L93.

Second, a comment above crypto/tls.cipherSuitesPreferenceOrder spells out the logic behind demoting this cipher: https://github.com/golang/go/blob/3d6ba27f4ffef372d9a41bc488ca329c2786187f/src/crypto/tls/cipher_suites.go#L223-L227 ("SHA-256 variants of the CBC ciphersuites don't implement any Lucky13 countermeasures. See http://www.isg.rhul.ac.uk/tls/Lucky13.html and https://www.imperialviolet.org/2013/02/04/luckythirteen.html.").

I couldn't tell from that comment if the countermeasures mentioned are available for both SHA-1 and SHA-256, but the explainer blog post for the change to put Go servers in charge of cipher suite ordering makes it clear: https://go.dev/blog/tls-cipher-suites#:~:text=The%20CBC%20cipher,disabled%20by%20default ("The CBC cipher suites are vulnerable to Lucky13-style side channel attacks and we only partially implement the complex countermeasures discussed above for the SHA-1 hash, not for SHA-256. CBC-SHA1 suites have compatibility value, justifying the extra complexity, while the CBC-SHA256 ones don’t, so they are disabled by default.")

So ultimately, there's information here that the client and SSL evaluation tools don't possess: that Go implemented some of the countermeasures for Lucky13, but not for SHA-256. I don't know this area enough to say whether with full mitigations for Lucky13-style attacks the preference ordering you cited for testssl.sh, SSLLabs, etc. would be justified or not, but I think this extra information is enough to overrule that general preference knowing what mitigations Go has implemented.

~Nate

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGabyPrzwbBZqXb70fMOaSrv5562G6uTXviMRimE_aRbMNkBdg%40mail.gmail.com.

[Diana Tuck]

Thank you for the additional context. I indeed missed that TLS_RSA_WITH_AES_128_GCM_SHA256 was listed in the InsecureCipherSuites.

I also found the comment above cipherSuitesPreferenceOrder to be missing some pertinent information, but the blog post does clear that up. Thank you for sharing that - I'll need to make sure to look there first in the future.