too narrow listing of TLS cipher suites
jmhodges opened this issue · comments
The cipher suites in go-tigertonic all rely on RC4 which has many suspicions around it (its biases are a little funny and there are strong rumors of breaks from certain Government Bodies). While RC4 is a fine fallback for TLS 1.0 (due to BEAST), later versions of TLS are better off using CBC modes. Also, Go's crypto/tls already mitigates the BEAST attack.
The default list of cipher suites in crypto/tls is very solid and was chosen carefully.
If you wish to lock the cipher suite list down further, a more scalable way to do this would be to require TLS 1.2 as the minimum TLS version and continue to use the default cipher suite list. (TLS 1.2 and 1.1 fix the BEAST attack by changing how CBC is performed as one useful, if mooted, example). Using the defaults and setting the minimum version will net you the Langley-Approved cipher suites with few backwards compatibility problems.
Of course, perhaps I've mis-guessed why those were selected.
What an interesting intersection of internet people this ticket is. Those settings are exactly what we use explicitly internally, and I think we asked @ice799 to research the best combination. I am pretty sure this list was somehow influenced by that research, but I can't remember exactly how since the commit is from @rcrowley himself. Joe, do you have a trail of breadcrumbs somewhere for how we arrived at this list? Pretty sure backwards compatibility was a consideration.
@mihasya: Could you be explicit about "Those settings", please? Do you use just the ECDHE+RC4 and plain RC4 like server.go says or the defaults Jeff's referencing?
@jmhodges: You're right to call this up. The current Tiger Tonic default was chosen long ago when this was still an internal framework for purposes of interoperability with Node.js. I know. Least good reason ever. Anyway, I've tested removing Tiger Tonic's configuration and committed a change to remove the restriction to RC4.
@wadey: Does this break anything at Betable?
Doesn't the Go http client only do TLS 1.0? I think that actually was the
main compatibility constraint for us.
On Saturday, July 26, 2014, Richard Crowley notifications@github.com
wrote:
@mihasya https://github.com/mihasya: Could you be explicit about "Those
settings", please? Do you use just the ECDHE+RC4 and plain RC4 like
server.go says or the defaults Jeff's referencing?@jmhodges https://github.com/jmhodges: You're right to call this up.
The current Tiger Tonic default was chosen long ago when this was still an
internal framework for purposes of interoperability with Node.js. I know.
Least good reason ever. Anyway, I've tested removing Tiger Tonic's
configuration and committed a change to remove the restriction to RC4.@wadey https://github.com/wadey: Does this break anything at Betable?
—
Reply to this email directly or view it on GitHub
#74 (comment)
.
Sent from Russia, with love. But also from my phone.
No, the Go HTTP client defaults to TLS 1.2 and has since Go 1.0, iirc.
Proof that Go 1.3 definitely does:
$ curl -so dYWzAKTxvb.go http://play.golang.org/p/dYWzAKTxvb.go && go run dYWzAKTxvb.go
TLS 1.2
Doing a little more digging for my own sanity just to figure out how this choice of ciphers came about.. Go 1.2 release notes seem to bear out my suspicion (that is when TLS 1.1 and 1.2 were added). We started using tt with Go 1.1, so that likely had to do with the choice of ciphers (again, I cannot remember for sure and can't find any relevant emails or chats).
EEEEIIIIRRRRRRREGARDLESS, 100% agreed that there's no reason to keep these settings around given the current state of affairs and the known RC4 issues. 👍 on the patch.
@wadey: Does this break anything at Betable?
Nope, we are building our own tls.Config so this change doesn't affect us.
Thanks for securing everything, @jmhodges!