crypto/tls: TLS 1.3 with tls.RequireAndVerifyClientCert not work with mac os 10.12 and chrome 71 at tip #29831
Comments
bronze1man
changed the title
|
/cc @FiloSottile |
bradfitz
changed the title
bradfitz
added
the
NeedsInvestigation
|
@bronze1man What's the certificate key type and bit size? If it's an RSA certificate with a 512-bit key, it's not supported by TLS 1.3 at the protocol level. Otherwise, it would be useful if you could post the certificate details here. |
FiloSottile
added
the
WaitingForInfo
|
@FiloSottile thanks
My self signed CA and client certificate is created with golang x509.CreateCertificate with 4th argument rsa 2048bit public key, and 5th argument rsa 2048bit private key. As the tls1.3 with tls.RequireAndVerifyClientCert is work in mac os 10.13.6 and chrome 71. I do not think the certificate key type and bit size is the problem. Plus:
|
andybons
removed
the
WaitingForInfo
|
Client certificates worked correctly with Chrome 72 and macOS 10.14, and the following code: https://play.golang.org/p/hGgDNOal0XK What I think is going on is that macOS 10.12 does not support RSA-PSS, which is required by TLS 1.3. I don't have a Sierra machine to confirm, but the This is consistent with everything you mentioned: it works on 10.13 because they added RSA-PSS, it works with TLS 1.2 because it doesn't require RSA-PSS, it works with Safari because on Sierra it doesn't do TLS 1.3, and it works without That means you just can't have browser client certificates and TLS 1.3 on Sierra. We also can't detect the case and disable TLS 1.3 automatically because that would introduce a downgrade vulnerability for all clients, and Chrome would kill the connection upon seeing the downgrade canary (search for "downgrade" in Section 4.1.3). (Unless of course we turned the canary off, but that would defeat a major security property of TLS 1.3, and no other TLS library plans to do that long term.) |
|
@FiloSottile Is it ok for newer version of chrome to do not use tls 1.3 and ClientCert on mac version 10.12 ? Will this kind of work around be a big security problem? |
|
That would be a tradeoff decision for the Chrome team, as then any attacker that wants to downgrade a connection could ask for a client certificate, and it would require cancelling the TLS 1.3 handshake and restarting. You can raise it with them in their issue tracker if you want. |
|
Change https://golang.org/cl/160998 mentions this issue: |
Most of the issues that led to the decision on #30055 were related to incompatibility with or faulty support for RSA-PSS (#29831, #29779, v1.5 signatures). RSA-PSS is required by TLS 1.3, but is also available to be negotiated in TLS 1.2. Altering TLS 1.2 behavior based on GODEBUG=tls13=1 feels surprising, so just disable RSA-PSS entirely in TLS 1.2 until TLS 1.3 is on by default, so breakage happens all at once. Updates #30055 Change-Id: Iee90454a20ded8895e5302e8bcbcd32e4e3031c2 Reviewed-on: https://go-review.googlesource.com/c/160998 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
Most of the issues that led to the decision on golang#30055 were related to incompatibility with or faulty support for RSA-PSS (golang#29831, golang#29779, v1.5 signatures). RSA-PSS is required by TLS 1.3, but is also available to be negotiated in TLS 1.2. Altering TLS 1.2 behavior based on GODEBUG=tls13=1 feels surprising, so just disable RSA-PSS entirely in TLS 1.2 until TLS 1.3 is on by default, so breakage happens all at once. Updates golang#30055 Change-Id: Iee90454a20ded8895e5302e8bcbcd32e4e3031c2 Reviewed-on: https://go-review.googlesource.com/c/160998 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
Most of the issues that led to the decision on golang#30055 were related to incompatibility with or faulty support for RSA-PSS (golang#29831, golang#29779, v1.5 signatures). RSA-PSS is required by TLS 1.3, but is also available to be negotiated in TLS 1.2. Altering TLS 1.2 behavior based on GODEBUG=tls13=1 feels surprising, so just disable RSA-PSS entirely in TLS 1.2 until TLS 1.3 is on by default, so breakage happens all at once. Updates golang#30055 Change-Id: Iee90454a20ded8895e5302e8bcbcd32e4e3031c2 Reviewed-on: https://go-review.googlesource.com/c/160998 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
What version of Go are you using (
go version)?go version devel +5538a9a Fri Jan 18 22:41:47 2019 +0000 darwin/amd64
Does this issue reproduce with the latest release?
No. go1.11.4 is ok.
What operating system and processor architecture are you using (
go env)?GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/a/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/a/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/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/m9/qtbxkp6s3p96fk54rln7qhj80000gp/T/go-build776315368=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
Start a https server with
and a some custom ca and client cert.
And use a mac os 10.12 install the ca and client cert and use chrome 71 to view the website.
My code used to work from go1.9 and go1.11.4, but not work at the tip version of golang.
What did you expect to see?
The website can be viewed.
What did you see instead?
chrome says: ERR_SSL_CLIENT_AUTH_NO_COMMON_ALGORITHMS
workaround:
Force the tls version down to tls1.2 is working with mac os 10.12.
But tls1.3 is working with mac os 10.13.6 and chrome 71
The text was updated successfully, but these errors were encountered: