go: crypto/tls: connecting to the registry.fedoraproject.org fails in tls

What version of Go are you using (`go version`)?

go1.12(with GODEBUG=tls13=1), go1.13rc2 and master

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (`go env`)?

linux/*

What did you do?

Originally pulling container images with podman built with go1.13beta. Run Go side reproducer(based on @cverna 's reproducer , thanks!) https://play.golang.org/p/dbRRM9-GdI0 .

I don’t believe that this is issue on the side of the registry.fedoraproject.org as other tls1.3 implementations(used by browsers, curl) work just fine, but I don’t have yet reduced server side reproducer/trigger. This can be worked-around by reverting to the go1.12 behavior(not enabling tls1.3 by default or GODEBUG=tls13=0).

For the record this got reported and is tracked in Fedora as https://bugzilla.redhat.com/show_bug.cgi?id=1737471

What did you expect to see?

Successful “get”.

What did you see instead?

<nil>
Get https://registry.fedoraproject.org/v2/fedora/manifests/latest: local error: tls: unexpected message

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 15 (10 by maintainers)

Most upvoted comments

The server is misbehaving here, I’m afraid. In the CertificateRequest message, it’s sending a status_request extension with 475 bytes, when it should be empty. You can see Wireshark also flagging this as an issue.

crypto/tls is seeing those extra bytes and rejecting the message. See RFC 8446, Section 4.4.2.1.

   A server MAY request that a client present an OCSP response with its
   certificate by sending an empty "status_request" extension in its
   CertificateRequest message.

The extraneous bytes are identical to the contents of the Certificate’s status_request extension, so my guess here is that there’s a bug in the server’s TLS stack where it sets the content of status_request globally for the connection, and ends up sending it also in CertificateRequest where it should be empty (because it’s a request for the client’s response). CertificateRequest extensions are new in TLS 1.3.

The server is not possibly a Go server, because it supports DHE ciphersuites which we don’t implement. Can you please find out what TLS stack the server is using, update if a fix is available, and report this upstream otherwise?

We try really hard not to introduce exceptions to tolerate misbehavior, but we’ll consider it based on how widespread this implementation bug is.

+11

FiloSottile on Sep 4, 2019

Skimming OpenSSL’s source, this looks like a bug in OpenSSL. Adding @mattcaswell to confirm. The status_request extension has flags for both the Certificate and CertificateRequest message: https://github.com/openssl/openssl/blob/bc5a80910dccbc1e417f96bb7f0a3814d3ad5a4d/ssl/statem/extensions.c#L213

However, the construction callback does not check context and appears to just send it in both. https://github.com/openssl/openssl/blob/bc5a80910dccbc1e417f96bb7f0a3814d3ad5a4d/ssl/statem/extensions_srvr.c#L1490

Looks like the bug may have been introduced in https://github.com/openssl/openssl/commit/5de683d2c6ae2f8c30b97326e72ff19f41228b74. The client callbacks was tweaked to ignore the extension in the CertificateRequest, but the server callback wasn’t fixed to handle the new context bits.

davidben on Sep 4, 2019

I can confirm this as an OpenSSL bug. I have managed to reproduce this behaviour using OpenSSL’s s_server and s_client tools. I have raised and OpenSSL issue to track this. Please see https://github.com/openssl/openssl/issues/9767

mattcaswell on Sep 4, 2019