4 ms·

If you encounter such a program that requires PreferServerCipherSuites to run correctly, please open an issue and we’ll look into it as a potential regression.

If you encounter such a program that requires PreferServerCipherSuites to run correctly, please open an issue and we’ll look into it as a potential regression. More in general, it’s unavoidable for packages that implement living protocols like TLS and HTTP to have a higher level concept of backwards compatibility: if the wire behavior of the package were to never change, Go would soon stop working with most of the ecosystem, and wouldn’t implement the likes of HTTP/2 and TLS 1.3. Many standard libraries went that way, and ended up less useful and safe.

TheDong 5y ago
I don't know of any programs that will break from this specific change, though I will be unsurprising if some exist. I agree that the http and tls packages have made frequent changes that are technically exceptions to the go1compat promises, where there are changes that are technically breaking, but are "in spirit" with the intent of the package. I agree that it's unavoidable to change them over time in this way. The reality of this has been that http-related changes semi-frequently break my programs when I update go versions. To me, the fact that http and tls are living protocols is an argument for them being separate versioned modules (i.e. golang.orx/x/net/http), not that we should be causing breaking changes and hand-waving it as being an improvement. Other packages, like os, sync, etc, have remained stable, and I have no issue with those being versioned alongside the go distribution. For packages like http and tls, that have made frequent breaking changes, it does seem like they should have been deprecated and replaced with either golang.org/x/vX/net/http, or some in-stdlib-versioned-thing. Why not deprecate crypto/tls and move it out of the stdlib such that users can get benefits of updating the compiler without the risk of code breakage? It also seems like a benefit that users could then consume crypto/tls updates on a faster cadence without needing go point releases.
- FiloSottile 5y ago
  That’s generally something that might be desirable for a number of reasons but it’s an extremely delicate change because of how stdlib packages import each other, and how types from x/ repos vendored back into the stdlib are not compatible with the original ones. You quickly have to ask questions like “do we let the main module upgrade the version of x/ repos used by the stdlib?” Maybe eventually we’ll find a way to do this cleanly and decide to do it, but large changes like this take time.
- deleted 5y ago
  [deleted]
mike_d 5y ago
This change will break my (and others) scanning the internet and enumerating supported cipher suites and server behavior. At least other footguns in Go are stuck into unsafe or something similar. Completely removing it will just force people to maintain local forks.
- tptacek 5y ago
  It's already pretty common for people using Go's (excellent) TLS library for scanners to fork it; it's probably what you should do, because there's lots of opportunity for instrumentation that the library easily hosts but doesn't provide out of the box.
- FiloSottile 5y ago
  My first intuition for how to do that would be to only enable one cipher suite at a time, which still works with this change. Still, do feel welcome to open an issue, I can’t promise any specific outcome but we’ll look at it. I’ll mention that we had to ignore the requirements of diagnostic and scanning tools in the past, and you might be better served by a fork like BoGo from the BoringSSL test suite. Fundamentally, what an application wants (“make a secure connection”) is at odds with what a test tool wants (“make a connection potentially broken in one of a thousand different ways, and tell me how it went”).
- Thorrez 5y ago
  Are you already lacking the ability to scan TLS 1.3 ciphers? Because it sounds like Go never provided the ability to order them.
arthur2e5 5y ago
I vaguely recall go’s safe but unusual TLS cipher suite default being one of v2ray’s early flaws. V2ray was a tunnel designed to look like normal HTTPS traffic to censors, and they were getting very easily sniffed out until they copied the suite preference from a popular browser. https://github.com/v2ray/discussion/issues/704 https://github.com/v2ray/discussion/issues/704 is the actual issue; my memory could be wrong.

TheDong 5y ago

I don't know of any programs that will break from this specific change, though I will be unsurprising if some exist. I agree that the http and tls packages have made frequent changes that are technically exceptions to the go1compat promises, where there are changes that are technically breaking, but are "in spirit" with the intent of the package. I agree that it's unavoidable to change them over time in this way. The reality of this has been that http-related changes semi-frequently break my programs when I update go versions. To me, the fact that http and tls are living protocols is an argument for them being separate versioned modules (i.e. golang.orx/x/net/http), not that we should be causing breaking changes and hand-waving it as being an improvement. Other packages, like os, sync, etc, have remained stable, and I have no issue with those being versioned alongside the go distribution. For packages like http and tls, that have made frequent breaking changes, it does seem like they should have been deprecated and replaced with either golang.org/x/vX/net/http, or some in-stdlib-versioned-thing. Why not deprecate crypto/tls and move it out of the stdlib such that users can get benefits of updating the compiler without the risk of code breakage? It also seems like a benefit that users could then consume crypto/tls updates on a faster cadence without needing go point releases.

FiloSottile 5y ago
That’s generally something that might be desirable for a number of reasons but it’s an extremely delicate change because of how stdlib packages import each other, and how types from x/ repos vendored back into the stdlib are not compatible with the original ones. You quickly have to ask questions like “do we let the main module upgrade the version of x/ repos used by the stdlib?” Maybe eventually we’ll find a way to do this cleanly and decide to do it, but large changes like this take time.
deleted 5y ago
[deleted]

mike_d 5y ago

This change will break my (and others) scanning the internet and enumerating supported cipher suites and server behavior. At least other footguns in Go are stuck into unsafe or something similar. Completely removing it will just force people to maintain local forks.

tptacek 5y ago
It's already pretty common for people using Go's (excellent) TLS library for scanners to fork it; it's probably what you should do, because there's lots of opportunity for instrumentation that the library easily hosts but doesn't provide out of the box.
FiloSottile 5y ago
My first intuition for how to do that would be to only enable one cipher suite at a time, which still works with this change. Still, do feel welcome to open an issue, I can’t promise any specific outcome but we’ll look at it. I’ll mention that we had to ignore the requirements of diagnostic and scanning tools in the past, and you might be better served by a fork like BoGo from the BoringSSL test suite. Fundamentally, what an application wants (“make a secure connection”) is at odds with what a test tool wants (“make a connection potentially broken in one of a thousand different ways, and tell me how it went”).
Thorrez 5y ago
Are you already lacking the ability to scan TLS 1.3 ciphers? Because it sounds like Go never provided the ability to order them.

arthur2e5 5y ago

I vaguely recall go’s safe but unusual TLS cipher suite default being one of v2ray’s early flaws. V2ray was a tunnel designed to look like normal HTTPS traffic to censors, and they were getting very easily sniffed out until they copied the suite preference from a popular browser. https://github.com/v2ray/discussion/issues/704 https://github.com/v2ray/discussion/issues/704 is the actual issue; my memory could be wrong.