aboutsummaryrefslogtreecommitdiff
path: root/src/crypto/tls/testdata/Server-TLSv13-ClientAuthRequestedNotGiven
AgeCommit message (Collapse)Author
2025-05-21crypto/tls: don't advertise TLS 1.2-only sigAlgs in TLS 1.3Filippo Valsorda
If a ClientHello only supports TLS 1.3, or if a CertificateRequest is sent after selecting TLS 1.3, we should not advertise TLS 1.2-only signature_algorithms like PKCS#1 v1.5 or SHA-1. However, since crypto/x509 still supports PKCS#1 v1.5, and a direct CertPool match might not care about the signature in the certificate at all, start sending a separate signature_algorithms_cert extension to indicate support for PKCS#1 v1.5 and SHA-1 in certificates. We were already correctly rejecting these algorithms if the peer selected them in a TLS 1.3 connection. Updates #72883 Change-Id: I6a6a4656ab60e1b7fb20fdedc32604dc156953ae Reviewed-on: https://go-review.googlesource.com/c/go/+/658215 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
2023-05-25crypto/tls: don't reverify but check certificate expiration on resumptionFilippo Valsorda
We used to inconsistently run certificate verification on the server on resumption, but not on the client. This made TLS 1.3 resumption pretty much useless, as it didn't save bytes, CPU, or round-trips. This requires serializing the verified chains into the session ticket, so it's a tradeoff making the ticket bigger to save computation (and for consistency). The previous behavior also had a "stickyness" issue: if a ticket contained invalid certificates, they would be used even if the client had in the meantime configured valid certificates for a full handshake. We also didn't check expiration on the client side on resumption if InsecureSkipVerify was set. Again for consistency, we do that now. Also, we used to run VerifyPeerCertificates on resumption even if NoClientCerts was set. Fixes #31641 Change-Id: Icc88269ea4adb544fa81158114aae76f3c91a15f Reviewed-on: https://go-review.googlesource.com/c/go/+/497895 Reviewed-by: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org>
2023-05-25crypto/tls: implement Extended Master SecretFilippo Valsorda
All OpenSSL tests now test operation with EMS. To test a handshake *without* EMS we need to pass -Options=-ExtendedMasterSecret which is only available in OpenSSL 3.1, which breaks a number of other tests. Updates #43922 Change-Id: Ib9ac79a1d03fab6bfba5fe9cd66689cff661cda7 Reviewed-on: https://go-review.googlesource.com/c/go/+/497376 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Damien Neil <dneil@google.com>
2023-05-25crypto/tls: add QUIC 0-RTT APIsFilippo Valsorda
Fixes #60107 Change-Id: I158b1c2d80d8ebb5ed7a8e6f313f69060754e220 Reviewed-on: https://go-review.googlesource.com/c/go/+/496995 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-05-24crypto/tls: add SessionState.ExtraFilippo Valsorda
This can be used by applications to store additional data in a session. Fixes #57753 For #60105 Change-Id: Ib42387ad64750fa8dbbdf51de5e9c86378bef0ee Reviewed-on: https://go-review.googlesource.com/c/go/+/496822 Run-TryBot: Filippo Valsorda <filippo@golang.org> Reviewed-by: Marten Seemann <martenseemann@gmail.com> Reviewed-by: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2023-05-24crypto/tls: add SessionState and use it on the server sideFilippo Valsorda
This change by itself is useless, because the application has no way to access or provide SessionStates to crypto/tls, but they will be provided in following CLs. For #60105 Change-Id: I8d5de79b1eda0a778420134cf6f346246a1bb296 Reviewed-on: https://go-review.googlesource.com/c/go/+/496818 Reviewed-by: Marten Seemann <martenseemann@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Filippo Valsorda <filippo@golang.org>
2023-05-24crypto/tls: reduce session ticket linkabilityFilippo Valsorda
Ever since session ticket key rotation was introduced in CL 9072, we've been including a prefix in every ticket to identify what key it's encrypted with. It's a small privacy gain, but the cost of trial decryptions is also small, especially since the first key is probably the most frequently used. Also reissue tickets on every resumption so that the next connection can't be linked to all the previous ones. Again the privacy gain is small but the performance cost is small and it comes with a reduction in complexity. For #60105 Change-Id: I852f297162d2b79a3d9bf61f6171e8ce94b2537a Reviewed-on: https://go-review.googlesource.com/c/go/+/496817 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2020-11-10crypto/tls: de-prioritize AES-GCM ciphers when lacking hardware supportRoland Shoemaker
When either the server or client are lacking hardware support for AES-GCM ciphers, indicated by the server lacking the relevant instructions and by the client not putting AES-GCM ciphers at the top of its preference list, reorder the preference list to de-prioritize AES-GCM based ciphers when they are adjacent to other AEAD ciphers. Also updates a number of recorded openssl TLS tests which previously only specified TLS 1.2 cipher preferences (using -cipher), but not TLS 1.3 cipher preferences (using -ciphersuites), to specify both preferences, making these tests more predictable. Fixes #41181. Change-Id: Ied896c96c095481e755aaff9ff0746fb4cb9568e Reviewed-on: https://go-review.googlesource.com/c/go/+/262857 Run-TryBot: Roland Shoemaker <roland@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> Trust: Roland Shoemaker <roland@golang.org> Trust: Katie Hockman <katie@golang.org>
2019-05-17crypto/tls: add support for Ed25519 certificates in TLS 1.2 and 1.3Filippo Valsorda
Support for Ed25519 certificates was added in CL 175478, this wires them up into the TLS stack according to RFC 8422 (TLS 1.2) and RFC 8446 (TLS 1.3). RFC 8422 also specifies support for TLS 1.0 and 1.1, and I initially implemented that, but even OpenSSL doesn't take the complexity, so I just dropped it. It would have required keeping a buffer of the handshake transcript in order to do the direct Ed25519 signatures. We effectively need to support TLS 1.2 because it shares ClientHello signature algorithms with TLS 1.3. While at it, reordered the advertised signature algorithms in the rough order we would want to use them, also based on what curves have fast constant-time implementations. Client and client auth tests changed because of the change in advertised signature algorithms in ClientHello and CertificateRequest. Fixes #25355 Change-Id: I9fdd839afde4fd6b13fcbc5cc7017fd8c35085ee Reviewed-on: https://go-review.googlesource.com/c/go/+/177698 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2018-11-12crypto/tls: implement TLS 1.3 client authenticationFilippo Valsorda
Note that the SignatureSchemes passed to GetClientCertificate in TLS 1.2 are now filtered by the requested certificate type. This feels like an improvement anyway, and the full list can be surfaced as well when support for signature_algorithms_cert is added, which actually matches the semantics of the CertificateRequest signature_algorithms in TLS 1.2. Also, note a subtle behavior change in server side resumption: if a certificate is requested but not required, and the resumed session did not include one, it used not to invoke VerifyPeerCertificate. However, if the resumed session did include a certificate, it would. (If a certificate was required but not in the session, the session is rejected in checkForResumption.) This inconsistency could be unexpected, even dangerous, so now VerifyPeerCertificate is always invoked. Still not consistent with the client behavior, which does not ever invoke VerifyPeerCertificate on resumption, but it felt too surprising to entirely change either. Updates #9671 Change-Id: Ib2b0dbc30e659208dca3ac07d6c687a407d7aaaf Reviewed-on: https://go-review.googlesource.com/c/147599 Reviewed-by: Adam Langley <agl@golang.org>