crypto/tls: "unexpected message" when CT extension enabled with no SCTs

[woodsaj]

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

all since go1.5

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

all

What did you do?

Try and negotiate a TLS connection with a server that has Certificate Transparency TLS extension enabled but provides no signed certificate timestamps

What did you expect to see?

The TLS handshake to succeed.

What did you see instead?

Error: "local error: tls: unexpected message"

[woodsaj]

https://github.com/golang/go/blob/master/src/crypto/tls/handshake_messages.go#L809

By calling "continue" the byte slice "data" is never reduced by the extension length. "break" should be called instead.

[gopherbot]

CL https://golang.org/cl/33265 mentions this issue.

[bradfitz]

To @agl for decision on what Go should do here.

[agl]

Where did you come across a server that returns an empty SCT list? The spec says that the list must not be empty, so it's actually something that should be rejected. The code, as is, will mostly reject it—albeit because of a bug. Thankfully the extension type and length are already sliced off so its not an infinite loop.

[woodsaj]

Had a user of one of our monitoring tools report that our tool was unable to connect to their site even though their site loaded correctly in browsers. I cant give you their site address without their permission, but the site referenced in #7953 (comment) is an example you can test with.

I believe that these sites are using https://github.com/grahamedgecombe/nginx-ct

I am not all familiar with this TLS feature, i just came across the handling bug after spending a big chunk of my day tracking down the cause of the vague "unexpected message" error. I assumed that the empty SCT list was valid as the sites loaded in the browser (Chrome) fine.

So though the Spec is explicit about the SCT list have at least 1 entry, perhaps the Go TLS library could be as forgiving as browsers.

[agl]

Thank you for the pointer. I'll see whether I can get nginx-ct fixed as the best approach here isn't to make Go more permissive but rather to fix the browsers to match.

[agl]

nginx-ct have produced a new release (1.3.2) which includes a fix for this.