Check for invalid encodings and keys more systematically in
ParseRawPrivateKey/PrivateKey.Bytes,
ParseUncompressedPublicKey/PublicKey.Bytes, and
fips140/ecdsa.NewPrivateKey/NewPublicKey.
Also, use these functions throughout the codebase.
This should not change any observable behavior, because there were
multiple layers of checks and every path would hit at least one.
Change-Id: I6a6a46566c95de871a5a37996835a0e51495f1d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/724000
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This commit adds fields to the ClientHelloInfo and ConnectionState
structures to represent hello retry request state information.
ClientHelloInfo gains a new HelloRetryRequest bool field that indicates
if the client hello was sent in response to a TLS 1.3 hello retry
request message previously emitted by the server.
ConnectionState gains a new HelloRetryRequest bool field that indicates
(depending on the connection role) whether the client received a TLS 1.3
hello retry request message from the server, or whether the server sent
such a message to a client.
Fixes#74425
Change-Id: Ic1a5290b8a4ba1568da1d2c2cf9f148150955fa5
Reviewed-on: https://go-review.googlesource.com/c/go/+/717440
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
A hash object needs to be cloned when doing certain steps in a
TLS 1.3 server handshake. It is more efficient to use the
hash.Cloner interface to clone a hash than to encode and decode
the hash object using the binary encoding interfaces.
We still need to support the binary encoding path in case the
hash objects come from the fips140 v1.0.0 module, given that
this module doesn't support the hash.Cloner interface.
Change-Id: I8425e14e481dcefafc9aa1e5bfd63b61c22675ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/682597
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The different chacha20-poly1305 cipher suites were renamed to
include the _SHA256 suffix, which is the canonical naming convention.
The occurrences of the old names were still not updated, which can lead
to confusion when searching for the canonical names in the codebase.
Change-Id: I4f90e9cbedc3552c3481c8b0c616b6f915ddd345
Reviewed-on: https://go-review.googlesource.com/c/go/+/689135
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
When a TLS server uses the information from the server_name extension in
a client hello, and the connection isn't resuming, it should return an
empty server_name extension in its server hello (or encrypted extensions
for TLS 1.3).
For TLS <1.3 we we do this in doFullHandshake(), by setting the
pre-existing serverHelloMsg.serverNameAck bool. We know that the
connection isn't resuming based on the context where this function is
called.
For TLS 1.3, a new encryptedExtensionsMsg.serverNameAck bool is added,
and populated as appropriate in sendServerParameters() based on whether
the conn was resumed or not. The encryptedExtensionsMsg marshalling is
updated to emit the encrypted extension based on that field.
These changes allow enabling the ServerNameExtensionServer-* bogo tests
that verify both the presence and absence of the server_name extension
based on the relevant specifications.
Resolves#74282
Updates #72006
Change-Id: I703bc2ec916b50906bdece7b7483a7faed7aa8e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/684795
TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
When a TLS 1.3 client processes the server's encryptedExtensionsMsg it
should reject instances that contain duplicate extension types.
RFC 8446 §4.2 says:
There MUST NOT be more than one extension of the same type in a given
extension block.
This update matches enforcement done in the client hello unmarshalling,
but applied to the TLS 1.3 encrypted extensions message unmarshalling.
Making this change also allows enabling the
DuplicateExtensionClient-TLS-TLS13 BoGo test.
Updates #72006
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/673757
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Previously if instances of the handshakeMessage interface returned false
from unmarshal(), indicating an umarshalling error, the crypto/tls
package would emit an unexpected_message alert. This commit changes to
use a decode_error alert for this condition instead.
The usage-pattern of the handshakeMessage interface is that we switch on
the message type, invoke a specific concrete handshakeMessage type's
unmarshal function, and then return it to the caller on success. At this
point the caller looks at the message type and can determine if the
message was unexpected or not. If it was unexpected, the call-sites emit
the correct error for that case. Only the caller knows the current
protocol state and allowed message types, not the generic handshake
decoding logic.
With the above in mind, if we find that within the unmarshal logic for
a specific message type that the data we have in hand doesn't match the
protocol syntax we should emit a decode_error. An unexpected_message
error isn't appropriate because we don't yet know if the message is
unexpected or not, only that the message can't be decoded based on the
spec's syntax for the type the message claimed to be.
Notably one unit test, TestQUICPostHandshakeKeyUpdate, had to have its
test data adjusted because it was previously not testing the right
thing: it was double-encoding the type & length prefix data for a key
update message and expecting the QUIC logic to reject it as an
inappropriate post-handshake message. In reality it was being rejected
sooner as an invalid key update message from the double-encoding and
this was masked by the previous alert for this condition matching the
expected alert.
Finally, changing our alert allows enabling a handful of BoGo tests
related to duplicate extensions of the form
"DuplicateExtension[Server|Client]-TLS-[TLS1|TLS11|TLS12|TLS13]". One
test remains skipped (DuplicateExtensionClient-TLS-TLS13), as it
requires additional follow-up.
Updates #72006
Change-Id: I27a2cd231e4b8762b0d9e2dbd3d8ddd5b87fd5d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/673738
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
This implements RFC 9155 by removing support for SHA-1 algorithms:
- we don't advertise them in ClientHello and CertificateRequest
(where supportedSignatureAlgorithms is used directly)
- we don't select them in our ServerKeyExchange and CertificateVerify
(where supportedSignatureAlgorithms filters signatureSchemesForCertificate)
- we reject them in the peer's ServerKeyExchange and CertificateVerify
(where we check against the algorithms we advertised in ClientHello
and CertificateRequest)
Fixes#72883
Change-Id: I6a6a4656e2aafd2c38cdd32090d3d8a9a8047818
Reviewed-on: https://go-review.googlesource.com/c/go/+/658216
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Filippo Valsorda <filippo@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
yuhan6665