New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
crypto/tls: recent TLS 1.3 changes appear to break cases where client cert should be rejected #28779
Comments
The server is in fact rejecting the certificate here, but that error is being thrown out after being printed by your test. You can see the error logged in Travis.
Your test is checking the error on the client side instead of the server side. In TLS 1.2, there was a whole round-trip of handshake after sending the client cert, so the remote error was making it to the client in the form of an alert before The error will show up on the client first read. This is unavoidable, because the protocol is designed that way, but I can see it causing trouble. Hopefully relatively few users call |
@jhump BTW, thank you for that reproduction PR, it was extremely handy. |
@FiloSottile, will the server simply close the connection after it sees the cert is bad? If so, does that mean there is no way to distinguish, in the client, between the server rejecting the client's credentials and the server simply being partitioned from the client between the handshake and first read? I'm trying to figure out how to work around this: for command-line tools (such as One example: it means that using Anyhow. Sorry for the long-winded comment. I guess, summing up, I'm wondering if you have recommendations for providing better client-side error messages with TLS 1.3 in these situations. |
I do agree that it’s unfortunate, but I don’t have useful advice beyond what you already suggested. Note though that the server won’t just close the connection but send an alert, so the first client read will fail with the same meaningful error as the Handshake used to. |
Ok, that's useful actually. Thanks for the info. |
TLS 1.3 pushes detection of some client-side handshake errors to the time of the first read. For more details, see: golang/go#28779 (comment) Signed-off-by: Alain Jobart <alainjobart@google.com>
TLS 1.3 pushes detection of some client-side handshake errors to the time of the first read. For more details, see: golang/go#28779 (comment) Signed-off-by: Alain Jobart <alainjobart@google.com>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Nope, it's okay in release. It only repros with tip.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I have a test case that is verifying that a TLS client that uses a bad cert (either no cert, when server requires one, or an expired cert or one issued by untrusted CA) gets rejected by the server during a TLS handshake.
I've distilled it down to this test: fullstorydev/grpcurl#68
What did you expect to see?
Server should have rejected the client due to bad certificate.
This is what happens in every other Go version that I tested: https://travis-ci.org/fullstorydev/grpcurl/builds/454615565
What did you see instead?
Server accepted the client.
If I set
MaxVersion
on the server'stls.Config
totls.VersionTLS12
then things work as expected. So this appears to be related to the new TLS 1.3 work that landed yesterday.FYI: @FiloSottile
The text was updated successfully, but these errors were encountered: