aboutsummaryrefslogtreecommitdiff
path: root/src/crypto/tls/testdata/Server-TLSv13-ClientAuthRequestedNotGiven
AgeCommit message (Collapse)Author
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>