Repository navigation
crypto/tls: TLS 1.3 ciphers are not configurable #29349
Description
What version of Go are you using (go version)?
go version devel +e3b4b7baad Tue Dec 18 23:01:06 2018 +0000 darwin/amd64
Does this issue reproduce with the latest release?
Yes if 1.12beta1 is the latest release.
What operating system and processor architecture are you using (go env)?
go env Output
GOARCH="amd64" GOBIN="" GOCACHE="/Users/crvv/Library/Caches/go-build" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOOS="darwin" GOPATH="/Users/crvv/Develop/go" GOPROXY="" GORACE="" GOROOT="/Users/crvv/Develop/goroot" GOTMPDIR="" GOTOOLDIR="/Users/crvv/Develop/goroot/pkg/tool/darwin_amd64" GCCGO="gccgo" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/x1/1pp78x6d3n99gpx9f7rz2_rh0000gn/T/go-build965128833=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
Run the following code with GODEBUG=http2server=0 go run main.go
package main
import (
"crypto/tls"
"log"
"net/http"
)
func main() {
server := http.Server{
Addr: "localhost:2443",
TLSConfig: &tls.Config{
CipherSuites: []uint16{tls.TLS_CHACHA20_POLY1305_SHA256},
MinVersion: tls.VersionTLS13,
},
}
log.Fatal(server.ListenAndServeTLS("localhost.pem", "localhost-key.pem"))
}and openssl s_client -connect localhost:2443
What did you expect to see?
A TLS 1.3 connection with TLS_CHACHA20_POLY1305_SHA256 cipher.
What did you see instead?
SSL handshake has read 1603 bytes and written 391 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
It looks like Config.CipherSuites isn't used in TLS 1.3.
If this is the desired behavior, I think it should be documented in https://tip.golang.org/pkg/crypto/tls/
Activity
agnivade commentedon Dec 20, 2018
From the release notes -
crvv commentedon Dec 20, 2018
I understand the reason to make it not configurable.
But there are only two kinds of CipherSuites.
and
That is to say, if the server and client are both written in Go,
TLS_AES_256_GCM_SHA384can never be used, which I think is kind of strange.Besides the documentation, I think this can be reconsidered or maybe
tls.Listenshould return an error ifConfig.CipherSuitescontains TLS 1.3 ciphers.agnivade commentedon Dec 20, 2018
/cc @FiloSottile
ulikunitz commentedon Dec 20, 2018
The TLS 1.3 implementation should at least allow the developer to select cipher suites from the supported set of cipher suites and change the priority of the supported cipher suites.
Why? It is obvious that the security assessment of the ciphers defined by TLS 1.3 might change. I'm old enough to know that SHA1 was the recommended hash algorithm for quite some time. Allowing the developer to exclude an algorithm gives him a chance to react for instance to meet internal compliance requirements while the cipher suite must still be supported in general to support users with legacy software.
The capability to mask interoperability issues with another TLS implementation instantly, is another reason to provide developers with the capability to change priorities of the supported algorithms.
[-]crypto/tls: Config.CipherSuites doesn't work for TLS 1.3[/-][+]crypto/tls: reject TLS 1.3 ciphers in Config.CipherSuites[/+]FiloSottile commentedon Dec 20, 2018
Configuration is necessary if the ecosystem has issues that require manual mitigation. The TLS 1.3 ecosystem thankfully doesn't yet, so until it's necessary we will not add a config option. Cipher suites happen to be something that required configuration in TLS 1.2, but by the argument that everything should be configurable in case it becomes necessary later, there are half a dozen axes in TLS 1.3 (cipher suites, groups, signature algorithms, certificate signature algorithms, PSK modes...) and we are not adding a config option for each.
Returning an error if
Config.CipherSuitescontains TLS 1.3 ciphers sounds like a good idea, though.ulikunitz commentedon Dec 21, 2018
Yes, the usage of cryptogragraphic methods must be configurable. Beside the two reasons, change of security assessment of a cryptographic algorithm and handling of interoperability issues, I have already given, there is a third one: compliance to government or internal policies. Such a policy might forbid ChaCha20, because the algorithm is not supported by government standards. How does a developer address such a requirement?
Not everybody shares your assessment that ciphers in TLS 1.3 have no issues. Dan Bernstein and Tanja Lange regard P256 as unsafe as documented in https://safecurves.cr.yp.to/. Apparently the Go implementation shares that assessment, because it prefers X25519 over P256. Burt what about developers that want to disable P256 completely?
FiloSottile commentedon Jan 17, 2019
@ulikunitz curves have nothing to do with cipher suites in TLS 1.3.
tls.Listen-time check are probably not worth it (#29779 (comment)) so I'm going to add a note to theConfig.CipherSuitesdocs, and close this.gopherbot commentedon Jan 18, 2019
Change https://golang.org/cl/158637 mentions this issue:
crypto/tls: expand Config.CipherSuites docsulikunitz commentedon Jan 19, 2019
@FiloSottile
Let me write at first that I'm aware that you were deeply involved in the development of TLS 1.3. I watched your presentation at the Chaos Communication Congress regarding it. I appreciate the work you put in the development in the new algorithm specifically the work on TLS 1.3.
Let me clarify the point regarding P265. In my opinion every TLS implementation should at least provide the capability to disable any cryptographic algorithm for which there are multiple alternatives available independent how they are negotiated in the protocol. So my ask is actually independent of the cipher suites.
The rationale is:
A lot of organisations have policies in place that define the set of algorithms including important parameters like key lengths that can be supported in the organisation. Not providing a capability to disable certain algorithms will create issues for the use of the Go language in those organisations.
In the practice there are issues for specific algorithms in TLS implementations. We observe regularly TLS connection resets at a rate of ca. 1/3000 in our production environment with Oracle's Java implementation of ECDHE for TLS 1.2. Since Java supports the disablement of crypto algorithms for TLS, we are able to work around the issue until it can be resolved with Oracle.
In the case of the identification of a vulnerability or general cryptographic problem of the TLS 1.3 Golang implementation there is only the option of updating the software. In my experience a software update triggers more dependencies and requires more testing effort then a software configuration change. The time frame differs here between minutes to sevaral hours for the configuration change and days to weeks for the software update.
Since I'm not providing patches to do what I see as necessary, I will stop discussing the point any further. I'm convinced that you and I want the best for the Golang community while we disagree that this
includes configurability of the cryptographic algorithms for the Golang TLS 1.3 implementation.
kopax commentedon Dec 25, 2019
I am having issue reverse proxying https with traefik v2.1.0, I have
TLS_AES_128_GCM_SHA256error.This prevent me from running sonarqube 6.3.1 test, do you guys know how I can fix this ?
Thanks and merry Christmas
12 remaining items
FiloSottile commentedon Jun 7, 2020
The same as with every decision: present a case for why and how adding this configuration option is beneficial and necessary for common, reasonable users, and consistent with https://golang.org/design/cryptography-principles. (And, I mean, of course Oreo.)
So far, the two arguments here have been: compliance with policies (requiring AES-256), which we tend to heavily discount especially when they add complexity for no coherent security benefit (which AES-256 doesn't have #29349 (comment)); and agility in the face of hypothetical security or compatibility issues, which is definitely an anti-goal of the Go cryptography libraries where we believe it's the job of the library, not the developer, to figure out the intricacies of the TLS ecosystem, and which would be an argument to make every single negotiated list of codepoints configurable (of which there are half a dozen).
ulikunitz commentedon Jun 8, 2020
I have to correct the statement regarding the CockroachDB issue. It is caused by #35722, which isn't related to a cipher implementation, so a cipher configuration option would not have helped.
bwesterb commentedon Jun 10, 2020
With regards to the quantum argument: we expect AES 128 to be secure for a long time after the first RSA and elliptic curves keys have been broken by quantum computers. The reason is that Grover's algorithm has a long runtime which requires immense error correction (and thus additional qubits).
jared2501 commentedon Aug 25, 2020
Just flagging that we've had to disable Go's TLS 1.3 implementation at my work since our software is deployed by government agencies that require us to run FIPS 140-2 compliant crypto algorithms (i.e. RSA, ECDSA, & AES). While I agree that reducing configurability in the name of reducing complexity is laudable, it does lock out entire classes of users (namely, government & financial ones).
@FiloSottile I doubt that you would consider the ability for TLS 1.3 to grow a "FIPS mode" option that would restrict the negotiated algorithms (i.e. rather than making them fully configurable)? I suppose the answer for users wanting FIPS compliant crypto is to run https://github.com/golang/go/tree/dev.boringcrypto?
p-kraszewski commentedon Aug 25, 2020
Following @jared2501 comment, to the powers-to-be of Go crypto systems. Please understand. We are programmers and developers working in predefined environment. We don't set rules, we don't set requirements, we don't have any influence on any of those aspects. We are expected to comply.
If Go people wish to discuss security requirements with government officials, I suppose we would be able to provide contacts to some of their secretaries. But please, make a podcast of the talk and give us an hour earlier notice to let us all buy cola and popcorn to watch the show.
There are few industries (mil, gov, med, fintech, automotive) where you either comply or GTFO. And if Golang is fine with GTFO, it is sad news for us, developers writing in Go.
FiloSottile commentedon Aug 25, 2020
Correct. By my understanding of FIPS 140, selecting ciphersuites is not nearly enough for compliance at any level.
ericlagergren commentedon Aug 25, 2020
jared2501 commentedon Aug 25, 2020
Yeah, there's a difference between "FIPS validated" and "FIPS compliant" - for "FIPS compliant", your ciphersuite selection is enough.
crvv commentedon Aug 26, 2020
I don't think the minority can be ignored here.
You shouldn't discriminate against those programs running in government.
FiloSottile commentedon Aug 26, 2020
Can you point me to somewhere I can read more? I never heard of that interpretation. AFAIK, TLS 1.3 itself is not FIPS 140-2 compliant.
Rather than commenting on a closed issue, what would work here would be to open a new one about a use case (not about a specific solution) with supporting information to show what the requirements are like and how common they are. They don't need to be the majority, but they need to be concrete and achievable and different from the BoringCrypto ones.
Run tests with a newer version of Go
Run tests with a newer version of Go