2009-11-05 23:44:32 +00:00
|
|
|
// Copyright 2009 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 (
|
2013-07-17 17:33:16 +01:00
|
|
|
"crypto"
|
|
|
|
"crypto/ecdsa"
|
2009-12-15 23:33:31 +00:00
|
|
|
"crypto/rsa"
|
|
|
|
"crypto/subtle"
|
2010-08-16 16:22:22 +01:00
|
|
|
"crypto/x509"
|
2013-07-17 17:33:16 +01:00
|
|
|
"encoding/asn1"
|
2011-11-02 02:04:37 +00:00
|
|
|
"errors"
|
2014-02-12 16:20:01 +00:00
|
|
|
"fmt"
|
2009-12-15 23:33:31 +00:00
|
|
|
"io"
|
2009-11-05 23:44:32 +00:00
|
|
|
)
|
|
|
|
|
2012-09-24 21:52:43 +01:00
|
|
|
// serverHandshakeState contains details of a server handshake in progress.
|
|
|
|
// It's discarded once the handshake has completed.
|
|
|
|
type serverHandshakeState struct {
|
2016-10-19 14:21:54 +01:00
|
|
|
c *Conn
|
|
|
|
clientHello *clientHelloMsg
|
|
|
|
hello *serverHelloMsg
|
|
|
|
suite *cipherSuite
|
|
|
|
ellipticOk bool
|
|
|
|
ecdsaOk bool
|
|
|
|
rsaDecryptOk bool
|
|
|
|
rsaSignOk bool
|
|
|
|
sessionState *sessionState
|
|
|
|
finishedHash finishedHash
|
|
|
|
masterSecret []byte
|
|
|
|
certsFromClient [][]byte
|
|
|
|
cert *Certificate
|
|
|
|
cachedClientHelloInfo *ClientHelloInfo
|
2012-09-24 21:52:43 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
// serverHandshake performs a TLS handshake as a server.
|
2016-04-26 18:45:35 +01:00
|
|
|
// c.out.Mutex <= L; c.handshakeMutex <= L.
|
2011-11-02 02:04:37 +00:00
|
|
|
func (c *Conn) serverHandshake() error {
|
2012-09-24 21:52:43 +01:00
|
|
|
// If this is the first server handshake, we generate a random key to
|
|
|
|
// encrypt the tickets with.
|
2017-04-28 21:37:52 +01:00
|
|
|
c.config.serverInitOnce.Do(func() { c.config.serverInit(nil) })
|
2012-09-24 21:52:43 +01:00
|
|
|
|
|
|
|
hs := serverHandshakeState{
|
|
|
|
c: c,
|
|
|
|
}
|
|
|
|
isResume, err := hs.readClientHello()
|
2010-04-27 06:19:04 +01:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2012-09-24 21:52:43 +01:00
|
|
|
|
|
|
|
// For an overview of TLS handshaking, see https://tools.ietf.org/html/rfc5246#section-7.3
|
2016-06-01 22:41:09 +01:00
|
|
|
c.buffering = true
|
2012-09-24 21:52:43 +01:00
|
|
|
if isResume {
|
|
|
|
// The client has included a session ticket and so we do an abbreviated handshake.
|
|
|
|
if err := hs.doResumeHandshake(); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if err := hs.establishKeys(); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2015-04-18 02:32:11 +01:00
|
|
|
// ticketSupported is set in a resumption handshake if the
|
|
|
|
// ticket from the client was encrypted with an old session
|
|
|
|
// ticket key and thus a refreshed ticket should be sent.
|
|
|
|
if hs.hello.ticketSupported {
|
|
|
|
if err := hs.sendSessionTicket(); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
2016-04-26 18:45:35 +01:00
|
|
|
if err := hs.sendFinished(c.serverFinished[:]); err != nil {
|
2012-09-24 21:52:43 +01:00
|
|
|
return err
|
|
|
|
}
|
2016-06-01 22:41:09 +01:00
|
|
|
if _, err := c.flush(); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2016-04-26 18:45:35 +01:00
|
|
|
c.clientFinishedIsFirst = false
|
2014-08-12 00:40:42 +01:00
|
|
|
if err := hs.readFinished(nil); err != nil {
|
2012-09-24 21:52:43 +01:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
c.didResume = true
|
|
|
|
} else {
|
|
|
|
// The client didn't include a session ticket, or it wasn't
|
|
|
|
// valid so we do a full handshake.
|
|
|
|
if err := hs.doFullHandshake(); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if err := hs.establishKeys(); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2016-04-26 18:45:35 +01:00
|
|
|
if err := hs.readFinished(c.clientFinished[:]); err != nil {
|
2012-09-24 21:52:43 +01:00
|
|
|
return err
|
|
|
|
}
|
2016-04-26 18:45:35 +01:00
|
|
|
c.clientFinishedIsFirst = true
|
2016-06-01 22:41:09 +01:00
|
|
|
c.buffering = true
|
2012-09-24 21:52:43 +01:00
|
|
|
if err := hs.sendSessionTicket(); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2014-08-12 00:40:42 +01:00
|
|
|
if err := hs.sendFinished(nil); err != nil {
|
2012-09-24 21:52:43 +01:00
|
|
|
return err
|
|
|
|
}
|
2016-06-01 22:41:09 +01:00
|
|
|
if _, err := c.flush(); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2012-09-24 21:52:43 +01:00
|
|
|
}
|
|
|
|
c.handshakeComplete = true
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// readClientHello reads a ClientHello message from the client and decides
|
|
|
|
// whether we will perform session resumption.
|
|
|
|
func (hs *serverHandshakeState) readClientHello() (isResume bool, err error) {
|
|
|
|
c := hs.c
|
|
|
|
|
|
|
|
msg, err := c.readHandshake()
|
|
|
|
if err != nil {
|
|
|
|
return false, err
|
|
|
|
}
|
|
|
|
var ok bool
|
|
|
|
hs.clientHello, ok = msg.(*clientHelloMsg)
|
2009-11-05 23:44:32 +00:00
|
|
|
if !ok {
|
2014-02-12 16:20:01 +00:00
|
|
|
c.sendAlert(alertUnexpectedMessage)
|
|
|
|
return false, unexpectedMessageError(hs.clientHello, msg)
|
2009-11-05 23:44:32 +00:00
|
|
|
}
|
2016-10-10 23:27:34 +01:00
|
|
|
|
|
|
|
if c.config.GetConfigForClient != nil {
|
2016-10-19 14:21:54 +01:00
|
|
|
if newConfig, err := c.config.GetConfigForClient(hs.clientHelloInfo()); err != nil {
|
2016-10-10 23:27:34 +01:00
|
|
|
c.sendAlert(alertInternalError)
|
|
|
|
return false, err
|
|
|
|
} else if newConfig != nil {
|
2017-04-28 21:37:52 +01:00
|
|
|
newConfig.serverInitOnce.Do(func() { newConfig.serverInit(c.config) })
|
2016-10-10 23:27:34 +01:00
|
|
|
c.config = newConfig
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
c.vers, ok = c.config.mutualVersion(hs.clientHello.vers)
|
2009-11-05 23:44:32 +00:00
|
|
|
if !ok {
|
2014-02-12 16:20:01 +00:00
|
|
|
c.sendAlert(alertProtocolVersion)
|
|
|
|
return false, fmt.Errorf("tls: client offered an unsupported, maximum protocol version of %x", hs.clientHello.vers)
|
2009-11-05 23:44:32 +00:00
|
|
|
}
|
2010-04-27 06:19:04 +01:00
|
|
|
c.haveVers = true
|
2009-11-05 23:44:32 +00:00
|
|
|
|
2012-09-24 21:52:43 +01:00
|
|
|
hs.hello = new(serverHelloMsg)
|
2009-11-05 23:44:32 +00:00
|
|
|
|
2010-12-16 22:10:50 +00:00
|
|
|
supportedCurve := false
|
2016-10-10 23:27:34 +01:00
|
|
|
preferredCurves := c.config.curvePreferences()
|
2010-12-16 22:10:50 +00:00
|
|
|
Curves:
|
2012-09-24 21:52:43 +01:00
|
|
|
for _, curve := range hs.clientHello.supportedCurves {
|
2014-02-24 22:57:51 +00:00
|
|
|
for _, supported := range preferredCurves {
|
|
|
|
if supported == curve {
|
|
|
|
supportedCurve = true
|
|
|
|
break Curves
|
|
|
|
}
|
2010-12-16 22:10:50 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
supportedPointFormat := false
|
2012-09-24 21:52:43 +01:00
|
|
|
for _, pointFormat := range hs.clientHello.supportedPoints {
|
2010-12-16 22:10:50 +00:00
|
|
|
if pointFormat == pointFormatUncompressed {
|
|
|
|
supportedPointFormat = true
|
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
2012-09-24 21:52:43 +01:00
|
|
|
hs.ellipticOk = supportedCurve && supportedPointFormat
|
2009-11-05 23:44:32 +00:00
|
|
|
|
2009-12-15 23:33:31 +00:00
|
|
|
foundCompression := false
|
2009-11-05 23:44:32 +00:00
|
|
|
// We only support null compression, so check that the client offered it.
|
2012-09-24 21:52:43 +01:00
|
|
|
for _, compression := range hs.clientHello.compressionMethods {
|
2009-11-05 23:44:32 +00:00
|
|
|
if compression == compressionNone {
|
2009-12-15 23:33:31 +00:00
|
|
|
foundCompression = true
|
|
|
|
break
|
2009-11-05 23:44:32 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-09-24 21:52:43 +01:00
|
|
|
if !foundCompression {
|
2014-02-12 16:20:01 +00:00
|
|
|
c.sendAlert(alertHandshakeFailure)
|
|
|
|
return false, errors.New("tls: client does not support uncompressed connections")
|
2009-12-15 23:33:31 +00:00
|
|
|
}
|
|
|
|
|
2012-09-24 21:52:43 +01:00
|
|
|
hs.hello.vers = c.vers
|
|
|
|
hs.hello.random = make([]byte, 32)
|
2016-10-10 23:27:34 +01:00
|
|
|
_, err = io.ReadFull(c.config.rand(), hs.hello.random)
|
2009-11-05 23:44:32 +00:00
|
|
|
if err != nil {
|
2014-02-12 16:20:01 +00:00
|
|
|
c.sendAlert(alertInternalError)
|
|
|
|
return false, err
|
2012-09-24 21:52:43 +01:00
|
|
|
}
|
2016-04-26 18:45:35 +01:00
|
|
|
|
|
|
|
if len(hs.clientHello.secureRenegotiation) != 0 {
|
|
|
|
c.sendAlert(alertHandshakeFailure)
|
|
|
|
return false, errors.New("tls: initial handshake had non-empty renegotiation extension")
|
|
|
|
}
|
|
|
|
|
|
|
|
hs.hello.secureRenegotiationSupported = hs.clientHello.secureRenegotiationSupported
|
2012-09-24 21:52:43 +01:00
|
|
|
hs.hello.compressionMethod = compressionNone
|
|
|
|
if len(hs.clientHello.serverName) > 0 {
|
|
|
|
c.serverName = hs.clientHello.serverName
|
|
|
|
}
|
2014-08-05 19:36:20 +01:00
|
|
|
|
|
|
|
if len(hs.clientHello.alpnProtocols) > 0 {
|
|
|
|
if selectedProto, fallback := mutualProtocol(hs.clientHello.alpnProtocols, c.config.NextProtos); !fallback {
|
|
|
|
hs.hello.alpnProtocol = selectedProto
|
|
|
|
c.clientProtocol = selectedProto
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// Although sending an empty NPN extension is reasonable, Firefox has
|
|
|
|
// had a bug around this. Best to send nothing at all if
|
2016-10-10 23:27:34 +01:00
|
|
|
// c.config.NextProtos is empty. See
|
2015-02-06 12:44:39 +00:00
|
|
|
// https://golang.org/issue/5445.
|
2016-10-10 23:27:34 +01:00
|
|
|
if hs.clientHello.nextProtoNeg && len(c.config.NextProtos) > 0 {
|
2014-08-05 19:36:20 +01:00
|
|
|
hs.hello.nextProtoNeg = true
|
2016-10-10 23:27:34 +01:00
|
|
|
hs.hello.nextProtos = c.config.NextProtos
|
2014-08-05 19:36:20 +01:00
|
|
|
}
|
2012-09-24 21:52:43 +01:00
|
|
|
}
|
|
|
|
|
2016-10-19 14:21:54 +01:00
|
|
|
hs.cert, err = c.config.getCertificate(hs.clientHelloInfo())
|
2016-03-14 09:35:13 +00:00
|
|
|
if err != nil {
|
2014-02-12 16:20:01 +00:00
|
|
|
c.sendAlert(alertInternalError)
|
2015-04-13 00:41:31 +01:00
|
|
|
return false, err
|
2013-09-17 18:30:36 +01:00
|
|
|
}
|
2015-04-16 19:59:22 +01:00
|
|
|
if hs.clientHello.scts {
|
|
|
|
hs.hello.scts = hs.cert.SignedCertificateTimestamps
|
|
|
|
}
|
2013-09-17 18:30:36 +01:00
|
|
|
|
2015-03-19 11:01:57 +00:00
|
|
|
if priv, ok := hs.cert.PrivateKey.(crypto.Signer); ok {
|
|
|
|
switch priv.Public().(type) {
|
|
|
|
case *ecdsa.PublicKey:
|
|
|
|
hs.ecdsaOk = true
|
|
|
|
case *rsa.PublicKey:
|
2015-04-03 00:19:46 +01:00
|
|
|
hs.rsaSignOk = true
|
2015-03-19 11:01:57 +00:00
|
|
|
default:
|
|
|
|
c.sendAlert(alertInternalError)
|
2016-04-12 18:43:44 +01:00
|
|
|
return false, fmt.Errorf("tls: unsupported signing key type (%T)", priv.Public())
|
2015-03-19 11:01:57 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
if priv, ok := hs.cert.PrivateKey.(crypto.Decrypter); ok {
|
|
|
|
switch priv.Public().(type) {
|
|
|
|
case *rsa.PublicKey:
|
2015-04-03 00:19:46 +01:00
|
|
|
hs.rsaDecryptOk = true
|
2015-03-19 11:01:57 +00:00
|
|
|
default:
|
|
|
|
c.sendAlert(alertInternalError)
|
2016-04-12 18:43:44 +01:00
|
|
|
return false, fmt.Errorf("tls: unsupported decryption key type (%T)", priv.Public())
|
2015-03-19 11:01:57 +00:00
|
|
|
}
|
|
|
|
}
|
2013-09-17 18:30:36 +01:00
|
|
|
|
2012-09-24 21:52:43 +01:00
|
|
|
if hs.checkForResumption() {
|
|
|
|
return true, nil
|
|
|
|
}
|
|
|
|
|
2013-01-22 15:10:38 +00:00
|
|
|
var preferenceList, supportedList []uint16
|
|
|
|
if c.config.PreferServerCipherSuites {
|
|
|
|
preferenceList = c.config.cipherSuites()
|
|
|
|
supportedList = hs.clientHello.cipherSuites
|
|
|
|
} else {
|
|
|
|
preferenceList = hs.clientHello.cipherSuites
|
|
|
|
supportedList = c.config.cipherSuites()
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, id := range preferenceList {
|
2015-03-19 11:01:57 +00:00
|
|
|
if hs.setCipherSuite(id, supportedList, c.vers) {
|
2012-09-24 21:52:43 +01:00
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if hs.suite == nil {
|
2014-02-12 16:20:01 +00:00
|
|
|
c.sendAlert(alertHandshakeFailure)
|
|
|
|
return false, errors.New("tls: no cipher suite supported by both client and server")
|
2012-09-24 21:52:43 +01:00
|
|
|
}
|
|
|
|
|
2016-02-15 16:56:18 +00:00
|
|
|
// See https://tools.ietf.org/html/rfc7507.
|
2014-10-16 01:54:04 +01:00
|
|
|
for _, id := range hs.clientHello.cipherSuites {
|
|
|
|
if id == TLS_FALLBACK_SCSV {
|
|
|
|
// The client is doing a fallback connection.
|
2014-12-18 18:17:54 +00:00
|
|
|
if hs.clientHello.vers < c.config.maxVersion() {
|
2014-10-16 01:54:04 +01:00
|
|
|
c.sendAlert(alertInappropriateFallback)
|
2015-03-06 13:59:12 +00:00
|
|
|
return false, errors.New("tls: client using inappropriate protocol fallback")
|
2014-10-16 01:54:04 +01:00
|
|
|
}
|
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-09-24 21:52:43 +01:00
|
|
|
return false, nil
|
|
|
|
}
|
|
|
|
|
2015-02-17 23:44:42 +00:00
|
|
|
// checkForResumption reports whether we should perform resumption on this connection.
|
2012-09-24 21:52:43 +01:00
|
|
|
func (hs *serverHandshakeState) checkForResumption() bool {
|
|
|
|
c := hs.c
|
|
|
|
|
2014-09-26 02:02:09 +01:00
|
|
|
if c.config.SessionTicketsDisabled {
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
2012-09-24 21:52:43 +01:00
|
|
|
var ok bool
|
2015-02-04 00:15:18 +00:00
|
|
|
var sessionTicket = append([]uint8{}, hs.clientHello.sessionTicket...)
|
|
|
|
if hs.sessionState, ok = c.decryptTicket(sessionTicket); !ok {
|
2012-09-24 21:52:43 +01:00
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
2016-02-15 16:41:40 +00:00
|
|
|
// Never resume a session for a different TLS version.
|
|
|
|
if c.vers != hs.sessionState.vers {
|
2012-09-24 21:52:43 +01:00
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
|
|
|
cipherSuiteOk := false
|
|
|
|
// Check that the client is still offering the ciphersuite in the session.
|
|
|
|
for _, id := range hs.clientHello.cipherSuites {
|
|
|
|
if id == hs.sessionState.cipherSuite {
|
|
|
|
cipherSuiteOk = true
|
|
|
|
break
|
|
|
|
}
|
2009-11-05 23:44:32 +00:00
|
|
|
}
|
2012-09-24 21:52:43 +01:00
|
|
|
if !cipherSuiteOk {
|
|
|
|
return false
|
2009-12-23 19:13:09 +00:00
|
|
|
}
|
2009-11-05 23:44:32 +00:00
|
|
|
|
2012-09-24 21:52:43 +01:00
|
|
|
// Check that we also support the ciphersuite from the session.
|
2015-03-19 11:01:57 +00:00
|
|
|
if !hs.setCipherSuite(hs.sessionState.cipherSuite, c.config.cipherSuites(), hs.sessionState.vers) {
|
2012-09-24 21:52:43 +01:00
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
|
|
|
sessionHasClientCerts := len(hs.sessionState.certificates) != 0
|
|
|
|
needClientCerts := c.config.ClientAuth == RequireAnyClientCert || c.config.ClientAuth == RequireAndVerifyClientCert
|
|
|
|
if needClientCerts && !sessionHasClientCerts {
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
if sessionHasClientCerts && c.config.ClientAuth == NoClientCert {
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
|
|
|
|
func (hs *serverHandshakeState) doResumeHandshake() error {
|
|
|
|
c := hs.c
|
|
|
|
|
|
|
|
hs.hello.cipherSuite = hs.suite.id
|
|
|
|
// We echo the client's session ID in the ServerHello to let it know
|
|
|
|
// that we're doing a resumption.
|
|
|
|
hs.hello.sessionId = hs.clientHello.sessionId
|
2015-04-18 02:32:11 +01:00
|
|
|
hs.hello.ticketSupported = hs.sessionState.usedOldKey
|
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
|
|
|
hs.finishedHash = newFinishedHash(c.vers, hs.suite)
|
|
|
|
hs.finishedHash.discardHandshakeBuffer()
|
|
|
|
hs.finishedHash.Write(hs.clientHello.marshal())
|
2012-09-24 21:52:43 +01:00
|
|
|
hs.finishedHash.Write(hs.hello.marshal())
|
2016-02-26 19:17:29 +00:00
|
|
|
if _, err := c.writeRecord(recordTypeHandshake, hs.hello.marshal()); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2012-09-24 21:52:43 +01:00
|
|
|
|
|
|
|
if len(hs.sessionState.certificates) > 0 {
|
|
|
|
if _, err := hs.processCertsFromClient(hs.sessionState.certificates); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
hs.masterSecret = hs.sessionState.masterSecret
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (hs *serverHandshakeState) doFullHandshake() error {
|
|
|
|
c := hs.c
|
|
|
|
|
2013-09-17 18:30:36 +01:00
|
|
|
if hs.clientHello.ocspStapling && len(hs.cert.OCSPStaple) > 0 {
|
2012-09-24 21:52:43 +01:00
|
|
|
hs.hello.ocspStapling = true
|
2012-04-12 17:35:21 +01:00
|
|
|
}
|
|
|
|
|
2016-10-10 23:27:34 +01:00
|
|
|
hs.hello.ticketSupported = hs.clientHello.ticketSupported && !c.config.SessionTicketsDisabled
|
2012-09-24 21:52:43 +01:00
|
|
|
hs.hello.cipherSuite = hs.suite.id
|
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
|
|
|
|
|
|
|
hs.finishedHash = newFinishedHash(hs.c.vers, hs.suite)
|
2016-10-10 23:27:34 +01:00
|
|
|
if c.config.ClientAuth == NoClientCert {
|
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
|
|
|
// No need to keep a full record of the handshake if client
|
|
|
|
// certificates won't be used.
|
|
|
|
hs.finishedHash.discardHandshakeBuffer()
|
|
|
|
}
|
|
|
|
hs.finishedHash.Write(hs.clientHello.marshal())
|
2012-09-24 21:52:43 +01:00
|
|
|
hs.finishedHash.Write(hs.hello.marshal())
|
2016-02-26 19:17:29 +00:00
|
|
|
if _, err := c.writeRecord(recordTypeHandshake, hs.hello.marshal()); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2012-04-12 17:35:21 +01:00
|
|
|
|
|
|
|
certMsg := new(certificateMsg)
|
2013-09-17 18:30:36 +01:00
|
|
|
certMsg.certificates = hs.cert.Certificate
|
2012-09-24 21:52:43 +01:00
|
|
|
hs.finishedHash.Write(certMsg.marshal())
|
2016-02-26 19:17:29 +00:00
|
|
|
if _, err := c.writeRecord(recordTypeHandshake, certMsg.marshal()); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2009-11-05 23:44:32 +00:00
|
|
|
|
2012-09-24 21:52:43 +01:00
|
|
|
if hs.hello.ocspStapling {
|
2011-04-14 19:47:28 +01:00
|
|
|
certStatus := new(certificateStatusMsg)
|
|
|
|
certStatus.statusType = statusTypeOCSP
|
2013-09-17 18:30:36 +01:00
|
|
|
certStatus.response = hs.cert.OCSPStaple
|
2012-09-24 21:52:43 +01:00
|
|
|
hs.finishedHash.Write(certStatus.marshal())
|
2016-02-26 19:17:29 +00:00
|
|
|
if _, err := c.writeRecord(recordTypeHandshake, certStatus.marshal()); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2011-04-14 19:47:28 +01:00
|
|
|
}
|
|
|
|
|
2013-07-03 00:58:56 +01:00
|
|
|
keyAgreement := hs.suite.ka(c.vers)
|
2016-10-10 23:27:34 +01:00
|
|
|
skx, err := keyAgreement.generateServerKeyExchange(c.config, hs.cert, hs.clientHello, hs.hello)
|
2010-12-16 22:10:50 +00:00
|
|
|
if err != nil {
|
|
|
|
c.sendAlert(alertHandshakeFailure)
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if skx != nil {
|
2012-09-24 21:52:43 +01:00
|
|
|
hs.finishedHash.Write(skx.marshal())
|
2016-02-26 19:17:29 +00:00
|
|
|
if _, err := c.writeRecord(recordTypeHandshake, skx.marshal()); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2010-12-16 22:10:50 +00:00
|
|
|
}
|
|
|
|
|
2016-10-10 23:27:34 +01:00
|
|
|
if c.config.ClientAuth >= RequestClientCert {
|
2010-08-16 16:22:22 +01:00
|
|
|
// Request a client certificate
|
|
|
|
certReq := new(certificateRequestMsg)
|
2013-07-17 17:33:16 +01:00
|
|
|
certReq.certificateTypes = []byte{
|
|
|
|
byte(certTypeRSASign),
|
|
|
|
byte(certTypeECDSASign),
|
|
|
|
}
|
2013-07-03 00:58:56 +01:00
|
|
|
if c.vers >= VersionTLS12 {
|
|
|
|
certReq.hasSignatureAndHash = true
|
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
|
|
|
certReq.signatureAndHashes = supportedSignatureAlgorithms
|
2013-07-03 00:58:56 +01:00
|
|
|
}
|
2012-01-05 17:05:38 +00:00
|
|
|
|
2010-08-16 16:22:22 +01:00
|
|
|
// An empty list of certificateAuthorities signals to
|
|
|
|
// the client that it may send any certificate in response
|
2012-01-05 17:05:38 +00:00
|
|
|
// to our request. When we know the CAs we trust, then
|
|
|
|
// we can send them down, so that the client can choose
|
|
|
|
// an appropriate certificate to give to us.
|
2016-10-10 23:27:34 +01:00
|
|
|
if c.config.ClientCAs != nil {
|
|
|
|
certReq.certificateAuthorities = c.config.ClientCAs.Subjects()
|
2012-01-05 17:05:38 +00:00
|
|
|
}
|
2012-09-24 21:52:43 +01:00
|
|
|
hs.finishedHash.Write(certReq.marshal())
|
2016-02-26 19:17:29 +00:00
|
|
|
if _, err := c.writeRecord(recordTypeHandshake, certReq.marshal()); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2010-08-16 16:22:22 +01:00
|
|
|
}
|
|
|
|
|
2009-12-15 23:33:31 +00:00
|
|
|
helloDone := new(serverHelloDoneMsg)
|
2012-09-24 21:52:43 +01:00
|
|
|
hs.finishedHash.Write(helloDone.marshal())
|
2016-02-26 19:17:29 +00:00
|
|
|
if _, err := c.writeRecord(recordTypeHandshake, helloDone.marshal()); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2009-11-05 23:44:32 +00:00
|
|
|
|
2016-06-01 22:41:09 +01:00
|
|
|
if _, err := c.flush(); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2013-07-17 17:33:16 +01:00
|
|
|
var pub crypto.PublicKey // public key for client auth, if any
|
2012-01-05 17:05:38 +00:00
|
|
|
|
2012-09-24 21:52:43 +01:00
|
|
|
msg, err := c.readHandshake()
|
2012-01-05 17:05:38 +00:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2012-09-24 21:52:43 +01:00
|
|
|
var ok bool
|
2012-01-05 17:05:38 +00:00
|
|
|
// If we requested a client certificate, then the client must send a
|
|
|
|
// certificate message, even if it's empty.
|
2016-10-10 23:27:34 +01:00
|
|
|
if c.config.ClientAuth >= RequestClientCert {
|
2012-01-05 17:05:38 +00:00
|
|
|
if certMsg, ok = msg.(*certificateMsg); !ok {
|
2014-02-12 16:20:01 +00:00
|
|
|
c.sendAlert(alertUnexpectedMessage)
|
|
|
|
return unexpectedMessageError(certMsg, msg)
|
2010-08-16 16:22:22 +01:00
|
|
|
}
|
2012-09-24 21:52:43 +01:00
|
|
|
hs.finishedHash.Write(certMsg.marshal())
|
2010-08-16 16:22:22 +01:00
|
|
|
|
2012-01-05 17:05:38 +00:00
|
|
|
if len(certMsg.certificates) == 0 {
|
|
|
|
// The client didn't actually send a certificate
|
2016-10-10 23:27:34 +01:00
|
|
|
switch c.config.ClientAuth {
|
2012-01-05 17:05:38 +00:00
|
|
|
case RequireAnyClientCert, RequireAndVerifyClientCert:
|
|
|
|
c.sendAlert(alertBadCertificate)
|
|
|
|
return errors.New("tls: client didn't provide a certificate")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-09-24 21:52:43 +01:00
|
|
|
pub, err = hs.processCertsFromClient(certMsg.certificates)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
2010-08-16 16:22:22 +01:00
|
|
|
}
|
2012-01-05 17:05:38 +00:00
|
|
|
|
|
|
|
msg, err = c.readHandshake()
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2010-08-16 16:22:22 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
// Get client key exchange
|
2010-04-27 06:19:04 +01:00
|
|
|
ckx, ok := msg.(*clientKeyExchangeMsg)
|
2009-11-05 23:44:32 +00:00
|
|
|
if !ok {
|
2014-02-12 16:20:01 +00:00
|
|
|
c.sendAlert(alertUnexpectedMessage)
|
|
|
|
return unexpectedMessageError(ckx, msg)
|
2009-11-05 23:44:32 +00:00
|
|
|
}
|
2012-09-24 21:52:43 +01:00
|
|
|
hs.finishedHash.Write(ckx.marshal())
|
2009-11-05 23:44:32 +00:00
|
|
|
|
2016-10-10 23:27:34 +01:00
|
|
|
preMasterSecret, err := keyAgreement.processClientKeyExchange(c.config, hs.cert, ckx, c.vers)
|
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 err != nil {
|
|
|
|
c.sendAlert(alertHandshakeFailure)
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
hs.masterSecret = masterFromPreMasterSecret(c.vers, hs.suite, preMasterSecret, hs.clientHello.random, hs.hello.random)
|
2016-10-10 23:27:34 +01:00
|
|
|
if err := c.config.writeKeyLog(hs.clientHello.random, hs.masterSecret); err != nil {
|
2016-08-20 12:41:42 +01:00
|
|
|
c.sendAlert(alertInternalError)
|
|
|
|
return 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
|
|
|
|
2010-08-16 16:22:22 +01:00
|
|
|
// If we received a client cert in response to our certificate request message,
|
|
|
|
// the client will send us a certificateVerifyMsg immediately after the
|
2016-03-01 23:21:55 +00:00
|
|
|
// clientKeyExchangeMsg. This message is a digest of all preceding
|
2010-08-16 16:22:22 +01:00
|
|
|
// handshake-layer messages that is signed using the private key corresponding
|
|
|
|
// to the client's certificate. This allows us to verify that the client is in
|
2011-05-18 18:14:56 +01:00
|
|
|
// possession of the private key of the certificate.
|
2010-08-16 16:22:22 +01:00
|
|
|
if len(c.peerCertificates) > 0 {
|
|
|
|
msg, err = c.readHandshake()
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
certVerify, ok := msg.(*certificateVerifyMsg)
|
|
|
|
if !ok {
|
2014-02-12 16:20:01 +00:00
|
|
|
c.sendAlert(alertUnexpectedMessage)
|
|
|
|
return unexpectedMessageError(certVerify, msg)
|
2010-08-16 16:22:22 +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
|
|
|
// Determine the signature type.
|
|
|
|
var signatureAndHash signatureAndHash
|
|
|
|
if certVerify.hasSignatureAndHash {
|
|
|
|
signatureAndHash = certVerify.signatureAndHash
|
|
|
|
if !isSupportedSignatureAndHash(signatureAndHash, supportedSignatureAlgorithms) {
|
|
|
|
return errors.New("tls: unsupported hash function for client certificate")
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// Before TLS 1.2 the signature algorithm was implicit
|
|
|
|
// from the key type, and only one hash per signature
|
|
|
|
// algorithm was possible. Leave the hash as zero.
|
|
|
|
switch pub.(type) {
|
|
|
|
case *ecdsa.PublicKey:
|
|
|
|
signatureAndHash.signature = signatureECDSA
|
|
|
|
case *rsa.PublicKey:
|
|
|
|
signatureAndHash.signature = signatureRSA
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-07-17 17:33:16 +01:00
|
|
|
switch key := pub.(type) {
|
|
|
|
case *ecdsa.PublicKey:
|
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 signatureAndHash.signature != signatureECDSA {
|
2016-04-12 18:43:44 +01:00
|
|
|
err = errors.New("tls: bad signature type for client's ECDSA certificate")
|
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
|
|
|
break
|
|
|
|
}
|
2013-07-17 17:33:16 +01:00
|
|
|
ecdsaSig := new(ecdsaSignature)
|
|
|
|
if _, err = asn1.Unmarshal(certVerify.signature, ecdsaSig); err != nil {
|
|
|
|
break
|
|
|
|
}
|
|
|
|
if ecdsaSig.R.Sign() <= 0 || ecdsaSig.S.Sign() <= 0 {
|
2016-04-12 18:43:44 +01:00
|
|
|
err = errors.New("tls: ECDSA signature contained zero or negative values")
|
2013-07-17 17:33:16 +01:00
|
|
|
break
|
|
|
|
}
|
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
|
|
|
var digest []byte
|
|
|
|
if digest, _, err = hs.finishedHash.hashForClientCertificate(signatureAndHash, hs.masterSecret); err != nil {
|
|
|
|
break
|
|
|
|
}
|
2013-07-17 17:33:16 +01:00
|
|
|
if !ecdsa.Verify(key, digest, ecdsaSig.R, ecdsaSig.S) {
|
2016-04-12 18:43:44 +01:00
|
|
|
err = errors.New("tls: ECDSA verification failure")
|
2013-07-17 17:33:16 +01:00
|
|
|
}
|
|
|
|
case *rsa.PublicKey:
|
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 signatureAndHash.signature != signatureRSA {
|
2016-04-12 18:43:44 +01:00
|
|
|
err = errors.New("tls: bad signature type for client's RSA certificate")
|
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
|
|
|
break
|
|
|
|
}
|
|
|
|
var digest []byte
|
|
|
|
var hashFunc crypto.Hash
|
|
|
|
if digest, hashFunc, err = hs.finishedHash.hashForClientCertificate(signatureAndHash, hs.masterSecret); err != nil {
|
|
|
|
break
|
|
|
|
}
|
2013-07-17 17:33:16 +01:00
|
|
|
err = rsa.VerifyPKCS1v15(key, hashFunc, digest, certVerify.signature)
|
|
|
|
}
|
2010-08-16 16:22:22 +01:00
|
|
|
if err != nil {
|
2010-10-11 15:39:56 +01:00
|
|
|
c.sendAlert(alertBadCertificate)
|
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
|
|
|
return errors.New("tls: could not validate signature of connection nonces: " + err.Error())
|
2010-08-16 16:22:22 +01:00
|
|
|
}
|
|
|
|
|
2012-09-24 21:52:43 +01:00
|
|
|
hs.finishedHash.Write(certVerify.marshal())
|
2010-08-16 16:22:22 +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
|
|
|
|
|
|
|
hs.finishedHash.discardHandshakeBuffer()
|
2012-09-24 21:52:43 +01:00
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (hs *serverHandshakeState) establishKeys() error {
|
|
|
|
c := hs.c
|
2009-11-05 23:44:32 +00:00
|
|
|
|
2012-09-24 21:52:43 +01:00
|
|
|
clientMAC, serverMAC, clientKey, serverKey, clientIV, serverIV :=
|
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
|
|
|
keysFromMasterSecret(c.vers, hs.suite, hs.masterSecret, hs.clientHello.random, hs.hello.random, hs.suite.macLen, hs.suite.keyLen, hs.suite.ivLen)
|
2009-11-05 23:44:32 +00:00
|
|
|
|
2013-08-29 22:18:59 +01:00
|
|
|
var clientCipher, serverCipher interface{}
|
|
|
|
var clientHash, serverHash macFunction
|
|
|
|
|
|
|
|
if hs.suite.aead == nil {
|
|
|
|
clientCipher = hs.suite.cipher(clientKey, clientIV, true /* for reading */)
|
|
|
|
clientHash = hs.suite.mac(c.vers, clientMAC)
|
|
|
|
serverCipher = hs.suite.cipher(serverKey, serverIV, false /* not for reading */)
|
|
|
|
serverHash = hs.suite.mac(c.vers, serverMAC)
|
|
|
|
} else {
|
|
|
|
clientCipher = hs.suite.aead(clientKey, clientIV)
|
|
|
|
serverCipher = hs.suite.aead(serverKey, serverIV)
|
|
|
|
}
|
2012-09-24 21:52:43 +01:00
|
|
|
|
2013-08-29 22:18:59 +01:00
|
|
|
c.in.prepareCipherSpec(c.vers, clientCipher, clientHash)
|
2012-09-24 21:52:43 +01:00
|
|
|
c.out.prepareCipherSpec(c.vers, serverCipher, serverHash)
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2014-08-12 00:40:42 +01:00
|
|
|
func (hs *serverHandshakeState) readFinished(out []byte) error {
|
2012-09-24 21:52:43 +01:00
|
|
|
c := hs.c
|
|
|
|
|
2010-04-27 06:19:04 +01:00
|
|
|
c.readRecord(recordTypeChangeCipherSpec)
|
2016-04-26 18:45:35 +01:00
|
|
|
if c.in.err != nil {
|
|
|
|
return c.in.err
|
2010-04-27 06:19:04 +01:00
|
|
|
}
|
2009-11-05 23:44:32 +00:00
|
|
|
|
2012-09-24 21:52:43 +01:00
|
|
|
if hs.hello.nextProtoNeg {
|
|
|
|
msg, err := c.readHandshake()
|
2010-04-27 06:19:04 +01:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
nextProto, ok := msg.(*nextProtoMsg)
|
2009-12-23 19:13:09 +00:00
|
|
|
if !ok {
|
2014-02-12 16:20:01 +00:00
|
|
|
c.sendAlert(alertUnexpectedMessage)
|
|
|
|
return unexpectedMessageError(nextProto, msg)
|
2009-12-23 19:13:09 +00:00
|
|
|
}
|
2012-09-24 21:52:43 +01:00
|
|
|
hs.finishedHash.Write(nextProto.marshal())
|
2010-04-27 06:19:04 +01:00
|
|
|
c.clientProtocol = nextProto.proto
|
2009-12-23 19:13:09 +00:00
|
|
|
}
|
|
|
|
|
2012-09-24 21:52:43 +01:00
|
|
|
msg, err := c.readHandshake()
|
2010-04-27 06:19:04 +01:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
clientFinished, ok := msg.(*finishedMsg)
|
2009-11-05 23:44:32 +00:00
|
|
|
if !ok {
|
2014-02-12 16:20:01 +00:00
|
|
|
c.sendAlert(alertUnexpectedMessage)
|
|
|
|
return unexpectedMessageError(clientFinished, msg)
|
2009-11-05 23:44:32 +00:00
|
|
|
}
|
|
|
|
|
2012-09-24 21:52:43 +01:00
|
|
|
verify := hs.finishedHash.clientSum(hs.masterSecret)
|
2009-11-05 23:44:32 +00:00
|
|
|
if len(verify) != len(clientFinished.verifyData) ||
|
|
|
|
subtle.ConstantTimeCompare(verify, clientFinished.verifyData) != 1 {
|
2014-02-12 16:20:01 +00:00
|
|
|
c.sendAlert(alertHandshakeFailure)
|
|
|
|
return errors.New("tls: client's Finished message is incorrect")
|
2009-11-05 23:44:32 +00:00
|
|
|
}
|
|
|
|
|
2012-09-24 21:52:43 +01:00
|
|
|
hs.finishedHash.Write(clientFinished.marshal())
|
2014-08-12 00:40:42 +01:00
|
|
|
copy(out, verify)
|
2012-09-24 21:52:43 +01:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (hs *serverHandshakeState) sendSessionTicket() error {
|
|
|
|
if !hs.hello.ticketSupported {
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
c := hs.c
|
|
|
|
m := new(newSessionTicketMsg)
|
|
|
|
|
|
|
|
var err error
|
|
|
|
state := sessionState{
|
|
|
|
vers: c.vers,
|
|
|
|
cipherSuite: hs.suite.id,
|
|
|
|
masterSecret: hs.masterSecret,
|
|
|
|
certificates: hs.certsFromClient,
|
|
|
|
}
|
|
|
|
m.ticket, err = c.encryptTicket(&state)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
hs.finishedHash.Write(m.marshal())
|
2016-02-26 19:17:29 +00:00
|
|
|
if _, err := c.writeRecord(recordTypeHandshake, m.marshal()); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2012-09-24 21:52:43 +01:00
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2014-08-12 00:40:42 +01:00
|
|
|
func (hs *serverHandshakeState) sendFinished(out []byte) error {
|
2012-09-24 21:52:43 +01:00
|
|
|
c := hs.c
|
2009-11-05 23:44:32 +00:00
|
|
|
|
2016-02-26 19:17:29 +00:00
|
|
|
if _, err := c.writeRecord(recordTypeChangeCipherSpec, []byte{1}); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2009-11-05 23:44:32 +00:00
|
|
|
|
2009-12-15 23:33:31 +00:00
|
|
|
finished := new(finishedMsg)
|
2012-09-24 21:52:43 +01:00
|
|
|
finished.verifyData = hs.finishedHash.serverSum(hs.masterSecret)
|
|
|
|
hs.finishedHash.Write(finished.marshal())
|
2016-02-26 19:17:29 +00:00
|
|
|
if _, err := c.writeRecord(recordTypeHandshake, finished.marshal()); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2009-11-05 23:44:32 +00:00
|
|
|
|
2012-09-24 21:52:43 +01:00
|
|
|
c.cipherSuite = hs.suite.id
|
2014-08-12 00:40:42 +01:00
|
|
|
copy(out, finished.verifyData)
|
2012-09-24 21:52:43 +01:00
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// processCertsFromClient takes a chain of client certificates either from a
|
|
|
|
// Certificates message or from a sessionState and verifies them. It returns
|
|
|
|
// the public key of the leaf certificate.
|
2013-07-17 17:33:16 +01:00
|
|
|
func (hs *serverHandshakeState) processCertsFromClient(certificates [][]byte) (crypto.PublicKey, error) {
|
2012-09-24 21:52:43 +01:00
|
|
|
c := hs.c
|
|
|
|
|
|
|
|
hs.certsFromClient = certificates
|
|
|
|
certs := make([]*x509.Certificate, len(certificates))
|
|
|
|
var err error
|
|
|
|
for i, asn1Data := range certificates {
|
|
|
|
if certs[i], err = x509.ParseCertificate(asn1Data); err != nil {
|
|
|
|
c.sendAlert(alertBadCertificate)
|
|
|
|
return nil, errors.New("tls: failed to parse client certificate: " + err.Error())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if c.config.ClientAuth >= VerifyClientCertIfGiven && len(certs) > 0 {
|
|
|
|
opts := x509.VerifyOptions{
|
|
|
|
Roots: c.config.ClientCAs,
|
|
|
|
CurrentTime: c.config.time(),
|
|
|
|
Intermediates: x509.NewCertPool(),
|
|
|
|
KeyUsages: []x509.ExtKeyUsage{x509.ExtKeyUsageClientAuth},
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, cert := range certs[1:] {
|
|
|
|
opts.Intermediates.AddCert(cert)
|
|
|
|
}
|
|
|
|
|
|
|
|
chains, err := certs[0].Verify(opts)
|
|
|
|
if err != nil {
|
|
|
|
c.sendAlert(alertBadCertificate)
|
|
|
|
return nil, errors.New("tls: failed to verify client's certificate: " + err.Error())
|
|
|
|
}
|
|
|
|
|
|
|
|
c.verifiedChains = chains
|
|
|
|
}
|
|
|
|
|
2016-07-13 23:22:28 +01:00
|
|
|
if c.config.VerifyPeerCertificate != nil {
|
|
|
|
if err := c.config.VerifyPeerCertificate(certificates, c.verifiedChains); err != nil {
|
|
|
|
c.sendAlert(alertBadCertificate)
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-03-14 09:35:13 +00:00
|
|
|
if len(certs) == 0 {
|
|
|
|
return nil, nil
|
2012-09-24 21:52:43 +01:00
|
|
|
}
|
|
|
|
|
2016-03-14 09:35:13 +00:00
|
|
|
var pub crypto.PublicKey
|
|
|
|
switch key := certs[0].PublicKey.(type) {
|
|
|
|
case *ecdsa.PublicKey, *rsa.PublicKey:
|
|
|
|
pub = key
|
|
|
|
default:
|
|
|
|
c.sendAlert(alertUnsupportedCertificate)
|
|
|
|
return nil, fmt.Errorf("tls: client's certificate contains an unsupported public key of type %T", certs[0].PublicKey)
|
|
|
|
}
|
|
|
|
c.peerCertificates = certs
|
|
|
|
return pub, nil
|
2012-09-24 21:52:43 +01:00
|
|
|
}
|
|
|
|
|
2015-03-19 11:01:57 +00:00
|
|
|
// setCipherSuite sets a cipherSuite with the given id as the serverHandshakeState
|
|
|
|
// suite if that cipher suite is acceptable to use.
|
|
|
|
// It returns a bool indicating if the suite was set.
|
|
|
|
func (hs *serverHandshakeState) setCipherSuite(id uint16, supportedCipherSuites []uint16, version uint16) bool {
|
2013-01-22 15:10:38 +00:00
|
|
|
for _, supported := range supportedCipherSuites {
|
2012-09-24 21:52:43 +01:00
|
|
|
if id == supported {
|
|
|
|
var candidate *cipherSuite
|
|
|
|
|
|
|
|
for _, s := range cipherSuites {
|
|
|
|
if s.id == id {
|
|
|
|
candidate = s
|
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if candidate == nil {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
// Don't select a ciphersuite which we can't
|
|
|
|
// support for this client.
|
2015-03-19 11:01:57 +00:00
|
|
|
if candidate.flags&suiteECDHE != 0 {
|
2015-04-03 00:19:46 +01:00
|
|
|
if !hs.ellipticOk {
|
2015-03-19 11:01:57 +00:00
|
|
|
continue
|
|
|
|
}
|
|
|
|
if candidate.flags&suiteECDSA != 0 {
|
|
|
|
if !hs.ecdsaOk {
|
|
|
|
continue
|
|
|
|
}
|
2015-04-03 00:19:46 +01:00
|
|
|
} else if !hs.rsaSignOk {
|
2015-03-19 11:01:57 +00:00
|
|
|
continue
|
|
|
|
}
|
2015-04-03 00:19:46 +01:00
|
|
|
} else if !hs.rsaDecryptOk {
|
2012-09-24 21:52:43 +01:00
|
|
|
continue
|
|
|
|
}
|
2013-09-26 22:09:56 +01:00
|
|
|
if version < VersionTLS12 && candidate.flags&suiteTLS12 != 0 {
|
|
|
|
continue
|
|
|
|
}
|
2015-03-19 11:01:57 +00:00
|
|
|
hs.suite = candidate
|
|
|
|
return true
|
2012-09-24 21:52:43 +01:00
|
|
|
}
|
|
|
|
}
|
2015-03-19 11:01:57 +00:00
|
|
|
return false
|
2009-11-05 23:44:32 +00:00
|
|
|
}
|
2016-10-19 14:21:54 +01:00
|
|
|
|
|
|
|
// suppVersArray is the backing array of ClientHelloInfo.SupportedVersions
|
|
|
|
var suppVersArray = [...]uint16{VersionTLS12, VersionTLS11, VersionTLS10, VersionSSL30}
|
|
|
|
|
|
|
|
func (hs *serverHandshakeState) clientHelloInfo() *ClientHelloInfo {
|
|
|
|
if hs.cachedClientHelloInfo != nil {
|
|
|
|
return hs.cachedClientHelloInfo
|
|
|
|
}
|
|
|
|
|
|
|
|
var supportedVersions []uint16
|
|
|
|
if hs.clientHello.vers > VersionTLS12 {
|
|
|
|
supportedVersions = suppVersArray[:]
|
|
|
|
} else if hs.clientHello.vers >= VersionSSL30 {
|
|
|
|
supportedVersions = suppVersArray[VersionTLS12-hs.clientHello.vers:]
|
|
|
|
}
|
|
|
|
|
2016-10-26 20:30:30 +01:00
|
|
|
signatureSchemes := make([]SignatureScheme, 0, len(hs.clientHello.signatureAndHashes))
|
2016-10-19 14:21:54 +01:00
|
|
|
for _, sah := range hs.clientHello.signatureAndHashes {
|
2016-10-26 20:30:30 +01:00
|
|
|
signatureSchemes = append(signatureSchemes, SignatureScheme(sah.hash)<<8+SignatureScheme(sah.signature))
|
2016-10-19 14:21:54 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
hs.cachedClientHelloInfo = &ClientHelloInfo{
|
|
|
|
CipherSuites: hs.clientHello.cipherSuites,
|
|
|
|
ServerName: hs.clientHello.serverName,
|
|
|
|
SupportedCurves: hs.clientHello.supportedCurves,
|
|
|
|
SupportedPoints: hs.clientHello.supportedPoints,
|
|
|
|
SignatureSchemes: signatureSchemes,
|
|
|
|
SupportedProtos: hs.clientHello.alpnProtocols,
|
|
|
|
SupportedVersions: supportedVersions,
|
|
|
|
Conn: hs.c.conn,
|
|
|
|
}
|
|
|
|
|
|
|
|
return hs.cachedClientHelloInfo
|
|
|
|
}
|