2010-12-16 22:10:50 +00:00
|
|
|
// Copyright 2010 The Go Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
|
|
package tls
|
|
|
|
|
|
|
|
import (
|
2011-02-01 16:02:48 +00:00
|
|
|
"crypto"
|
2013-07-17 17:33:16 +01:00
|
|
|
"crypto/ecdsa"
|
2010-12-16 22:10:50 +00:00
|
|
|
"crypto/elliptic"
|
|
|
|
"crypto/md5"
|
|
|
|
"crypto/rsa"
|
|
|
|
"crypto/sha1"
|
|
|
|
"crypto/x509"
|
2013-07-17 17:33:16 +01:00
|
|
|
"encoding/asn1"
|
2011-11-02 02:04:37 +00:00
|
|
|
"errors"
|
2010-12-16 22:10:50 +00:00
|
|
|
"io"
|
2011-11-08 23:40:58 +00:00
|
|
|
"math/big"
|
2016-10-11 02:23:37 +01:00
|
|
|
|
|
|
|
"golang_org/x/crypto/curve25519"
|
2010-12-16 22:10:50 +00:00
|
|
|
)
|
|
|
|
|
2014-02-12 16:20:01 +00:00
|
|
|
var errClientKeyExchange = errors.New("tls: invalid ClientKeyExchange message")
|
|
|
|
var errServerKeyExchange = errors.New("tls: invalid ServerKeyExchange message")
|
|
|
|
|
2010-12-16 22:10:50 +00:00
|
|
|
// rsaKeyAgreement implements the standard TLS key agreement where the client
|
|
|
|
// encrypts the pre-master secret to the server's public key.
|
|
|
|
type rsaKeyAgreement struct{}
|
|
|
|
|
2012-04-12 17:35:21 +01:00
|
|
|
func (ka rsaKeyAgreement) generateServerKeyExchange(config *Config, cert *Certificate, clientHello *clientHelloMsg, hello *serverHelloMsg) (*serverKeyExchangeMsg, error) {
|
2010-12-16 22:10:50 +00:00
|
|
|
return nil, nil
|
|
|
|
}
|
|
|
|
|
2012-04-12 17:35:21 +01:00
|
|
|
func (ka rsaKeyAgreement) processClientKeyExchange(config *Config, cert *Certificate, ckx *clientKeyExchangeMsg, version uint16) ([]byte, error) {
|
2010-12-16 22:10:50 +00:00
|
|
|
if len(ckx.ciphertext) < 2 {
|
2014-02-12 16:20:01 +00:00
|
|
|
return nil, errClientKeyExchange
|
2010-12-16 22:10:50 +00:00
|
|
|
}
|
2011-09-14 20:32:19 +01:00
|
|
|
|
|
|
|
ciphertext := ckx.ciphertext
|
2013-06-05 01:02:22 +01:00
|
|
|
if version != VersionSSL30 {
|
2011-09-14 20:32:19 +01:00
|
|
|
ciphertextLen := int(ckx.ciphertext[0])<<8 | int(ckx.ciphertext[1])
|
|
|
|
if ciphertextLen != len(ckx.ciphertext)-2 {
|
2014-02-12 16:20:01 +00:00
|
|
|
return nil, errClientKeyExchange
|
2011-09-14 20:32:19 +01:00
|
|
|
}
|
|
|
|
ciphertext = ckx.ciphertext[2:]
|
2010-12-16 22:10:50 +00:00
|
|
|
}
|
2015-03-19 11:01:57 +00:00
|
|
|
priv, ok := cert.PrivateKey.(crypto.Decrypter)
|
|
|
|
if !ok {
|
|
|
|
return nil, errors.New("tls: certificate private key does not implement crypto.Decrypter")
|
|
|
|
}
|
2015-06-11 14:49:38 +01:00
|
|
|
// Perform constant time RSA PKCS#1 v1.5 decryption
|
2015-03-19 11:01:57 +00:00
|
|
|
preMasterSecret, err := priv.Decrypt(config.rand(), ciphertext, &rsa.PKCS1v15DecryptOptions{SessionKeyLen: 48})
|
2010-12-16 22:10:50 +00:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2016-03-01 23:21:55 +00:00
|
|
|
// We don't check the version number in the premaster secret. For one,
|
2010-12-16 22:10:50 +00:00
|
|
|
// by checking it, we would leak information about the validity of the
|
|
|
|
// encrypted pre-master secret. Secondly, it provides only a small
|
|
|
|
// benefit against a downgrade attack and some implementations send the
|
|
|
|
// wrong version anyway. See the discussion at the end of section
|
|
|
|
// 7.4.7.1 of RFC 4346.
|
|
|
|
return preMasterSecret, nil
|
|
|
|
}
|
|
|
|
|
2011-11-02 02:04:37 +00:00
|
|
|
func (ka rsaKeyAgreement) processServerKeyExchange(config *Config, clientHello *clientHelloMsg, serverHello *serverHelloMsg, cert *x509.Certificate, skx *serverKeyExchangeMsg) error {
|
2014-02-12 16:20:01 +00:00
|
|
|
return errors.New("tls: unexpected ServerKeyExchange")
|
2010-12-16 22:10:50 +00:00
|
|
|
}
|
|
|
|
|
2011-11-02 02:04:37 +00:00
|
|
|
func (ka rsaKeyAgreement) generateClientKeyExchange(config *Config, clientHello *clientHelloMsg, cert *x509.Certificate) ([]byte, *clientKeyExchangeMsg, error) {
|
2010-12-16 22:10:50 +00:00
|
|
|
preMasterSecret := make([]byte, 48)
|
|
|
|
preMasterSecret[0] = byte(clientHello.vers >> 8)
|
|
|
|
preMasterSecret[1] = byte(clientHello.vers)
|
|
|
|
_, err := io.ReadFull(config.rand(), preMasterSecret[2:])
|
|
|
|
if err != nil {
|
|
|
|
return nil, nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
encrypted, err := rsa.EncryptPKCS1v15(config.rand(), cert.PublicKey.(*rsa.PublicKey), preMasterSecret)
|
|
|
|
if err != nil {
|
|
|
|
return nil, nil, err
|
|
|
|
}
|
|
|
|
ckx := new(clientKeyExchangeMsg)
|
|
|
|
ckx.ciphertext = make([]byte, len(encrypted)+2)
|
|
|
|
ckx.ciphertext[0] = byte(len(encrypted) >> 8)
|
|
|
|
ckx.ciphertext[1] = byte(len(encrypted))
|
|
|
|
copy(ckx.ciphertext[2:], encrypted)
|
|
|
|
return preMasterSecret, ckx, nil
|
|
|
|
}
|
|
|
|
|
2013-07-17 17:33:16 +01:00
|
|
|
// sha1Hash calculates a SHA1 hash over the given byte slices.
|
|
|
|
func sha1Hash(slices [][]byte) []byte {
|
|
|
|
hsha1 := sha1.New()
|
|
|
|
for _, slice := range slices {
|
|
|
|
hsha1.Write(slice)
|
|
|
|
}
|
|
|
|
return hsha1.Sum(nil)
|
|
|
|
}
|
|
|
|
|
2010-12-16 22:10:50 +00:00
|
|
|
// md5SHA1Hash implements TLS 1.0's hybrid hash function which consists of the
|
|
|
|
// concatenation of an MD5 and SHA1 hash.
|
2013-07-03 00:58:56 +01:00
|
|
|
func md5SHA1Hash(slices [][]byte) []byte {
|
2010-12-16 22:10:50 +00:00
|
|
|
md5sha1 := make([]byte, md5.Size+sha1.Size)
|
|
|
|
hmd5 := md5.New()
|
|
|
|
for _, slice := range slices {
|
|
|
|
hmd5.Write(slice)
|
|
|
|
}
|
2011-12-01 17:35:37 +00:00
|
|
|
copy(md5sha1, hmd5.Sum(nil))
|
2013-07-17 17:33:16 +01:00
|
|
|
copy(md5sha1[md5.Size:], sha1Hash(slices))
|
2010-12-16 22:10:50 +00:00
|
|
|
return md5sha1
|
|
|
|
}
|
|
|
|
|
2013-07-03 00:58:56 +01:00
|
|
|
// hashForServerKeyExchange hashes the given slices and returns their digest
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
// and the identifier of the hash function used. The sigAndHash argument is
|
|
|
|
// only used for >= TLS 1.2 and precisely identifies the hash function to use.
|
|
|
|
func hashForServerKeyExchange(sigAndHash signatureAndHash, version uint16, slices ...[]byte) ([]byte, crypto.Hash, error) {
|
2013-07-03 00:58:56 +01:00
|
|
|
if version >= VersionTLS12 {
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
if !isSupportedSignatureAndHash(sigAndHash, supportedSignatureAlgorithms) {
|
|
|
|
return nil, crypto.Hash(0), errors.New("tls: unsupported hash function used by peer")
|
2013-10-21 21:35:09 +01:00
|
|
|
}
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
hashFunc, err := lookupTLSHash(sigAndHash.hash)
|
|
|
|
if err != nil {
|
|
|
|
return nil, crypto.Hash(0), err
|
|
|
|
}
|
|
|
|
h := hashFunc.New()
|
|
|
|
for _, slice := range slices {
|
|
|
|
h.Write(slice)
|
|
|
|
}
|
|
|
|
digest := h.Sum(nil)
|
|
|
|
return digest, hashFunc, nil
|
2013-07-03 00:58:56 +01:00
|
|
|
}
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
if sigAndHash.signature == signatureECDSA {
|
2013-10-21 21:35:09 +01:00
|
|
|
return sha1Hash(slices), crypto.SHA1, nil
|
2013-07-17 17:33:16 +01:00
|
|
|
}
|
2013-10-21 21:35:09 +01:00
|
|
|
return md5SHA1Hash(slices), crypto.MD5SHA1, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// pickTLS12HashForSignature returns a TLS 1.2 hash identifier for signing a
|
|
|
|
// ServerKeyExchange given the signature type being used and the client's
|
2014-05-02 21:17:55 +01:00
|
|
|
// advertised list of supported signature and hash combinations.
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
func pickTLS12HashForSignature(sigType uint8, clientList []signatureAndHash) (uint8, error) {
|
|
|
|
if len(clientList) == 0 {
|
2013-10-21 21:35:09 +01:00
|
|
|
// If the client didn't specify any signature_algorithms
|
|
|
|
// extension then we can assume that it supports SHA1. See
|
|
|
|
// http://tools.ietf.org/html/rfc5246#section-7.4.1.4.1
|
|
|
|
return hashSHA1, nil
|
|
|
|
}
|
|
|
|
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
for _, sigAndHash := range clientList {
|
2013-10-21 21:35:09 +01:00
|
|
|
if sigAndHash.signature != sigType {
|
|
|
|
continue
|
|
|
|
}
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
if isSupportedSignatureAndHash(sigAndHash, supportedSignatureAlgorithms) {
|
2013-10-21 21:35:09 +01:00
|
|
|
return sigAndHash.hash, nil
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0, errors.New("tls: client doesn't support any common hash functions")
|
2013-07-03 00:58:56 +01:00
|
|
|
}
|
|
|
|
|
2014-02-24 22:57:51 +00:00
|
|
|
func curveForCurveID(id CurveID) (elliptic.Curve, bool) {
|
|
|
|
switch id {
|
|
|
|
case CurveP256:
|
|
|
|
return elliptic.P256(), true
|
|
|
|
case CurveP384:
|
|
|
|
return elliptic.P384(), true
|
|
|
|
case CurveP521:
|
|
|
|
return elliptic.P521(), true
|
|
|
|
default:
|
|
|
|
return nil, false
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2010-12-16 22:10:50 +00:00
|
|
|
// ecdheRSAKeyAgreement implements a TLS key agreement where the server
|
2017-09-15 02:24:47 +01:00
|
|
|
// generates an ephemeral EC public/private key pair and signs it. The
|
2013-07-17 17:33:16 +01:00
|
|
|
// pre-master secret is then calculated using ECDH. The signature may
|
|
|
|
// either be ECDSA or RSA.
|
|
|
|
type ecdheKeyAgreement struct {
|
2013-07-03 00:58:56 +01:00
|
|
|
version uint16
|
2013-07-17 17:33:16 +01:00
|
|
|
sigType uint8
|
2010-12-16 22:10:50 +00:00
|
|
|
privateKey []byte
|
2016-10-11 02:23:37 +01:00
|
|
|
curveid CurveID
|
|
|
|
|
|
|
|
// publicKey is used to store the peer's public value when X25519 is
|
|
|
|
// being used.
|
|
|
|
publicKey []byte
|
|
|
|
// x and y are used to store the peer's public value when one of the
|
|
|
|
// NIST curves is being used.
|
|
|
|
x, y *big.Int
|
2010-12-16 22:10:50 +00:00
|
|
|
}
|
|
|
|
|
2013-07-17 17:33:16 +01:00
|
|
|
func (ka *ecdheKeyAgreement) generateServerKeyExchange(config *Config, cert *Certificate, clientHello *clientHelloMsg, hello *serverHelloMsg) (*serverKeyExchangeMsg, error) {
|
2014-02-24 22:57:51 +00:00
|
|
|
preferredCurves := config.curvePreferences()
|
|
|
|
|
|
|
|
NextCandidate:
|
|
|
|
for _, candidate := range preferredCurves {
|
|
|
|
for _, c := range clientHello.supportedCurves {
|
|
|
|
if candidate == c {
|
2016-10-11 02:23:37 +01:00
|
|
|
ka.curveid = c
|
2014-02-24 22:57:51 +00:00
|
|
|
break NextCandidate
|
|
|
|
}
|
2010-12-16 22:10:50 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-10-11 02:23:37 +01:00
|
|
|
if ka.curveid == 0 {
|
2012-03-23 14:48:51 +00:00
|
|
|
return nil, errors.New("tls: no supported elliptic curves offered")
|
|
|
|
}
|
|
|
|
|
2016-10-11 02:23:37 +01:00
|
|
|
var ecdhePublic []byte
|
2014-02-24 22:57:51 +00:00
|
|
|
|
2016-10-11 02:23:37 +01:00
|
|
|
if ka.curveid == X25519 {
|
|
|
|
var scalar, public [32]byte
|
|
|
|
if _, err := io.ReadFull(config.rand(), scalar[:]); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
curve25519.ScalarBaseMult(&public, &scalar)
|
|
|
|
ka.privateKey = scalar[:]
|
|
|
|
ecdhePublic = public[:]
|
|
|
|
} else {
|
|
|
|
curve, ok := curveForCurveID(ka.curveid)
|
|
|
|
if !ok {
|
|
|
|
return nil, errors.New("tls: preferredCurves includes unsupported curve")
|
|
|
|
}
|
|
|
|
|
|
|
|
var x, y *big.Int
|
|
|
|
var err error
|
|
|
|
ka.privateKey, x, y, err = elliptic.GenerateKey(curve, config.rand())
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
ecdhePublic = elliptic.Marshal(curve, x, y)
|
2010-12-16 22:10:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// http://tools.ietf.org/html/rfc4492#section-5.4
|
|
|
|
serverECDHParams := make([]byte, 1+2+1+len(ecdhePublic))
|
|
|
|
serverECDHParams[0] = 3 // named curve
|
2016-10-11 02:23:37 +01:00
|
|
|
serverECDHParams[1] = byte(ka.curveid >> 8)
|
|
|
|
serverECDHParams[2] = byte(ka.curveid)
|
2010-12-16 22:10:50 +00:00
|
|
|
serverECDHParams[3] = byte(len(ecdhePublic))
|
|
|
|
copy(serverECDHParams[4:], ecdhePublic)
|
|
|
|
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
sigAndHash := signatureAndHash{signature: ka.sigType}
|
|
|
|
|
2013-10-21 21:35:09 +01:00
|
|
|
if ka.version >= VersionTLS12 {
|
2016-10-11 02:23:37 +01:00
|
|
|
var err error
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
if sigAndHash.hash, err = pickTLS12HashForSignature(ka.sigType, clientHello.signatureAndHashes); err != nil {
|
2013-10-21 21:35:09 +01:00
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
digest, hashFunc, err := hashForServerKeyExchange(sigAndHash, ka.version, clientHello.random, hello.random, serverECDHParams)
|
2013-10-21 21:35:09 +01:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2015-03-19 11:01:57 +00:00
|
|
|
|
|
|
|
priv, ok := cert.PrivateKey.(crypto.Signer)
|
|
|
|
if !ok {
|
|
|
|
return nil, errors.New("tls: certificate private key does not implement crypto.Signer")
|
|
|
|
}
|
2013-07-17 17:33:16 +01:00
|
|
|
var sig []byte
|
|
|
|
switch ka.sigType {
|
|
|
|
case signatureECDSA:
|
2015-03-19 11:01:57 +00:00
|
|
|
_, ok := priv.Public().(*ecdsa.PublicKey)
|
2013-07-17 17:33:16 +01:00
|
|
|
if !ok {
|
2016-04-12 18:43:44 +01:00
|
|
|
return nil, errors.New("tls: ECDHE ECDSA requires an ECDSA server key")
|
2013-07-17 17:33:16 +01:00
|
|
|
}
|
|
|
|
case signatureRSA:
|
2015-03-19 11:01:57 +00:00
|
|
|
_, ok := priv.Public().(*rsa.PublicKey)
|
2013-07-17 17:33:16 +01:00
|
|
|
if !ok {
|
2016-04-12 18:43:44 +01:00
|
|
|
return nil, errors.New("tls: ECDHE RSA requires a RSA server key")
|
2013-07-17 17:33:16 +01:00
|
|
|
}
|
|
|
|
default:
|
2016-04-12 18:43:44 +01:00
|
|
|
return nil, errors.New("tls: unknown ECDHE signature algorithm")
|
2010-12-16 22:10:50 +00:00
|
|
|
}
|
2015-03-19 11:01:57 +00:00
|
|
|
sig, err = priv.Sign(config.rand(), digest, hashFunc)
|
|
|
|
if err != nil {
|
2016-04-12 18:43:44 +01:00
|
|
|
return nil, errors.New("tls: failed to sign ECDHE parameters: " + err.Error())
|
2015-03-19 11:01:57 +00:00
|
|
|
}
|
2010-12-16 22:10:50 +00:00
|
|
|
|
|
|
|
skx := new(serverKeyExchangeMsg)
|
2013-07-03 00:58:56 +01:00
|
|
|
sigAndHashLen := 0
|
|
|
|
if ka.version >= VersionTLS12 {
|
|
|
|
sigAndHashLen = 2
|
|
|
|
}
|
|
|
|
skx.key = make([]byte, len(serverECDHParams)+sigAndHashLen+2+len(sig))
|
2010-12-16 22:10:50 +00:00
|
|
|
copy(skx.key, serverECDHParams)
|
|
|
|
k := skx.key[len(serverECDHParams):]
|
2013-07-03 00:58:56 +01:00
|
|
|
if ka.version >= VersionTLS12 {
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
k[0] = sigAndHash.hash
|
|
|
|
k[1] = sigAndHash.signature
|
2013-07-03 00:58:56 +01:00
|
|
|
k = k[2:]
|
|
|
|
}
|
2010-12-16 22:10:50 +00:00
|
|
|
k[0] = byte(len(sig) >> 8)
|
|
|
|
k[1] = byte(len(sig))
|
|
|
|
copy(k[2:], sig)
|
|
|
|
|
|
|
|
return skx, nil
|
|
|
|
}
|
|
|
|
|
2013-07-17 17:33:16 +01:00
|
|
|
func (ka *ecdheKeyAgreement) processClientKeyExchange(config *Config, cert *Certificate, ckx *clientKeyExchangeMsg, version uint16) ([]byte, error) {
|
2010-12-16 22:10:50 +00:00
|
|
|
if len(ckx.ciphertext) == 0 || int(ckx.ciphertext[0]) != len(ckx.ciphertext)-1 {
|
2014-02-12 16:20:01 +00:00
|
|
|
return nil, errClientKeyExchange
|
2010-12-16 22:10:50 +00:00
|
|
|
}
|
2016-10-11 02:23:37 +01:00
|
|
|
|
|
|
|
if ka.curveid == X25519 {
|
|
|
|
if len(ckx.ciphertext) != 1+32 {
|
|
|
|
return nil, errClientKeyExchange
|
|
|
|
}
|
|
|
|
|
|
|
|
var theirPublic, sharedKey, scalar [32]byte
|
|
|
|
copy(theirPublic[:], ckx.ciphertext[1:])
|
|
|
|
copy(scalar[:], ka.privateKey)
|
|
|
|
curve25519.ScalarMult(&sharedKey, &scalar, &theirPublic)
|
|
|
|
return sharedKey[:], nil
|
|
|
|
}
|
|
|
|
|
|
|
|
curve, ok := curveForCurveID(ka.curveid)
|
|
|
|
if !ok {
|
|
|
|
panic("internal error")
|
|
|
|
}
|
2017-05-26 10:33:49 +01:00
|
|
|
x, y := elliptic.Unmarshal(curve, ckx.ciphertext[1:]) // Unmarshal also checks whether the given point is on the curve
|
2010-12-16 22:10:50 +00:00
|
|
|
if x == nil {
|
2014-02-12 16:20:01 +00:00
|
|
|
return nil, errClientKeyExchange
|
2010-12-16 22:10:50 +00:00
|
|
|
}
|
2016-10-11 02:23:37 +01:00
|
|
|
x, _ = curve.ScalarMult(x, y, ka.privateKey)
|
|
|
|
preMasterSecret := make([]byte, (curve.Params().BitSize+7)>>3)
|
2010-12-16 22:10:50 +00:00
|
|
|
xBytes := x.Bytes()
|
|
|
|
copy(preMasterSecret[len(preMasterSecret)-len(xBytes):], xBytes)
|
|
|
|
|
|
|
|
return preMasterSecret, nil
|
|
|
|
}
|
|
|
|
|
2013-07-17 17:33:16 +01:00
|
|
|
func (ka *ecdheKeyAgreement) processServerKeyExchange(config *Config, clientHello *clientHelloMsg, serverHello *serverHelloMsg, cert *x509.Certificate, skx *serverKeyExchangeMsg) error {
|
2010-12-16 22:10:50 +00:00
|
|
|
if len(skx.key) < 4 {
|
2011-06-17 11:07:13 +01:00
|
|
|
return errServerKeyExchange
|
2010-12-16 22:10:50 +00:00
|
|
|
}
|
|
|
|
if skx.key[0] != 3 { // named curve
|
2014-02-24 22:57:51 +00:00
|
|
|
return errors.New("tls: server selected unsupported curve")
|
2010-12-16 22:10:50 +00:00
|
|
|
}
|
2016-10-11 02:23:37 +01:00
|
|
|
ka.curveid = CurveID(skx.key[1])<<8 | CurveID(skx.key[2])
|
2010-12-16 22:10:50 +00:00
|
|
|
|
|
|
|
publicLen := int(skx.key[3])
|
|
|
|
if publicLen+4 > len(skx.key) {
|
2011-06-17 11:07:13 +01:00
|
|
|
return errServerKeyExchange
|
2010-12-16 22:10:50 +00:00
|
|
|
}
|
|
|
|
serverECDHParams := skx.key[:4+publicLen]
|
2016-10-11 02:23:37 +01:00
|
|
|
publicKey := serverECDHParams[4:]
|
2010-12-16 22:10:50 +00:00
|
|
|
|
|
|
|
sig := skx.key[4+publicLen:]
|
|
|
|
if len(sig) < 2 {
|
2011-06-17 11:07:13 +01:00
|
|
|
return errServerKeyExchange
|
2010-12-16 22:10:50 +00:00
|
|
|
}
|
2013-10-21 21:35:09 +01:00
|
|
|
|
2016-10-11 02:23:37 +01:00
|
|
|
if ka.curveid == X25519 {
|
|
|
|
if len(publicKey) != 32 {
|
|
|
|
return errors.New("tls: bad X25519 public value")
|
|
|
|
}
|
|
|
|
ka.publicKey = publicKey
|
|
|
|
} else {
|
|
|
|
curve, ok := curveForCurveID(ka.curveid)
|
|
|
|
if !ok {
|
|
|
|
return errors.New("tls: server selected unsupported curve")
|
|
|
|
}
|
2017-05-26 10:33:49 +01:00
|
|
|
ka.x, ka.y = elliptic.Unmarshal(curve, publicKey) // Unmarshal also checks whether the given point is on the curve
|
2016-10-11 02:23:37 +01:00
|
|
|
if ka.x == nil {
|
|
|
|
return errServerKeyExchange
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
sigAndHash := signatureAndHash{signature: ka.sigType}
|
2013-07-03 00:58:56 +01:00
|
|
|
if ka.version >= VersionTLS12 {
|
2013-10-21 21:35:09 +01:00
|
|
|
// handle SignatureAndHashAlgorithm
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
sigAndHash = signatureAndHash{hash: sig[0], signature: sig[1]}
|
|
|
|
if sigAndHash.signature != ka.sigType {
|
2013-10-21 21:35:09 +01:00
|
|
|
return errServerKeyExchange
|
|
|
|
}
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
sig = sig[2:]
|
2013-07-03 00:58:56 +01:00
|
|
|
if len(sig) < 2 {
|
|
|
|
return errServerKeyExchange
|
|
|
|
}
|
|
|
|
}
|
2010-12-16 22:10:50 +00:00
|
|
|
sigLen := int(sig[0])<<8 | int(sig[1])
|
|
|
|
if sigLen+2 != len(sig) {
|
2011-06-17 11:07:13 +01:00
|
|
|
return errServerKeyExchange
|
2010-12-16 22:10:50 +00:00
|
|
|
}
|
|
|
|
sig = sig[2:]
|
|
|
|
|
crypto/tls: decouple handshake signatures from the handshake hash.
Prior to TLS 1.2, the handshake had a pleasing property that one could
incrementally hash it and, from that, get the needed hashes for both
the CertificateVerify and Finished messages.
TLS 1.2 introduced negotiation for the signature and hash and it became
possible for the handshake hash to be, say, SHA-384, but for the
CertificateVerify to sign the handshake with SHA-1. The problem is that
one doesn't know in advance which hashes will be needed and thus the
handshake needs to be buffered.
Go ignored this, always kept a single handshake hash, and any signatures
over the handshake had to use that hash.
However, there are a set of servers that inspect the client's offered
signature hash functions and will abort the handshake if one of the
server's certificates is signed with a hash function outside of that
set. https://robertsspaceindustries.com/ is an example of such a server.
Clearly not a lot of thought happened when that server code was written,
but its out there and we have to deal with it.
This change decouples the handshake hash from the CertificateVerify
hash. This lays the groundwork for advertising support for SHA-384 but
doesn't actually make that change in the interests of reviewability.
Updating the advertised hash functions will cause changes in many of the
testdata/ files and some errors might get lost in the noise. This change
only needs to update four testdata/ files: one because a SHA-384-based
handshake is now being signed with SHA-256 and the others because the
TLS 1.2 CertificateRequest message now includes SHA-1.
This change also has the effect of adding support for
client-certificates in SSLv3 servers. However, SSLv3 is now disabled by
default so this should be moot.
It would be possible to avoid much of this change and just support
SHA-384 for the ServerKeyExchange as the SKX only signs over the nonces
and SKX params (a design mistake in TLS). However, that would leave Go
in the odd situation where it advertised support for SHA-384, but would
only use the handshake hash when signing client certificates. I fear
that'll just cause problems in the future.
Much of this code was written by davidben@ for the purposes of testing
BoringSSL.
Partly addresses #9757
Change-Id: I5137a472b6076812af387a5a69fc62c7373cd485
Reviewed-on: https://go-review.googlesource.com/9415
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2015-04-28 17:13:38 +01:00
|
|
|
digest, hashFunc, err := hashForServerKeyExchange(sigAndHash, ka.version, clientHello.random, serverHello.random, serverECDHParams)
|
2013-10-21 21:35:09 +01:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2013-07-17 17:33:16 +01:00
|
|
|
switch ka.sigType {
|
|
|
|
case signatureECDSA:
|
|
|
|
pubKey, ok := cert.PublicKey.(*ecdsa.PublicKey)
|
|
|
|
if !ok {
|
2016-04-12 18:43:44 +01:00
|
|
|
return errors.New("tls: ECDHE ECDSA requires a ECDSA server public key")
|
2013-07-17 17:33:16 +01:00
|
|
|
}
|
|
|
|
ecdsaSig := new(ecdsaSignature)
|
|
|
|
if _, err := asn1.Unmarshal(sig, ecdsaSig); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if ecdsaSig.R.Sign() <= 0 || ecdsaSig.S.Sign() <= 0 {
|
2016-04-12 18:43:44 +01:00
|
|
|
return errors.New("tls: ECDSA signature contained zero or negative values")
|
2013-07-17 17:33:16 +01:00
|
|
|
}
|
|
|
|
if !ecdsa.Verify(pubKey, digest, ecdsaSig.R, ecdsaSig.S) {
|
2016-04-12 18:43:44 +01:00
|
|
|
return errors.New("tls: ECDSA verification failure")
|
2013-07-17 17:33:16 +01:00
|
|
|
}
|
|
|
|
case signatureRSA:
|
|
|
|
pubKey, ok := cert.PublicKey.(*rsa.PublicKey)
|
|
|
|
if !ok {
|
2016-04-12 18:43:44 +01:00
|
|
|
return errors.New("tls: ECDHE RSA requires a RSA server public key")
|
2013-07-17 17:33:16 +01:00
|
|
|
}
|
|
|
|
if err := rsa.VerifyPKCS1v15(pubKey, hashFunc, digest, sig); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
default:
|
2016-04-12 18:43:44 +01:00
|
|
|
return errors.New("tls: unknown ECDHE signature algorithm")
|
2013-07-17 17:33:16 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
return nil
|
2010-12-16 22:10:50 +00:00
|
|
|
}
|
|
|
|
|
2013-07-17 17:33:16 +01:00
|
|
|
func (ka *ecdheKeyAgreement) generateClientKeyExchange(config *Config, clientHello *clientHelloMsg, cert *x509.Certificate) ([]byte, *clientKeyExchangeMsg, error) {
|
2016-10-11 02:23:37 +01:00
|
|
|
if ka.curveid == 0 {
|
2016-04-12 18:43:44 +01:00
|
|
|
return nil, nil, errors.New("tls: missing ServerKeyExchange message")
|
2010-12-16 22:10:50 +00:00
|
|
|
}
|
|
|
|
|
2016-10-11 02:23:37 +01:00
|
|
|
var serialized, preMasterSecret []byte
|
|
|
|
|
|
|
|
if ka.curveid == X25519 {
|
|
|
|
var ourPublic, theirPublic, sharedKey, scalar [32]byte
|
|
|
|
|
|
|
|
if _, err := io.ReadFull(config.rand(), scalar[:]); err != nil {
|
|
|
|
return nil, nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
copy(theirPublic[:], ka.publicKey)
|
|
|
|
curve25519.ScalarBaseMult(&ourPublic, &scalar)
|
|
|
|
curve25519.ScalarMult(&sharedKey, &scalar, &theirPublic)
|
|
|
|
serialized = ourPublic[:]
|
|
|
|
preMasterSecret = sharedKey[:]
|
|
|
|
} else {
|
|
|
|
curve, ok := curveForCurveID(ka.curveid)
|
|
|
|
if !ok {
|
|
|
|
panic("internal error")
|
|
|
|
}
|
|
|
|
priv, mx, my, err := elliptic.GenerateKey(curve, config.rand())
|
|
|
|
if err != nil {
|
|
|
|
return nil, nil, err
|
|
|
|
}
|
|
|
|
x, _ := curve.ScalarMult(ka.x, ka.y, priv)
|
|
|
|
preMasterSecret = make([]byte, (curve.Params().BitSize+7)>>3)
|
|
|
|
xBytes := x.Bytes()
|
|
|
|
copy(preMasterSecret[len(preMasterSecret)-len(xBytes):], xBytes)
|
|
|
|
|
|
|
|
serialized = elliptic.Marshal(curve, mx, my)
|
|
|
|
}
|
2010-12-16 22:10:50 +00:00
|
|
|
|
|
|
|
ckx := new(clientKeyExchangeMsg)
|
2011-05-18 18:14:56 +01:00
|
|
|
ckx.ciphertext = make([]byte, 1+len(serialized))
|
|
|
|
ckx.ciphertext[0] = byte(len(serialized))
|
|
|
|
copy(ckx.ciphertext[1:], serialized)
|
2010-12-16 22:10:50 +00:00
|
|
|
|
|
|
|
return preMasterSecret, ckx, nil
|
|
|
|
}
|