$ go version
go version devel +724a86fced Wed Mar 27 02:37:56 2019 +0000 openbsd/amd64
What did you do?
//MaxVersion: tls.VersionTLS12,ServerName: "www.cloudflare.com",
conn, err:=tls.Dial("tcp", "www.cloudflare.com:443", tlsCfg)
log.Fatalf("Failed to dial: %v", err)
log.Printf("Connected with TLS 0x%x using cipher suite 0x%x\n", cs.Version, cs.CipherSuite)
What did you expect to see?
Connected with TLS 0x303 using cipher suite 0xc02f
(which is what occurs if compiled with Go 1.12)
What did you see instead?
Connected with TLS 0x304 using cipher suite 0x1301
Based on the crypto/tls code and documentation for crypto/tls.Config, this is an intentional change, however it changes the behaviour of existing code - previously when compiled and run it would adhere to the configuration in CipherSuites, however it is now silently ignored and the behaviour changes to one that is not intended by the author.
This means that the connection is potentially being established without using one of the intended cipher suites - there are various cases where this is a bad thing. Obviously it can be worked around by pinning the maximum version (i.e. uncommenting the MaxVersion in the above code), however this still requires a change to existing code and is probably worse than having pinned cipher suites.
I'm also somewhat concerned by the fact that there is no way to configure the cipher suites for TLS 1.3.
The text was updated successfully, but these errors were encountered:
So you're saying that it is fine that this breaks code that works with Go 1.12 (and probably every Go 1 release), now that the previous behaviour/configuration is ignored?
Unfortunately, cipher suite selection is not just about security and performance - there are also contractual and compliance reasons. At the very least, it seems that if TLS 1.3 is going to be enabled and completely ignore CipherSuites, if the configuration has CipherSuites specified and a zero value is given for MaxVersion, the maximum version should be inferred as being TLS 1.2 (which would at least restore the previous behaviour without code change).
Your argument re TLS 1.3 cipher suites being completely separate from 1.2, also largely applies to previous versions of TLS - there are cipher suites that are TLS 1.2 only and cannot be used with TLS 1.0 or TLS 1.1, yet their configuration is via the same single mechanism. And when you say we automatically prefer the faster ones - the question is for who (there are situations where you may be willing to burn CPU cycles server-side to benefit some clients)?
if the configuration has CipherSuites specified and a zero value is given for MaxVersion, the maximum version should be inferred as being TLS 1.2
I agree that this is the only way to not change behavior at all, but in practice it would mean many applications which only set CipherSuites for performance or security reasons would find TLS 1.3 disabled by a subtle behavior. Also, it means that you must set MaxVersion to configure the TLS 1.2 cipher suites and still have TLS 1.3, which is confusing.
Instead, if one has contractual and compliance reasons to maintain the cipher suites values, I think it's reasonable to require them to also set MaxVersion.
PreferServerCipherSuites controls if the client or the server preference is prioritized.