crypto/tls: wrong private key used for SNI connections

[benburkert]

A client can use the server name indication TLS extension to specify the desired
hostname of the server certificate used in the TLS handshake. Go supports this SNI
extension in server connections with the tls.Config struct's NameToCertificate member
and BuildNameToCertificate function. These are used in the server connection's handshake
implementation to lookup a certificate which may not be the default certificate used by
the server. In such case, the key exchange functionality will still use the default
certificate's private key.

The linked code sample demonstrates this problem when the client recieve a "remote
error: bad record MAC" error during handshake. The included patch fixes this error
by keeping track of the non-default certificate's private key in the key exchange struct.

What steps will reproduce the problem?

https://gist.github.com/2151037

go run sni_test.go

What is the expected output?

the program should exit 0

What do you see instead?

a "remote error: bad record MAC" panic

Which compiler are you using (5g, 6g, 8g, gccgo)?

6g

Which operating system are you using?

OSX

Which revision are you using?  (hg identify)

15a98eba66e0

Please provide any additional information below.

[benburkert]

Comment 1:

It appears that the same problem (always using config.Certificates[0] as the
certificate) affects the OCSP stapling functionality, but i have not verified this. I'm
working on patch with with a fix & test for this as well.

[agl]

Comment 3:

Yea, we do indeed use the wrong private key. Nobody has tried using SNI support before
because not enough client support it, but we should fix it none the less.
But I'll wait until after the initial Go 1 release.

Labels changed: added priority-later, packagebug, removed priority-triage.

Owner changed to @agl.

Status changed to Accepted.

[benburkert]

Comment 4:

in that case, would you consider removing and/or deprecating the server implementation
of SNI before 1.0? The existing API is inelegant and diverges from the pattern
implemented in OpenSSL and followed by other languages.

[agl]

Comment 5:

What would you like the API to be? If the existing API worked as expected I believe that
it would cover most use cases.

[benburkert]

Comment 6:

I would like to see a callback based API that can change the tls.Config used per client.
Something similar to this: https://gist.github.com/2161321
I believe this could be further simplified by removing tls.Config.NameToCertificate and
tls.Config.BuildNameToCertificate, and switching tls.Config.Certificates back to
tls.Config.Certificate tls.Certificate.
This would be more inline with OpenSSL's SSL_CTX_set_tlsext_servername_callback API
where the callback can return a SSL_CTX (analogous to tls.Config) or null, in which case
it uses the existing SSL_CTX.

[agl]

Comment 7:

There are plenty of odd cases where a callback can be nice (enabling client auth only on
some hostnames etc), but the crypto libraries deliberately only aim to solve the 90%
case. And I think the 90% case is that you have several certificates on the same IP and
want to serve the right one.
That doesn't preclude adding the callback in the future, but it would need a firm reason.
If you're doing something odd then there's no shame in forking the code.

[benburkert]

Comment 8:

very true, thanks for the quick response!

[agl]

Comment 9:

This issue was closed by revision e6e8b72.

Status changed to Fixed.

[agl]

Comment 10:

This issue was closed by revision 018462b9df95.