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. On Friday, August 26, 2022 at 5:56:18 PM UTC-7 Nate White wrote: > 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 > > On Fri, Aug 26, 2022 at 9:16 AM 'Sean Liao' via golang-nuts < > golan...@googlegroups.com> wrote: > >> 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 >> >> On Fri, Aug 26, 2022, 04:23 'Diana Tuck' via golang-nuts < >> golan...@googlegroups.com> wrote: >> >>> 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? >>> >>> On Thursday, August 25, 2022 at 1:30:11 PM UTC-7 Diana Tuck wrote: >>> >>>> Yes, I'm aware it's intentional, but it causes a lower security grade >>>> on SSLLabs <https://ssllabs.com/>. >>>> >>>> On Thu, Aug 25, 2022 at 1:20 PM 'Sean Liao' via golang-nuts < >>>> golan...@googlegroups.com> wrote: >>>> >>>>> This is intentional, see https://go.dev/issue/45430 >>>>> >>>>> - sean >>>>> >>>>> On Thu, Aug 25, 2022, 19:07 'Diana Tuck' via golang-nuts < >>>>> golan...@googlegroups.com> wrote: >>>>> >>>>>> 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 >>>>>> <https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=11&platform=Win%207&key=95> >>>>>> and >>>>>> Win 8.1 >>>>>> <https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=11&platform=Win%208.1&key=134> >>>>>> 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. >>>>>> >>>>>> -- >>>>>> 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 >>>>>> >>>>>> <https://groups.google.com/d/msgid/golang-nuts/726cacb3-ddf3-4602-8455-4eae9889f236n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>>> >>>> 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 >>>>> >>>>> <https://groups.google.com/d/msgid/golang-nuts/CAGabyPrJ56%3DPd0Du1ooVd9dx-CA3N%3DNkHN46OaHfFTC7S%2B_x1A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>>> >>>> -- >>>> Thank you, >>>> >>>> Diana Tuck >>>> Software Engineer >>>> +1 (919) 270-9838 <(919)%20270-9838> >>>> diana...@elastic.co >>>> >>>> <https://www.elastic.co/> >>>> >>> -- >>> 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/7384e49b-bf7e-4343-b0a9-fa5503cc9905n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/golang-nuts/7384e49b-bf7e-4343-b0a9-fa5503cc9905n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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/CAGabyPrzwbBZqXb70fMOaSrv5562G6uTXviMRimE_aRbMNkBdg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/golang-nuts/CAGabyPrzwbBZqXb70fMOaSrv5562G6uTXviMRimE_aRbMNkBdg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/fb8b8fc6-585f-4796-9708-67ddc2f6782en%40googlegroups.com.
