Vous ne pouvez pas sélectionner plus de 25 sujets Les noms de sujets doivent commencer par une lettre ou un nombre, peuvent contenir des tirets ('-') et peuvent comporter jusqu'à 35 caractères.

cipher_suites.go 14 KiB

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>
il y a 9 ans
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>
il y a 9 ans
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>
il y a 9 ans
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>
il y a 9 ans
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>
il y a 9 ans
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>
il y a 9 ans
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396
  1. // Copyright 2010 The Go Authors. All rights reserved.
  2. // Use of this source code is governed by a BSD-style
  3. // license that can be found in the LICENSE file.
  4. package tls
  5. import (
  6. "crypto/aes"
  7. "crypto/cipher"
  8. "crypto/des"
  9. "crypto/hmac"
  10. "crypto/rc4"
  11. "crypto/sha1"
  12. "crypto/sha256"
  13. "crypto/x509"
  14. "hash"
  15. "golang_org/x/crypto/chacha20poly1305"
  16. )
  17. // a keyAgreement implements the client and server side of a TLS key agreement
  18. // protocol by generating and processing key exchange messages.
  19. type keyAgreement interface {
  20. // On the server side, the first two methods are called in order.
  21. // In the case that the key agreement protocol doesn't use a
  22. // ServerKeyExchange message, generateServerKeyExchange can return nil,
  23. // nil.
  24. generateServerKeyExchange(*Config, *Certificate, *clientHelloMsg, *serverHelloMsg) (*serverKeyExchangeMsg, error)
  25. processClientKeyExchange(*Config, *Certificate, *clientKeyExchangeMsg, uint16) ([]byte, error)
  26. // On the client side, the next two methods are called in order.
  27. // This method may not be called if the server doesn't send a
  28. // ServerKeyExchange message.
  29. processServerKeyExchange(*Config, *clientHelloMsg, *serverHelloMsg, *x509.Certificate, *serverKeyExchangeMsg) error
  30. generateClientKeyExchange(*Config, *clientHelloMsg, *x509.Certificate) ([]byte, *clientKeyExchangeMsg, error)
  31. }
  32. const (
  33. // suiteECDH indicates that the cipher suite involves elliptic curve
  34. // Diffie-Hellman. This means that it should only be selected when the
  35. // client indicates that it supports ECC with a curve and point format
  36. // that we're happy with.
  37. suiteECDHE = 1 << iota
  38. // suiteECDSA indicates that the cipher suite involves an ECDSA
  39. // signature and therefore may only be selected when the server's
  40. // certificate is ECDSA. If this is not set then the cipher suite is
  41. // RSA based.
  42. suiteECDSA
  43. // suiteTLS12 indicates that the cipher suite should only be advertised
  44. // and accepted when using TLS 1.2.
  45. suiteTLS12
  46. // suiteSHA384 indicates that the cipher suite uses SHA384 as the
  47. // handshake hash.
  48. suiteSHA384
  49. // suiteDefaultOff indicates that this cipher suite is not included by
  50. // default.
  51. suiteDefaultOff
  52. )
  53. // A cipherSuite is a specific combination of key agreement, cipher and MAC
  54. // function. All cipher suites currently assume RSA key agreement.
  55. type cipherSuite struct {
  56. id uint16
  57. // the lengths, in bytes, of the key material needed for each component.
  58. keyLen int
  59. macLen int
  60. ivLen int
  61. ka func(version uint16) keyAgreement
  62. // flags is a bitmask of the suite* values, above.
  63. flags int
  64. cipher func(key, iv []byte, isRead bool) interface{}
  65. mac func(version uint16, macKey []byte) macFunction
  66. aead func(key, fixedNonce []byte) cipher.AEAD
  67. }
  68. var cipherSuites = []*cipherSuite{
  69. // Ciphersuite order is chosen so that ECDHE comes before plain RSA and
  70. // AEADs are the top preference.
  71. {TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, 32, 0, 12, ecdheRSAKA, suiteECDHE | suiteTLS12, nil, nil, aeadChaCha20Poly1305},
  72. {TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, 32, 0, 12, ecdheECDSAKA, suiteECDHE | suiteECDSA | suiteTLS12, nil, nil, aeadChaCha20Poly1305},
  73. {TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 16, 0, 4, ecdheRSAKA, suiteECDHE | suiteTLS12, nil, nil, aeadAESGCM},
  74. {TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 16, 0, 4, ecdheECDSAKA, suiteECDHE | suiteECDSA | suiteTLS12, nil, nil, aeadAESGCM},
  75. {TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, 32, 0, 4, ecdheRSAKA, suiteECDHE | suiteTLS12 | suiteSHA384, nil, nil, aeadAESGCM},
  76. {TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, 32, 0, 4, ecdheECDSAKA, suiteECDHE | suiteECDSA | suiteTLS12 | suiteSHA384, nil, nil, aeadAESGCM},
  77. {TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, 16, 32, 16, ecdheRSAKA, suiteECDHE | suiteTLS12 | suiteDefaultOff, cipherAES, macSHA256, nil},
  78. {TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, 16, 20, 16, ecdheRSAKA, suiteECDHE, cipherAES, macSHA1, nil},
  79. {TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, 16, 32, 16, ecdheECDSAKA, suiteECDHE | suiteECDSA | suiteTLS12 | suiteDefaultOff, cipherAES, macSHA256, nil},
  80. {TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, 16, 20, 16, ecdheECDSAKA, suiteECDHE | suiteECDSA, cipherAES, macSHA1, nil},
  81. {TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, 32, 20, 16, ecdheRSAKA, suiteECDHE, cipherAES, macSHA1, nil},
  82. {TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, 32, 20, 16, ecdheECDSAKA, suiteECDHE | suiteECDSA, cipherAES, macSHA1, nil},
  83. {TLS_RSA_WITH_AES_128_GCM_SHA256, 16, 0, 4, rsaKA, suiteTLS12, nil, nil, aeadAESGCM},
  84. {TLS_RSA_WITH_AES_256_GCM_SHA384, 32, 0, 4, rsaKA, suiteTLS12 | suiteSHA384, nil, nil, aeadAESGCM},
  85. {TLS_RSA_WITH_AES_128_CBC_SHA256, 16, 32, 16, rsaKA, suiteTLS12 | suiteDefaultOff, cipherAES, macSHA256, nil},
  86. {TLS_RSA_WITH_AES_128_CBC_SHA, 16, 20, 16, rsaKA, 0, cipherAES, macSHA1, nil},
  87. {TLS_RSA_WITH_AES_256_CBC_SHA, 32, 20, 16, rsaKA, 0, cipherAES, macSHA1, nil},
  88. {TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, 24, 20, 8, ecdheRSAKA, suiteECDHE, cipher3DES, macSHA1, nil},
  89. {TLS_RSA_WITH_3DES_EDE_CBC_SHA, 24, 20, 8, rsaKA, 0, cipher3DES, macSHA1, nil},
  90. // RC4-based cipher suites are disabled by default.
  91. {TLS_RSA_WITH_RC4_128_SHA, 16, 20, 0, rsaKA, suiteDefaultOff, cipherRC4, macSHA1, nil},
  92. {TLS_ECDHE_RSA_WITH_RC4_128_SHA, 16, 20, 0, ecdheRSAKA, suiteECDHE | suiteDefaultOff, cipherRC4, macSHA1, nil},
  93. {TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, 16, 20, 0, ecdheECDSAKA, suiteECDHE | suiteECDSA | suiteDefaultOff, cipherRC4, macSHA1, nil},
  94. }
  95. func cipherRC4(key, iv []byte, isRead bool) interface{} {
  96. cipher, _ := rc4.NewCipher(key)
  97. return cipher
  98. }
  99. func cipher3DES(key, iv []byte, isRead bool) interface{} {
  100. block, _ := des.NewTripleDESCipher(key)
  101. if isRead {
  102. return cipher.NewCBCDecrypter(block, iv)
  103. }
  104. return cipher.NewCBCEncrypter(block, iv)
  105. }
  106. func cipherAES(key, iv []byte, isRead bool) interface{} {
  107. block, _ := aes.NewCipher(key)
  108. if isRead {
  109. return cipher.NewCBCDecrypter(block, iv)
  110. }
  111. return cipher.NewCBCEncrypter(block, iv)
  112. }
  113. // macSHA1 returns a macFunction for the given protocol version.
  114. func macSHA1(version uint16, key []byte) macFunction {
  115. if version == VersionSSL30 {
  116. mac := ssl30MAC{
  117. h: sha1.New(),
  118. key: make([]byte, len(key)),
  119. }
  120. copy(mac.key, key)
  121. return mac
  122. }
  123. return tls10MAC{hmac.New(newConstantTimeHash(sha1.New), key)}
  124. }
  125. // macSHA256 returns a SHA-256 based MAC. These are only supported in TLS 1.2
  126. // so the given version is ignored.
  127. func macSHA256(version uint16, key []byte) macFunction {
  128. return tls10MAC{hmac.New(sha256.New, key)}
  129. }
  130. type macFunction interface {
  131. Size() int
  132. MAC(digestBuf, seq, header, data, extra []byte) []byte
  133. }
  134. type aead interface {
  135. cipher.AEAD
  136. // explicitIVLen returns the number of bytes used by the explicit nonce
  137. // that is included in the record. This is eight for older AEADs and
  138. // zero for modern ones.
  139. explicitNonceLen() int
  140. }
  141. // fixedNonceAEAD wraps an AEAD and prefixes a fixed portion of the nonce to
  142. // each call.
  143. type fixedNonceAEAD struct {
  144. // nonce contains the fixed part of the nonce in the first four bytes.
  145. nonce [12]byte
  146. aead cipher.AEAD
  147. }
  148. func (f *fixedNonceAEAD) NonceSize() int { return 8 }
  149. func (f *fixedNonceAEAD) Overhead() int { return f.aead.Overhead() }
  150. func (f *fixedNonceAEAD) explicitNonceLen() int { return 8 }
  151. func (f *fixedNonceAEAD) Seal(out, nonce, plaintext, additionalData []byte) []byte {
  152. copy(f.nonce[4:], nonce)
  153. return f.aead.Seal(out, f.nonce[:], plaintext, additionalData)
  154. }
  155. func (f *fixedNonceAEAD) Open(out, nonce, plaintext, additionalData []byte) ([]byte, error) {
  156. copy(f.nonce[4:], nonce)
  157. return f.aead.Open(out, f.nonce[:], plaintext, additionalData)
  158. }
  159. // xoredNonceAEAD wraps an AEAD by XORing in a fixed pattern to the nonce
  160. // before each call.
  161. type xorNonceAEAD struct {
  162. nonceMask [12]byte
  163. aead cipher.AEAD
  164. }
  165. func (f *xorNonceAEAD) NonceSize() int { return 8 }
  166. func (f *xorNonceAEAD) Overhead() int { return f.aead.Overhead() }
  167. func (f *xorNonceAEAD) explicitNonceLen() int { return 0 }
  168. func (f *xorNonceAEAD) Seal(out, nonce, plaintext, additionalData []byte) []byte {
  169. for i, b := range nonce {
  170. f.nonceMask[4+i] ^= b
  171. }
  172. result := f.aead.Seal(out, f.nonceMask[:], plaintext, additionalData)
  173. for i, b := range nonce {
  174. f.nonceMask[4+i] ^= b
  175. }
  176. return result
  177. }
  178. func (f *xorNonceAEAD) Open(out, nonce, plaintext, additionalData []byte) ([]byte, error) {
  179. for i, b := range nonce {
  180. f.nonceMask[4+i] ^= b
  181. }
  182. result, err := f.aead.Open(out, f.nonceMask[:], plaintext, additionalData)
  183. for i, b := range nonce {
  184. f.nonceMask[4+i] ^= b
  185. }
  186. return result, err
  187. }
  188. func aeadAESGCM(key, fixedNonce []byte) cipher.AEAD {
  189. aes, err := aes.NewCipher(key)
  190. if err != nil {
  191. panic(err)
  192. }
  193. aead, err := cipher.NewGCM(aes)
  194. if err != nil {
  195. panic(err)
  196. }
  197. ret := &fixedNonceAEAD{aead: aead}
  198. copy(ret.nonce[:], fixedNonce)
  199. return ret
  200. }
  201. func aeadChaCha20Poly1305(key, fixedNonce []byte) cipher.AEAD {
  202. aead, err := chacha20poly1305.New(key)
  203. if err != nil {
  204. panic(err)
  205. }
  206. ret := &xorNonceAEAD{aead: aead}
  207. copy(ret.nonceMask[:], fixedNonce)
  208. return ret
  209. }
  210. // ssl30MAC implements the SSLv3 MAC function, as defined in
  211. // www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt section 5.2.3.1
  212. type ssl30MAC struct {
  213. h hash.Hash
  214. key []byte
  215. }
  216. func (s ssl30MAC) Size() int {
  217. return s.h.Size()
  218. }
  219. var ssl30Pad1 = [48]byte{0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36}
  220. var ssl30Pad2 = [48]byte{0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c}
  221. // MAC does not offer constant timing guarantees for SSL v3.0, since it's deemed
  222. // useless considering the similar, protocol-level POODLE vulnerability.
  223. func (s ssl30MAC) MAC(digestBuf, seq, header, data, extra []byte) []byte {
  224. padLength := 48
  225. if s.h.Size() == 20 {
  226. padLength = 40
  227. }
  228. s.h.Reset()
  229. s.h.Write(s.key)
  230. s.h.Write(ssl30Pad1[:padLength])
  231. s.h.Write(seq)
  232. s.h.Write(header[:1])
  233. s.h.Write(header[3:5])
  234. s.h.Write(data)
  235. digestBuf = s.h.Sum(digestBuf[:0])
  236. s.h.Reset()
  237. s.h.Write(s.key)
  238. s.h.Write(ssl30Pad2[:padLength])
  239. s.h.Write(digestBuf)
  240. return s.h.Sum(digestBuf[:0])
  241. }
  242. type constantTimeHash interface {
  243. hash.Hash
  244. ConstantTimeSum(b []byte) []byte
  245. }
  246. // cthWrapper wraps any hash.Hash that implements ConstantTimeSum, and replaces
  247. // with that all calls to Sum. It's used to obtain a ConstantTimeSum-based HMAC.
  248. type cthWrapper struct {
  249. h constantTimeHash
  250. }
  251. func (c *cthWrapper) Size() int { return c.h.Size() }
  252. func (c *cthWrapper) BlockSize() int { return c.h.BlockSize() }
  253. func (c *cthWrapper) Reset() { c.h.Reset() }
  254. func (c *cthWrapper) Write(p []byte) (int, error) { return c.h.Write(p) }
  255. func (c *cthWrapper) Sum(b []byte) []byte { return c.h.ConstantTimeSum(b) }
  256. func newConstantTimeHash(h func() hash.Hash) func() hash.Hash {
  257. return func() hash.Hash {
  258. return &cthWrapper{h().(constantTimeHash)}
  259. }
  260. }
  261. // tls10MAC implements the TLS 1.0 MAC function. RFC 2246, section 6.2.3.
  262. type tls10MAC struct {
  263. h hash.Hash
  264. }
  265. func (s tls10MAC) Size() int {
  266. return s.h.Size()
  267. }
  268. // MAC is guaranteed to take constant time, as long as
  269. // len(seq)+len(header)+len(data)+len(extra) is constant. extra is not fed into
  270. // the MAC, but is only provided to make the timing profile constant.
  271. func (s tls10MAC) MAC(digestBuf, seq, header, data, extra []byte) []byte {
  272. s.h.Reset()
  273. s.h.Write(seq)
  274. s.h.Write(header)
  275. s.h.Write(data)
  276. res := s.h.Sum(digestBuf[:0])
  277. if extra != nil {
  278. s.h.Write(extra)
  279. }
  280. return res
  281. }
  282. func rsaKA(version uint16) keyAgreement {
  283. return rsaKeyAgreement{}
  284. }
  285. func ecdheECDSAKA(version uint16) keyAgreement {
  286. return &ecdheKeyAgreement{
  287. sigType: signatureECDSA,
  288. version: version,
  289. }
  290. }
  291. func ecdheRSAKA(version uint16) keyAgreement {
  292. return &ecdheKeyAgreement{
  293. sigType: signatureRSA,
  294. version: version,
  295. }
  296. }
  297. // mutualCipherSuite returns a cipherSuite given a list of supported
  298. // ciphersuites and the id requested by the peer.
  299. func mutualCipherSuite(have []uint16, want uint16) *cipherSuite {
  300. for _, id := range have {
  301. if id == want {
  302. for _, suite := range cipherSuites {
  303. if suite.id == want {
  304. return suite
  305. }
  306. }
  307. return nil
  308. }
  309. }
  310. return nil
  311. }
  312. // A list of cipher suite IDs that are, or have been, implemented by this
  313. // package.
  314. //
  315. // Taken from http://www.iana.org/assignments/tls-parameters/tls-parameters.xml
  316. const (
  317. TLS_RSA_WITH_RC4_128_SHA uint16 = 0x0005
  318. TLS_RSA_WITH_3DES_EDE_CBC_SHA uint16 = 0x000a
  319. TLS_RSA_WITH_AES_128_CBC_SHA uint16 = 0x002f
  320. TLS_RSA_WITH_AES_256_CBC_SHA uint16 = 0x0035
  321. TLS_RSA_WITH_AES_128_CBC_SHA256 uint16 = 0x003c
  322. TLS_RSA_WITH_AES_128_GCM_SHA256 uint16 = 0x009c
  323. TLS_RSA_WITH_AES_256_GCM_SHA384 uint16 = 0x009d
  324. TLS_ECDHE_ECDSA_WITH_RC4_128_SHA uint16 = 0xc007
  325. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA uint16 = 0xc009
  326. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA uint16 = 0xc00a
  327. TLS_ECDHE_RSA_WITH_RC4_128_SHA uint16 = 0xc011
  328. TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA uint16 = 0xc012
  329. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA uint16 = 0xc013
  330. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA uint16 = 0xc014
  331. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 uint16 = 0xc023
  332. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 uint16 = 0xc027
  333. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 uint16 = 0xc02f
  334. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 uint16 = 0xc02b
  335. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 uint16 = 0xc030
  336. TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 uint16 = 0xc02c
  337. TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 uint16 = 0xcca8
  338. TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 uint16 = 0xcca9
  339. // TLS_FALLBACK_SCSV isn't a standard cipher suite but an indicator
  340. // that the client is doing version fallback. See
  341. // https://tools.ietf.org/html/rfc7507.
  342. TLS_FALLBACK_SCSV uint16 = 0x5600
  343. )