Why is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 first in the cipher list?

[rays...@yahoo.com]

The go http2 server sets PreferServerCipherSuites true so that banned http2 ciphers will not be selected [1]. I've been testing go server http2 with a few ssl libraries recently and I noticed in wireshark that the cipher chosen by the server is always TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, presumably because it is always accepted for http2 but also because it's the first cipher in the server's preferred cipher list, which is the same as the list in crypto/tls/cipher_suites.go [2] sans suiteDefaultOff.

For example I have a client that offers both TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384  and TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 but because TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 has a higher preference it is used. So my question is why make that cipher first when there are stronger ciphers that aren't banned by http2?

[1]: https://github.com/golang/net/commit/42ad508
[2]: https://github.com/golang/go/blob/master/src/crypto/tls/cipher_suites.go#L75

[David Anderson]

Based on a bit of googling, I found that both Mozilla and Chrome also recommend putting 128-bit AES-GCM ahead of 256-bit, for "public" configurations where you don't know the client's capabilities. The rationale is that 256-bit AES is a significant performance hit for machines that don't have hardware accelerated AES (the AESNI instruction). Given that AES-128 is currently still considered safe for use, it's a worthwhile tradeoff to provide a better experience to older hardware.

Mozilla's "Modern" ciphersuite list gives a hint about the future, and it does put 256-bit GCM ahead of 128-bit. But the "Modern" list is built on the assumption that the whole world has modern hardware and software, and pushes the tradeoff needle harder towards security and away from usability.

https://wiki.mozilla.org/Security/Server_Side_TLS

https://bugs.chromium.org/p/chromium/issues/detail?id=442572

- Dave

--
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.
For more options, visit https://groups.google.com/d/optout.

[Julien Vehent]

Note that you can set your own cipher ordering server-side by using a tls.Config.

An old example: https://jve.linuxwall.info/blog/index.php?post/2014/10/16/Mitigating-POODLE-on-a-Go-server

- Julien

--

[Matt Silverlock]

> Based on a bit of googling, I found that both Mozilla and Chrome also recommend putting 128-bit AES-GCM ahead of 256-bit, for "public" configurations where you don't know the client's capabilities. The rationale is that 256-bit AES is a significant performance hit for machines that don't have hardware accelerated AES (the AESNI instruction). Given that AES-128 is currently still considered safe for use, it's a worthwhile tradeoff to provide a better experience to older hardware.

This is correct. The rationale is also that if AES-128 is broken, it would likely manifest in way that would also weaken AES-256.

If you have the option, you could also prefer ECDHE-ECDSA-CHACHA20-POLY1305-SHA256, since performance is substantially better than AES-GCM on mobile devices.

[rays...@yahoo.com]

I never considered a performance hit. Thanks for the help guys.