aboutsummaryrefslogtreecommitdiff
path: root/src/crypto/tls/testdata
AgeCommit message (Collapse)Author
2025-07-09crypto/tls: empty server_name conf. ext. from serverDaniel McCarney
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>
2025-05-21crypto/tls: disable SHA-1 signature algorithms in TLS 1.2Filippo Valsorda
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>
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>
2025-03-13crypto/tls: add ConnectionState.CurveIDFilippo Valsorda
This required adding a new field to SessionState for TLS 1.0–1.2, since the key exchange is not repeated on resumption. The additional field is unfortunately not backwards compatible because current Go versions check that the encoding has no extra data at the end, but will cause cross-version tickets to be ignored. Relaxed that so we can add fields in a backwards compatible way the next time. For the cipher suite, we check that the session's is still acceptable per the Config. That would arguably make sense here, too: if a Config for example requires PQ, we should reject resumptions of connections that didn't use PQ. However, that only applies to pre-TLS 1.3 connections, since in TLS 1.3 we always do a fresh key exchange on resumption. Since PQ is the only main differentiator between key exchanges (aside from off-by-default non-PFS RSA, which are controlled by the cipher suite in TLS 1.0–1.2) and it's PQ-only, we can skip that check. Fixes #67516 Change-Id: I6a6a465681a6292edf66c7b8df8f4aba4171a76b Reviewed-on: https://go-review.googlesource.com/c/go/+/653315 Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
2024-11-19crypto/ecdsa: implement deterministic and hedged signaturesFilippo Valsorda
For the future, some test vectors we should generate and then share through Wycheproof or CCTV: - A private key with a leading zero byte. - A hash longer than the modulus. - A hash longer than the P-521 modulus by a few bits. - Reductions happening in hashToNat and bits2octets. Fixes #64802 Change-Id: Ia0f89781b2c78eedd5103cf0e9720630711c37ad Reviewed-on: https://go-review.googlesource.com/c/go/+/628681 TryBot-Bypass: Filippo Valsorda <filippo@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Filippo Valsorda <filippo@golang.org>
2024-05-22crypto/tls: reorder client_hello extensionsRoland Shoemaker
This sets us up for ECH, which need compressible extensions to be contiguous. Put them at the end to make things easier for everyone. Change-Id: I2a51f76d5fcd1b6d82325f5a4a8cde6d75f1be0c Reviewed-on: https://go-review.googlesource.com/c/go/+/585437 Reviewed-by: Filippo Valsorda <filippo@golang.org> Auto-Submit: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2024-05-22crypto/tls: clarify group selection logicFilippo Valsorda
I initially thought the logic was broken, but writing the test I realized it was actually very clever (derogative). It was relying on the outer loop continuing after a supported match without a key share, allowing a later key share to override it (but not a later supported match because of the "if selectedGroup != 0 { continue }"). Replaced the clever loop with two hopefully more understandable loops, and added a test (which was already passing). We were however not checking that the selected group is in the supported list if we found it in key shares first. (This was only a MAY.) Fixed. Fixes #65686 Change-Id: I09ea44f90167ffa36809deb78255ed039a217b6d Reviewed-on: https://go-review.googlesource.com/c/go/+/586655 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Filippo Valsorda <filippo@golang.org>
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>
2022-11-21crypto/ecdsa: use bigmod and nistec instead of math/big and crypto/ellipticFilippo Valsorda
Ignoring custom curves, this makes the whole package constant-time. There is a slight loss in performance for P-384 and P-521 because bigmod is slower than math/big (but P-256 has an assembly scalar field inversion, so doesn't use bigmod for anything big). name old time/op new time/op delta Sign/P256-8 19.2µs ± 2% 19.1µs ± 2% ~ (p=0.268 n=9+10) Sign/P384-8 166µs ± 3% 188µs ± 2% +13.52% (p=0.000 n=10+10) Sign/P521-8 337µs ± 2% 359µs ± 2% +6.46% (p=0.000 n=10+10) Verify/P256-8 58.1µs ± 2% 58.1µs ± 2% ~ (p=0.971 n=10+10) Verify/P384-8 484µs ± 2% 569µs ±12% +17.65% (p=0.000 n=10+10) Verify/P521-8 1.03ms ± 4% 1.14ms ± 2% +11.02% (p=0.000 n=10+10) GenerateKey/P256-8 12.4µs ±12% 12.0µs ± 2% ~ (p=0.063 n=10+10) GenerateKey/P384-8 129µs ±18% 119µs ± 2% ~ (p=0.190 n=10+10) GenerateKey/P521-8 241µs ± 2% 240µs ± 2% ~ (p=0.436 n=10+10) name old alloc/op new alloc/op delta Sign/P256-8 3.08kB ± 0% 2.47kB ± 0% -19.77% (p=0.000 n=10+10) Sign/P384-8 6.16kB ± 0% 2.64kB ± 0% -57.16% (p=0.000 n=10+10) Sign/P521-8 7.87kB ± 0% 3.01kB ± 0% -61.80% (p=0.000 n=10+10) Verify/P256-8 1.29kB ± 1% 0.48kB ± 0% -62.69% (p=0.000 n=10+10) Verify/P384-8 2.49kB ± 1% 0.64kB ± 0% -74.25% (p=0.000 n=10+10) Verify/P521-8 3.31kB ± 0% 0.96kB ± 0% -71.02% (p=0.000 n=7+10) GenerateKey/P256-8 720B ± 0% 920B ± 0% +27.78% (p=0.000 n=10+10) GenerateKey/P384-8 921B ± 0% 1120B ± 0% +21.61% (p=0.000 n=9+10) GenerateKey/P521-8 1.30kB ± 0% 1.44kB ± 0% +10.45% (p=0.000 n=10+10) name old allocs/op new allocs/op delta Sign/P256-8 45.0 ± 0% 33.0 ± 0% -26.67% (p=0.000 n=10+10) Sign/P384-8 69.0 ± 0% 34.0 ± 0% -50.72% (p=0.000 n=10+10) Sign/P521-8 71.0 ± 0% 35.0 ± 0% -50.70% (p=0.000 n=10+10) Verify/P256-8 23.0 ± 0% 10.0 ± 0% -56.52% (p=0.000 n=10+10) Verify/P384-8 43.0 ± 0% 14.0 ± 0% -67.44% (p=0.000 n=10+10) Verify/P521-8 45.0 ± 0% 14.0 ± 0% -68.89% (p=0.000 n=7+10) GenerateKey/P256-8 13.0 ± 0% 14.0 ± 0% +7.69% (p=0.000 n=10+10) GenerateKey/P384-8 16.0 ± 0% 17.0 ± 0% +6.25% (p=0.000 n=10+10) GenerateKey/P521-8 16.5 ± 3% 17.0 ± 0% +3.03% (p=0.033 n=10+10) Change-Id: I4e074ef039b0f7ffbc436a4cdbe4ef90c647018d Reviewed-on: https://go-review.googlesource.com/c/go/+/353849 Auto-Submit: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Filippo Valsorda <filippo@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org>
2021-06-10crypto/tls: let HTTP/1.1 clients connect to servers with NextProtos "h2"go1.17beta1Filippo Valsorda
Fixes #46310 Change-Id: Idd5e30f05c439f736ae6f3904cbb9cc2ba772315 Reviewed-on: https://go-review.googlesource.com/c/go/+/325432 Trust: Filippo Valsorda <filippo@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org>
2021-05-08crypto/tls: make cipher suite preference ordering automaticFilippo Valsorda
We now have a (well, two, depending on AES hardware support) universal cipher suite preference order, based on their security and performance. Peer and application lists are now treated as filters (and AES hardware support hints) that are applied to this universal order. This removes a complex and nuanced decision from the application's responsibilities, one which we are better equipped to make and which applications usually don't need to have an opinion about. It also lets us worry less about what suites we support or enable, because we can be confident that bad ones won't be selected over good ones. This also moves 3DES suites to InsecureCipherSuites(), even if they are not disabled by default. Just because we can keep them as a last resort it doesn't mean they are secure. Thankfully we had not promised that Insecure means disabled by default. Notable test changes: - TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the right certificate regardless of CipherSuite ordering, which is now completely ignored, as tested by TestCipherSuitePreference. Removed. - The openssl command of TestHandshakeServerExportKeyingMaterial was broken for TLS 1.0 in CL 262857, but its golden file was not regenerated, so the test kept passing. It now broke because the selected suite from the ones in the golden file changed. - In TestAESCipherReordering, "server strongly prefers AES-GCM" is removed because there is no way for a server to express a strong preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha" switched to ChaCha20 when the server lacks AES hardware; and finally "client supports multiple AES-GCM" changed to always prefer AES-128 per the universal preference list. * this is going back on an explicit decision from CL 262857, and while that client order is weird and does suggest a strong dislike for ChaCha20, we have a strong dislike for software AES, so it didn't feel worth making the logic more complex - All Client-* golden files had to be regenerated because the ClientHello cipher suites have changed. (Even when Config.CipherSuites was limited to one suite, the TLS 1.3 default order changed.) Fixes #45430 Fixes #41476 (as 3DES is now always the last resort) Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5 Reviewed-on: https://go-review.googlesource.com/c/go/+/314609 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Trust: Filippo Valsorda <filippo@golang.org>
2021-05-06crypto/tls: enforce ALPN overlap when negotiated on both sidesRoland Shoemaker
During the TLS handshake if the server doesn't support any of the application protocols requested by the client, send the no_application_protocol alert and abort the handshake on the server side. This enforces the requirements of RFC 7301. Change-Id: Iced2bb5c6efc607497de1c40ee3de9c2b393fa5d Reviewed-on: https://go-review.googlesource.com/c/go/+/289209 Trust: Roland Shoemaker <roland@golang.org> Trust: Katie Hockman <katie@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Filippo Valsorda <filippo@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>
2020-05-07crypto/tls: rotate session keys in older TLS versionsKatie Hockman
Also encode the certificates in a way that's more consistent with TLS 1.3 (with a 24 byte length prefix). Note that this will have an additional performance cost requiring clients to do a full handshake every 7 days where previously they were able to use the same ticket indefinitely. Updates #25256 Change-Id: Ic4d1ba0d92773c490b33b5f6c1320d557cc7347d Reviewed-on: https://go-review.googlesource.com/c/go/+/231317 Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
2019-11-12crypto/tls: take key size into account in signature algorithm selectionFilippo Valsorda
Fixes #29793 Change-Id: I6e389d166c2d9a2ba8664a41f4b9569f2481b27f Reviewed-on: https://go-review.googlesource.com/c/go/+/205177 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Katie Hockman <katie@golang.org>
2019-11-12crypto/tls: re-enable RSA-PSS in TLS 1.2 againFilippo Valsorda
TLS 1.3, which requires RSA-PSS, is now enabled without a GODEBUG opt-out, and with the introduction of Certificate.SupportedSignatureAlgorithms (#28660) there is a programmatic way to avoid RSA-PSS (disable TLS 1.3 with MaxVersion and use that field to specify only PKCS#1 v1.5 SignatureSchemes). This effectively reverts 0b3a57b5374bba3fdf88258e2be4c8be65e6a5de, although following CL 205061 all of the signing-side logic is conveniently centralized in signatureSchemesForCertificate. Fixes #32425 Change-Id: I7c9a8893bb5d518d86eae7db82612b9b2cd257d7 Reviewed-on: https://go-review.googlesource.com/c/go/+/205063 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Katie Hockman <katie@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2019-10-31crypto/tls: send ec_points_format extension in ServerHelloOlivier Poitrey
Follow the recommandation from RFC 8422, section 5.1.2 of sending back the ec_points_format extension when requested by the client. This is to fix some clients declining the handshake if omitted. Fixes #31943 Change-Id: I7b04dbac6f9af75cda094073defe081e1e9a295d Reviewed-on: https://go-review.googlesource.com/c/go/+/176418 Run-TryBot: Filippo Valsorda <filippo@golang.org> Reviewed-by: Olivier Poitrey <rs@rhapsodyk.net> Reviewed-by: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-10-04crypto/tls: remove NPN supportBrad Fitzpatrick
RELNOTE=yes Fixes #28362 Change-Id: I43813c0c17bbe6c4cbb4d1f121518c434b3f5aa8 Reviewed-on: https://go-review.googlesource.com/c/go/+/174329 Reviewed-by: Filippo Valsorda <filippo@golang.org>
2019-08-27crypto/tls: remove SSLv3 supportFilippo Valsorda
SSLv3 has been irreparably broken since the POODLE attack 5 years ago and RFC 7568 (f.k.a. draft-ietf-tls-sslv3-diediedie) prohibits its use in no uncertain terms. As announced in the Go 1.13 release notes, remove support for it entirely in Go 1.14. Updates #32716 Change-Id: Id653557961d8f75f484a01e6afd2e104a4ccceaf Reviewed-on: https://go-review.googlesource.com/c/go/+/191976 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-06-19crypto/tls: disable RSA-PSS in TLS 1.2 againFilippo Valsorda
Signing with RSA-PSS can uncover faulty crypto.Signer implementations, and it can fail for (broken) small keys. We'll have to take that breakage eventually, but it would be nice for it to be opt-out at first. TLS 1.3 requires RSA-PSS and is opt-out in Go 1.13. Instead of making a TLS 1.3 opt-out influence a TLS 1.2 behavior, let's wait to add RSA-PSS to TLS 1.2 until TLS 1.3 is on without opt-out. Note that since the Client Hello is sent before a protocol version is selected, we have to advertise RSA-PSS there to support TLS 1.3. That means that we still support RSA-PSS on the client in TLS 1.2 for verifying server certificates, which is fine, as all issues arise on the signing side. We have to be careful not to pick (or consider available) RSA-PSS on the client for client certificates, though. We'd expect tests to change only in TLS 1.2: * the server won't pick PSS to sign the key exchange (Server-TLSv12-* w/ RSA, TestHandshakeServerRSAPSS); * the server won't advertise PSS in CertificateRequest (Server-TLSv12-ClientAuthRequested*, TestClientAuth); * and the client won't pick PSS for its CertificateVerify (Client-TLSv12-ClientCert-RSA-*, TestHandshakeClientCertRSAPSS, Client-TLSv12-Renegotiate* because "R" requests a client cert). Client-TLSv13-ClientCert-RSA-RSAPSS was updated because of a fix in the test. This effectively reverts 88343530720a52c96b21f2bd5488c8fb607605d7. Testing was made more complex by the undocumented semantics of OpenSSL's -[client_]sigalgs (see openssl/openssl#9172). Updates #32425 Change-Id: Iaddeb2df1f5c75cd090cc8321df2ac8e8e7db349 Reviewed-on: https://go-review.googlesource.com/c/go/+/182339 Reviewed-by: Adam Langley <agl@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>
2019-02-27Revert "crypto/tls: disable RSA-PSS in TLS 1.2"Filippo Valsorda
In Go 1.13 we will enable RSA-PSS in TLS 1.2 at the same time as we make TLS 1.3 enabled by default. This reverts commit 7ccd3583eddcd79679fb29cfc83a6e6fb6973f1e. Updates #30055 Change-Id: I6f2ddf7652d1172a6b29f4e335ff3a71a89974bc Reviewed-on: https://go-review.googlesource.com/c/163080 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2019-02-07crypto/tls: disable RSA-PSS in TLS 1.2Filippo Valsorda
Most of the issues that led to the decision on #30055 were related to incompatibility with or faulty support for RSA-PSS (#29831, #29779, v1.5 signatures). RSA-PSS is required by TLS 1.3, but is also available to be negotiated in TLS 1.2. Altering TLS 1.2 behavior based on GODEBUG=tls13=1 feels surprising, so just disable RSA-PSS entirely in TLS 1.2 until TLS 1.3 is on by default, so breakage happens all at once. Updates #30055 Change-Id: Iee90454a20ded8895e5302e8bcbcd32e4e3031c2 Reviewed-on: https://go-review.googlesource.com/c/160998 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2018-11-30crypto/tls: fix client certificates support for legacy serversFilippo Valsorda
signatureSchemesForCertificate was written to be used with TLS 1.3, but ended up used for TLS 1.2 client certificates in a refactor. Since it only supported TLS 1.3 signature algorithms, it would lead to no RSA client certificates being sent to servers that didn't support RSA-PSS. TestHandshakeClientCertRSAPKCS1v15 was testing *specifically* for this, but alas the OpenSSL flag -verify accepts an empty certificates list as valid, as opposed to -Verify... Fixes #28925 Change-Id: I61afc02ca501d3d64ab4ad77bbb4cf10931e6f93 Reviewed-on: https://go-review.googlesource.com/c/151660 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2018-11-29crypto/tls: prevent the test server from sending session ticketsFilippo Valsorda
Since they are sent after the handshake in TLS 1.3, the client was not actually consuming them, as it doesn't make any Read calls. They were then sitting in the kernel receive buffer when the client would call Close. The kernel would see that and send a RST, which would race the closeNotify, causing errors. Also, we get to trim 600 lines of useless test data. Fixes #28852 Change-Id: I7517feab77dabab7504bfc111098ba09ea07ae5e Reviewed-on: https://go-review.googlesource.com/c/151659 Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-11-12crypto/tls: enable TLS 1.3 and update testsFilippo Valsorda
To disable TLS 1.3, simply remove VersionTLS13 from supportedVersions, as tested by TestEscapeRoute, and amend documentation. To make it opt-in, revert the change to (*Config).supportedVersions from this CL. I did not have the heart to implement the early data skipping feature when I realized that it did not offer a choice between two abstraction-breaking options, but demanded them both (look for handshake type in case of HelloRetryRequest, trial decryption otherwise). It's a lot of complexity for an apparently small gain, but if anyone has strong opinions about it let me know. Note that in TLS 1.3 alerts are encrypted, so the close_notify peeking to return (n > 0, io.EOF) from Read doesn't work. If we are lucky, those servers that unexpectedly close connections after serving a single request will have stopped (maybe thanks to H/2) before they got updated to TLS 1.3. Relatedly, session tickets are now provisioned on the client first Read instead of at Handshake time, because they are, well, post-handshake messages. If this proves to be a problem we might try to peek at them. Doubled the tests that cover logic that's different in TLS 1.3. The benchmarks for TLS 1.2 compared to be0f3c286b5 (before TLS 1.3 and its refactors, after CL 142817 changed them to use real connections) show little movement. name old time/op new time/op delta HandshakeServer/RSA-8 795µs ± 1% 798µs ± 1% ~ (p=0.057 n=10+18) HandshakeServer/ECDHE-P256-RSA-8 903µs ± 0% 909µs ± 1% +0.68% (p=0.000 n=8+17) HandshakeServer/ECDHE-P256-ECDSA-P256-8 198µs ± 0% 204µs ± 1% +3.24% (p=0.000 n=9+18) HandshakeServer/ECDHE-X25519-ECDSA-P256-8 202µs ± 3% 208µs ± 1% +2.98% (p=0.000 n=9+20) HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.5ms ± 1% 15.9ms ± 2% +2.49% (p=0.000 n=10+20) Throughput/MaxPacket/1MB-8 5.81ms ±23% 6.14ms ±44% ~ (p=0.605 n=8+18) Throughput/MaxPacket/2MB-8 8.91ms ±22% 8.74ms ±33% ~ (p=0.498 n=9+19) Throughput/MaxPacket/4MB-8 12.8ms ± 3% 14.0ms ±10% +9.74% (p=0.000 n=10+17) Throughput/MaxPacket/8MB-8 25.1ms ± 7% 24.6ms ±16% ~ (p=0.129 n=9+19) Throughput/MaxPacket/16MB-8 46.3ms ± 4% 45.9ms ±12% ~ (p=0.340 n=9+20) Throughput/MaxPacket/32MB-8 88.5ms ± 4% 86.0ms ± 4% -2.82% (p=0.004 n=10+20) Throughput/MaxPacket/64MB-8 173ms ± 2% 167ms ± 7% -3.42% (p=0.001 n=10+19) Throughput/DynamicPacket/1MB-8 5.88ms ± 4% 6.59ms ±64% ~ (p=0.232 n=9+18) Throughput/DynamicPacket/2MB-8 9.08ms ±12% 8.73ms ±21% ~ (p=0.408 n=10+18) Throughput/DynamicPacket/4MB-8 14.2ms ± 5% 14.0ms ±11% ~ (p=0.188 n=9+19) Throughput/DynamicPacket/8MB-8 25.1ms ± 6% 24.0ms ± 7% -4.39% (p=0.000 n=10+18) Throughput/DynamicPacket/16MB-8 45.6ms ± 3% 43.3ms ± 1% -5.22% (p=0.000 n=10+8) Throughput/DynamicPacket/32MB-8 88.4ms ± 3% 84.8ms ± 2% -4.06% (p=0.000 n=10+10) Throughput/DynamicPacket/64MB-8 175ms ± 3% 167ms ± 2% -4.63% (p=0.000 n=10+10) Latency/MaxPacket/200kbps-8 694ms ± 0% 694ms ± 0% -0.02% (p=0.000 n=9+9) Latency/MaxPacket/500kbps-8 279ms ± 0% 279ms ± 0% -0.09% (p=0.000 n=10+10) Latency/MaxPacket/1000kbps-8 140ms ± 0% 140ms ± 0% -0.15% (p=0.000 n=10+9) Latency/MaxPacket/2000kbps-8 71.1ms ± 0% 71.0ms ± 0% -0.09% (p=0.001 n=8+9) Latency/MaxPacket/5000kbps-8 30.5ms ± 6% 30.1ms ± 6% ~ (p=0.905 n=10+9) Latency/DynamicPacket/200kbps-8 134ms ± 0% 134ms ± 0% ~ (p=0.796 n=9+9) Latency/DynamicPacket/500kbps-8 54.8ms ± 0% 54.7ms ± 0% -0.18% (p=0.000 n=8+10) Latency/DynamicPacket/1000kbps-8 28.5ms ± 0% 29.1ms ± 8% ~ (p=0.173 n=8+10) Latency/DynamicPacket/2000kbps-8 15.3ms ± 6% 15.9ms ±10% ~ (p=0.905 n=9+10) Latency/DynamicPacket/5000kbps-8 9.14ms ±21% 9.65ms ±82% ~ (p=0.529 n=10+10) name old speed new speed delta Throughput/MaxPacket/1MB-8 175MB/s ±13% 167MB/s ±64% ~ (p=0.646 n=7+20) Throughput/MaxPacket/2MB-8 241MB/s ±25% 241MB/s ±40% ~ (p=0.660 n=9+20) Throughput/MaxPacket/4MB-8 328MB/s ± 3% 300MB/s ± 9% -8.70% (p=0.000 n=10+17) Throughput/MaxPacket/8MB-8 335MB/s ± 7% 340MB/s ±17% ~ (p=0.212 n=9+20) Throughput/MaxPacket/16MB-8 363MB/s ± 4% 367MB/s ±11% ~ (p=0.340 n=9+20) Throughput/MaxPacket/32MB-8 379MB/s ± 4% 390MB/s ± 4% +2.93% (p=0.004 n=10+20) Throughput/MaxPacket/64MB-8 388MB/s ± 2% 401MB/s ± 7% +3.25% (p=0.004 n=10+20) Throughput/DynamicPacket/1MB-8 178MB/s ± 4% 157MB/s ±73% ~ (p=0.127 n=9+20) Throughput/DynamicPacket/2MB-8 232MB/s ±11% 243MB/s ±18% ~ (p=0.415 n=10+18) Throughput/DynamicPacket/4MB-8 296MB/s ± 5% 299MB/s ±15% ~ (p=0.295 n=9+20) Throughput/DynamicPacket/8MB-8 334MB/s ± 6% 350MB/s ± 7% +4.58% (p=0.000 n=10+18) Throughput/DynamicPacket/16MB-8 368MB/s ± 3% 388MB/s ± 1% +5.48% (p=0.000 n=10+8) Throughput/DynamicPacket/32MB-8 380MB/s ± 3% 396MB/s ± 2% +4.20% (p=0.000 n=10+10) Throughput/DynamicPacket/64MB-8 384MB/s ± 3% 403MB/s ± 2% +4.83% (p=0.000 n=10+10) Comparing TLS 1.2 and TLS 1.3 at tip shows a slight (~5-10%) slowdown of handshakes, which might be worth looking at next cycle, but the latency improvements are expected to overshadow that. name old time/op new time/op delta HandshakeServer/ECDHE-P256-RSA-8 909µs ± 1% 963µs ± 0% +5.87% (p=0.000 n=17+18) HandshakeServer/ECDHE-P256-ECDSA-P256-8 204µs ± 1% 225µs ± 2% +10.20% (p=0.000 n=18+20) HandshakeServer/ECDHE-X25519-ECDSA-P256-8 208µs ± 1% 230µs ± 2% +10.35% (p=0.000 n=20+18) HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.9ms ± 2% 15.9ms ± 1% ~ (p=0.444 n=20+19) Throughput/MaxPacket/1MB-8 6.14ms ±44% 7.07ms ±46% ~ (p=0.057 n=18+19) Throughput/MaxPacket/2MB-8 8.74ms ±33% 8.61ms ± 9% ~ (p=0.552 n=19+17) Throughput/MaxPacket/4MB-8 14.0ms ±10% 14.1ms ±12% ~ (p=0.707 n=17+20) Throughput/MaxPacket/8MB-8 24.6ms ±16% 25.6ms ±14% ~ (p=0.107 n=19+20) Throughput/MaxPacket/16MB-8 45.9ms ±12% 44.7ms ± 6% ~ (p=0.607 n=20+19) Throughput/MaxPacket/32MB-8 86.0ms ± 4% 87.9ms ± 8% ~ (p=0.113 n=20+19) Throughput/MaxPacket/64MB-8 167ms ± 7% 169ms ± 2% +1.26% (p=0.011 n=19+19) Throughput/DynamicPacket/1MB-8 6.59ms ±64% 6.79ms ±43% ~ (p=0.480 n=18+19) Throughput/DynamicPacket/2MB-8 8.73ms ±21% 9.58ms ±13% +9.71% (p=0.006 n=18+20) Throughput/DynamicPacket/4MB-8 14.0ms ±11% 13.9ms ±10% ~ (p=0.687 n=19+20) Throughput/DynamicPacket/8MB-8 24.0ms ± 7% 24.6ms ± 8% +2.36% (p=0.045 n=18+17) Throughput/DynamicPacket/16MB-8 43.3ms ± 1% 44.3ms ± 2% +2.48% (p=0.001 n=8+9) Throughput/DynamicPacket/32MB-8 84.8ms ± 2% 86.7ms ± 2% +2.27% (p=0.000 n=10+10) Throughput/DynamicPacket/64MB-8 167ms ± 2% 170ms ± 3% +1.89% (p=0.005 n=10+10) Latency/MaxPacket/200kbps-8 694ms ± 0% 699ms ± 0% +0.65% (p=0.000 n=9+10) Latency/MaxPacket/500kbps-8 279ms ± 0% 280ms ± 0% +0.68% (p=0.000 n=10+10) Latency/MaxPacket/1000kbps-8 140ms ± 0% 141ms ± 0% +0.59% (p=0.000 n=9+9) Latency/MaxPacket/2000kbps-8 71.0ms ± 0% 71.3ms ± 0% +0.42% (p=0.000 n=9+9) Latency/MaxPacket/5000kbps-8 30.1ms ± 6% 30.7ms ±10% +1.93% (p=0.019 n=9+9) Latency/DynamicPacket/200kbps-8 134ms ± 0% 138ms ± 0% +3.22% (p=0.000 n=9+10) Latency/DynamicPacket/500kbps-8 54.7ms ± 0% 56.3ms ± 0% +3.03% (p=0.000 n=10+8) Latency/DynamicPacket/1000kbps-8 29.1ms ± 8% 29.1ms ± 0% ~ (p=0.173 n=10+8) Latency/DynamicPacket/2000kbps-8 15.9ms ±10% 16.4ms ±36% ~ (p=0.633 n=10+8) Latency/DynamicPacket/5000kbps-8 9.65ms ±82% 8.32ms ± 8% ~ (p=0.573 n=10+8) name old speed new speed delta Throughput/MaxPacket/1MB-8 167MB/s ±64% 155MB/s ±55% ~ (p=0.224 n=20+19) Throughput/MaxPacket/2MB-8 241MB/s ±40% 244MB/s ± 9% ~ (p=0.407 n=20+17) Throughput/MaxPacket/4MB-8 300MB/s ± 9% 298MB/s ±11% ~ (p=0.707 n=17+20) Throughput/MaxPacket/8MB-8 340MB/s ±17% 330MB/s ±13% ~ (p=0.201 n=20+20) Throughput/MaxPacket/16MB-8 367MB/s ±11% 375MB/s ± 5% ~ (p=0.607 n=20+19) Throughput/MaxPacket/32MB-8 390MB/s ± 4% 382MB/s ± 8% ~ (p=0.113 n=20+19) Throughput/MaxPacket/64MB-8 401MB/s ± 7% 397MB/s ± 2% -0.96% (p=0.030 n=20+19) Throughput/DynamicPacket/1MB-8 157MB/s ±73% 156MB/s ±39% ~ (p=0.738 n=20+20) Throughput/DynamicPacket/2MB-8 243MB/s ±18% 220MB/s ±14% -9.65% (p=0.006 n=18+20) Throughput/DynamicPacket/4MB-8 299MB/s ±15% 303MB/s ± 9% ~ (p=0.512 n=20+20) Throughput/DynamicPacket/8MB-8 350MB/s ± 7% 342MB/s ± 8% -2.27% (p=0.045 n=18+17) Throughput/DynamicPacket/16MB-8 388MB/s ± 1% 378MB/s ± 2% -2.41% (p=0.001 n=8+9) Throughput/DynamicPacket/32MB-8 396MB/s ± 2% 387MB/s ± 2% -2.21% (p=0.000 n=10+10) Throughput/DynamicPacket/64MB-8 403MB/s ± 2% 396MB/s ± 3% -1.84% (p=0.005 n=10+10) Fixes #9671 Change-Id: Ieb57c5140eb2c083b8be0d42b240cd2eeec0dcf6 Reviewed-on: https://go-review.googlesource.com/c/147638 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>
2018-11-12crypto/tls: implement TLS 1.3 PSK authentication (server side)Filippo Valsorda
Added some assertions to testHandshake, but avoided checking the error of one of the Close() because the one that would lose the race would write the closeNotify to a connection closed on the other side which is broken on js/wasm (#28650). Moved that Close() after the chan sync to ensure it happens second. Accepting a ticket with client certificates when NoClientCert is configured is probably not a problem, and we could hide them to avoid confusing the application, but the current behavior is to skip the ticket, and I'd rather keep behavior changes to a minimum. Updates #9671 Change-Id: I93b56e44ddfe3d48c2bef52c83285ba2f46f297a Reviewed-on: https://go-review.googlesource.com/c/147445 Reviewed-by: Adam Langley <agl@golang.org>
2018-11-12crypto/tls: implement TLS 1.3 middlebox compatibility modeFilippo Valsorda
Looks like the introduction of CCS records in the client second flight gave time to s_server to send NewSessionTicket messages in between the client application data and close_notify. There seems to be no way of turning NewSessionTicket messages off, neither by not sending a psk_key_exchange_modes extension, nor by command line flag. Interleaving the client write like that tickled an issue akin to #18701: on Windows, the client reaches Close() before the last record is drained from the send buffer, the kernel notices and resets the connection, cutting short the last flow. There is no good way of synchronizing this, so we sleep for a RTT before calling close, like in CL 75210. Sigh. Updates #9671 Change-Id: I44dc1cca17b373695b5a18c2741f218af2990bd1 Reviewed-on: https://go-review.googlesource.com/c/147419 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 KeyUpdate messagesFilippo Valsorda
Since TLS 1.3 delivers handshake messages (including KeyUpdate) after the handshake, the want argument to readRecord had became almost pointless: it only meant something when set to recordTypeChangeCipherSpec. Replaced it with a bool to reflect that, and added two shorthands to avoid anonymous bools in calls. Took the occasion to simplify and formalize the invariants of readRecord. The maxConsecutiveEmptyRecords loop became useless when readRecord started retrying on any non-advancing record in CL 145297. Replaced panics with errors, because failure is better than undefined behavior, but contained failure is better than a DoS vulnerability. For example, I suspect the panic at the top of readRecord was reachable from handleRenegotiation, which calls readHandshake with handshakeComplete false. Thankfully it was not a panic in 1.11, and it's allowed now. Removed Client-TLSv13-RenegotiationRejected because OpenSSL isn't actually willing to ask for renegotiation over TLS 1.3, the expected error was due to NewSessionTicket messages, which didn't break the rest of the tests because they stop too soon. Updates #9671 Change-Id: I297a81bde5c8020a962a92891b70d6d70b90f5e3 Reviewed-on: https://go-review.googlesource.com/c/147418 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2018-11-02crypto/tls: implement TLS 1.3 server handshake (base)Filippo Valsorda
Implement a basic TLS 1.3 server handshake, only enabled if explicitly requested with MaxVersion. This CL intentionally leaves for future CLs: - PSK modes and resumption - client authentication - compatibility mode ChangeCipherSpecs - early data skipping - post-handshake messages - downgrade protection - KeyLogWriter support - TLS_FALLBACK_SCSV processing It also leaves a few areas up for a wider refactor (maybe in Go 1.13): - the certificate selection logic can be significantly improved, including supporting and surfacing signature_algorithms_cert, but this isn't new in TLS 1.3 (see comment in processClientHello) - handshake_server_tls13.go can be dried up and broken into more meaningful, smaller functions, but it felt premature to do before PSK and client auth support - the monstrous ClientHello equality check in doHelloRetryRequest can get both cleaner and more complete with collaboration from the parsing layer, which can come at the same time as extension duplicates detection Updates #9671 Change-Id: Id9db2b6ecc2eea21bf9b59b6d1d9c84a7435151c Reviewed-on: https://go-review.googlesource.com/c/147017 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2018-11-02crypto/tls: implement TLS 1.3 client handshake (base)Filippo Valsorda
Implement a basic TLS 1.3 client handshake, only enabled if explicitly requested with MaxVersion. This CL intentionally leaves for future CLs: - PSK modes and resumption - client authentication - post-handshake messages - downgrade protection - KeyLogWriter support Updates #9671 Change-Id: Ieb6130fb6f25aea4f0d39e3a2448dfc942e1de7a Reviewed-on: https://go-review.googlesource.com/c/146559 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2018-11-02crypto/tls: advertise and accept rsa_pss_rsae signature algorithmsFilippo Valsorda
crypto/x509 already supports PSS signatures (with rsaEncryption OID), and crypto/tls support was added in CL 79736. Advertise support for the algorithms and accept them as a peer. Note that this is about PSS signatures from regular RSA public keys. RSA-PSS only public keys (with RSASSA-PSS OID) are supported in neither crypto/tls nor crypto/x509. See RFC 8446, Section 4.2.3. testdata/Server-TLSv12-ClientAuthRequested* got modified because the CertificateRequest carries the supported signature algorithms. The net/smtp tests changed because 512 bits keys are too small for PSS. Based on Peter Wu's CL 79738, who did all the actual work in CL 79736. Updates #9671 Change-Id: I4a31e9c6e152ff4c50a5c8a274edd610d5fff231 Reviewed-on: https://go-review.googlesource.com/c/146258 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2018-08-22crypto/tls: make ConnectionState.ExportKeyingMaterial a methodFilippo Valsorda
The unexported field is hidden from reflect based marshalers, which would break otherwise. Also, make it return an error, as there are multiple reasons it might fail. Fixes #27125 Change-Id: I92adade2fe456103d2d5c0315629ca0256953764 Reviewed-on: https://go-review.googlesource.com/130535 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-04-30crypto/tls: add examples for [Load]X509KeyPairKevin Burke
I was confused about how to start an HTTP server if the server cert/key are in memory, not on disk. I thought it would be good to show an example of how to use these two functions to accomplish that. example-cert.pem and example-key.pem were generated using crypto/tls/generate_cert.go. Change-Id: I850e1282fb1c38aff8bd9aeb51988d21fe307584 Reviewed-on: https://go-review.googlesource.com/72252 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2017-11-08crypto/tls: advertise support for SHA-512 signatures in 1.2Filippo Valsorda
This is the equivalent change to 1c105980 but for SHA-512. SHA-512 certificates are already supported by default since b53bb2ca, but some servers will refuse connections if the algorithm is not advertised in the overloaded signatureAndHash extension (see 09b238f1). This required adding support for SHA-512 signatures on CertificateVerify and ServerKeyExchange messages, because of said overloading. Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2 ClientHello even if the server picks a lower version. Closes #22422 Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105 Reviewed-on: https://go-review.googlesource.com/74950 Run-TryBot: Filippo Valsorda <hi@filippo.io> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2016-10-18crypto/tls: enable ChaCha20-Poly1305 cipher suites by default.Adam Langley
This change enables the ChaCha20-Poly1305 cipher suites by default. This changes the default ClientHello and thus requires updating all the tests. Change-Id: I6683a2647caaff4a11f9e932babb6f07912cad94 Reviewed-on: https://go-review.googlesource.com/30958 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-10-17crypto/tls: support ChaCha20-Poly1305.Adam Langley
This change adds support for the ChaCha20-Poly1305 AEAD to crypto/tls, as specified in https://tools.ietf.org/html/rfc7905. Fixes #15499. Change-Id: Iaa689be90e03f208c40b574eca399e56f3c7ecf1 Reviewed-on: https://go-review.googlesource.com/30957 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-10-12crypto/tls: enable X25519 by default.Adam Langley
Since this changes the offered curves in the ClientHello, all the test data needs to be updated too. Change-Id: I227934711104349c0f0eab11d854e5a2adcbc363 Reviewed-on: https://go-review.googlesource.com/30825 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-10-12crypto/tls: support X25519.Adam Langley
X25519 (RFC 7748) is now commonly used for key agreement in TLS connections, as specified in https://tools.ietf.org/html/draft-ietf-tls-curve25519-01. This change adds support for that in crypto/tls, but does not enabled it by default so that there's less test noise. A future change will enable it by default and will update all the test data at the same time. Change-Id: I91802ecd776d73aae5c65bcb653d12e23c413ed4 Reviewed-on: https://go-review.googlesource.com/30824 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-10-12crypto/tls: switch to OpenSSL 1.1.0 for test data.Adam Langley
We will need OpenSSL 1.1.0 in order to test some of the features expected for Go 1.8. However, 1.1.0 also disables (by default) some things that we still want to test, such as RC4, 3DES and SSLv3. Thus developers wanting to update the crypto/tls test data will need to build OpenSSL from source. This change updates the test data with transcripts generated by 1.1.0 (in order to reduce future diffs) and also causes a banner to be printed if 1.1.0 is not used when updating. (The test for an ALPN mismatch is removed because OpenSSL now terminates the connection with a fatal alert if no known ALPN protocols are offered. There's no point testing against this because it's an OpenSSL behaviour.) Change-Id: I957516975e0b8c7def84184f65c81d0b68f1c551 Reviewed-on: https://go-review.googlesource.com/30821 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-10-01crypto/tls: simplify keylog tests.Adam Langley
Since there's no aspect of key logging that OpenSSL can check for us, the tests for it might as well just connect to another goroutine as this is lower-maintainance. Change-Id: I746d1dbad1b4bbfc8ef6ccf136ee4824dbda021e Reviewed-on: https://go-review.googlesource.com/30089 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Joonas Kuorilehto <joneskoo@derbian.fi> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-08-27crypto/tls: add KeyLogWriter for debuggingJoonas Kuorilehto
Add support for writing TLS client random and master secret in NSS key log format. https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format Normally this is enabled by a developer debugging TLS based applications, especially HTTP/2, by setting the KeyLogWriter to an open file. The keys negotiated in handshake are then logged and can be used to decrypt TLS sessions e.g. in Wireshark. Applications may choose to add support similar to NSS where this is enabled by environment variable, but no such mechanism is built in to Go. Instead each application must explicitly enable. Fixes #13057. Change-Id: If6edd2d58999903e8390b1674ba4257ecc747ae1 Reviewed-on: https://go-review.googlesource.com/27434 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-08-18crypto/tls: support AES-128-CBC cipher suites with SHA-256.Adam Langley
These were new with TLS 1.2 and, reportedly, some servers require it. Since it's easy, this change adds suport for three flavours of AES-128-CBC with SHA-256 MACs. Other testdata/ files have to be updated because this changes the list of cipher suites offered by default by the client. Fixes #15487. Change-Id: I1b14330c31eeda20185409a37072343552c3464f Reviewed-on: https://go-review.googlesource.com/27315 Run-TryBot: Adam Langley <agl@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Jonathan Rudenberg <jonathan@titanous.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-08-17crypto/x509: require a NULL parameters for RSA public keys.Adam Langley
The RFC is clear that the Parameters in an AlgorithmIdentifer for an RSA public key must be NULL. BoringSSL enforces this so we have strong evidence that this is a widely compatible change. Embarrassingly enough, the major source of violations of this is us. Go used to get this correct in only one of two places. This was only fixed in 2013 (with 4874bc9b). That's why lots of test certificates are updated in this change. Fixes #16166. Change-Id: Ib9a4551349354c66e730d44eb8cee4ec402ea8ab Reviewed-on: https://go-review.googlesource.com/27312 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 06:12:12 +0000