aboutsummaryrefslogtreecommitdiff
path: root/src/crypto/tls/handshake_client_test.go
AgeCommit message (Collapse)Author
2023-02-14crypto/tls: replace all usages of BytesOrPanicRoland Shoemaker
Message marshalling makes use of BytesOrPanic a lot, under the assumption that it will never panic. This assumption was incorrect, and specifically crafted handshakes could trigger panics. Rather than just surgically replacing the usages of BytesOrPanic in paths that could panic, replace all usages of it with proper error returns in case there are other ways of triggering panics which we didn't find. In one specific case, the tree routed by expandLabel, we replace the usage of BytesOrPanic, but retain a panic. This function already explicitly panicked elsewhere, and returning an error from it becomes rather painful because it requires changing a large number of APIs. The marshalling is unlikely to ever panic, as the inputs are all either fixed length, or already limited to the sizes required. If it were to panic, it'd likely only be during development. A close inspection shows no paths for a user to cause a panic currently. This patches ends up being rather large, since it requires routing errors back through functions which previously had no error returns. Where possible I've tried to use helpers that reduce the verbosity of frequently repeated stanzas, and to make the diffs as minimal as possible. Thanks to Marten Seemann for reporting this issue. Fixes #58001 Fixes CVE-2022-41724 Change-Id: Ieb55867ef0a3e1e867b33f09421932510cb58851 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1679436 Reviewed-by: Julie Qiu <julieqiu@google.com> TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/468125 Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Michael Pratt <mpratt@google.com>
2022-04-08all: consistently use US spelling of present participlesDaniel Martí
It has been agreed that we should prefer the US spelling of words like "canceling" over "cancelling"; for example, see https://go.dev/cl/14526. Fix a few occurrences of the "canceling" inconsistency, as well as: * signaling * tunneling * marshaling Change-Id: I99f3ba0a700a9f0292bc6c1b110af31dd05f1ff0 Reviewed-on: https://go-review.googlesource.com/c/go/+/398734 Trust: Daniel Martí <mvdan@mvdan.cc> Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2021-12-13all: gofmt -w -r 'interface{} -> any' srcRuss Cox
And then revert the bootstrap cmd directories and certain testdata. And adjust tests as needed. Not reverting the changes in std that are bootstrapped, because some of those changes would appear in API docs, and we want to use any consistently. Instead, rewrite 'any' to 'interface{}' in cmd/dist for those directories when preparing the bootstrap copy. A few files changed as a result of running gofmt -w not because of interface{} -> any but because they hadn't been updated for the new //go:build lines. Fixes #49884. Change-Id: Ie8045cba995f65bd79c694ec77a1b3d1fe01bb09 Reviewed-on: https://go-review.googlesource.com/c/go/+/368254 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-10-06all: use bytes.Cut, strings.CutRuss Cox
Many uses of Index/IndexByte/IndexRune/Split/SplitN can be written more clearly using the new Cut functions. Do that. Also rewrite to other functions if that's clearer. For #46336. Change-Id: I68d024716ace41a57a8bf74455c62279bde0f448 Reviewed-on: https://go-review.googlesource.com/c/go/+/351711 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@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>
2021-04-16crypto/tls: fix flaky handshake cancellation testsJohan Brandhorst
Simplified both tests significantly by removing logic for writing the client/server side messages. The flake was likely because of a race between the closing of the local pipe from inside the test and closing of the pipe from within the handshakeContext goroutine. Wait to close the local pipe in the test until after the test has finished running. Fixes #45106 Fixes #45299 Change-Id: If7ca75aeff7df70cda03c934fa9d8513276d465d Reviewed-on: https://go-review.googlesource.com/c/go/+/305250 Trust: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Trust: Katie Hockman <katie@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
2021-03-17crypto/tls: remove flaky cancellation testJohan Brandhorst
This will be reintroduced again once the source of the flakiness has been determined and fixed. Fixes #45084 Change-Id: I6677b27fcd71e8c9bb8edbe8e3be70e5a271ebd3 Reviewed-on: https://go-review.googlesource.com/c/go/+/302569 Trust: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Trust: Katie Hockman <katie@golang.org> Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Run-TryBot: Katie Hockman <katie@golang.org> Reviewed-by: Katie Hockman <katie@golang.org> TryBot-Result: Go Bot <gobot@golang.org>
2021-03-16crypto/tls: add HandshakeContext method to ConnJohan Brandhorst
Adds the (*tls.Conn).HandshakeContext method. This allows us to pass the context provided down the call stack to eventually reach the tls.ClientHelloInfo and tls.CertificateRequestInfo structs. These contexts are exposed to the user as read-only via Context() methods. This allows users of (*tls.Config).GetCertificate and (*tls.Config).GetClientCertificate to use the context for request scoped parameters and cancellation. Replace uses of (*tls.Conn).Handshake with (*tls.Conn).HandshakeContext where appropriate, to propagate existing contexts. Fixes #32406 Change-Id: I259939c744bdc9b805bf51a845a8bc462c042483 Reviewed-on: https://go-review.googlesource.com/c/go/+/295370 Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Katie Hockman <katie@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
2021-03-13all: remove duplicate wordsJohn Bampton
Change-Id: Ib0469232a2b69a869e58d5d24990ad74ac96ea56 GitHub-Last-Rev: eb38e049ee1e773392ff3747e1eb2af20dd50dcd GitHub-Pull-Request: golang/go#44805 Reviewed-on: https://go-review.googlesource.com/c/go/+/299109 Trust: Emmanuel Odeke <emmanuel@orijtech.com> Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2021-02-24docs: fix spellingJohn Bampton
Change-Id: Ib689e5793d9cb372e759c4f34af71f004010c822 GitHub-Last-Rev: d63798388e5dcccb984689b0ae39b87453b97393 GitHub-Pull-Request: golang/go#44259 Reviewed-on: https://go-review.googlesource.com/c/go/+/291949 Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Matthew Dempsky <mdempsky@google.com> Trust: Robert Griesemer <gri@golang.org>
2020-12-17crypto/tls: revert "add HandshakeContext method to Conn"Johan Brandhorst
This reverts CL 246338. Reason for revert: waiting for 1.17 release cycle Updates #32406 Change-Id: I074379039041e086c62271d689b4b7f442281663 Reviewed-on: https://go-review.googlesource.com/c/go/+/269697 Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Katie Hockman <katie@golang.org> Trust: Katie Hockman <katie@golang.org> Trust: Roland Shoemaker <roland@golang.org>
2020-11-09crypto/tls: add HandshakeContext method to ConnJohan Brandhorst
Adds the (*tls.Conn).HandshakeContext method. This allows us to pass the context provided down the call stack to eventually reach the tls.ClientHelloInfo and tls.CertificateRequestInfo structs. These contexts are exposed to the user as read-only via Context() methods. This allows users of (*tls.Config).GetCertificate and (*tls.Config).GetClientCertificate to use the context for request scoped parameters and cancellation. Replace uses of (*tls.Conn).Handshake with (*tls.Conn).HandshakeContext where appropriate, to propagate existing contexts. Fixes #32406 Change-Id: I33c228904fe82dcf57683b63627497d3eb841ff2 Reviewed-on: https://go-review.googlesource.com/c/go/+/246338 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Trust: Roland Shoemaker <roland@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
2020-06-09crypto/tls: restore OCSP and SCTs during session resumptionRoland Shoemaker
Restore previously sent SCTs and stapled OCSP response during session resumption for both TLS 1.2 and 1.3. This behavior is somewhat complicated for TLS 1.2 as SCTs are sent during the server hello, so they override what is saved in ClientSessionState. It is likely that if the server is sending a different set of SCTs there is probably a reason for doing so, such as a log being retired, or SCT validation requirements changing, so it makes sense to defer to the server in that case. Fixes #39075 Change-Id: I3c0fa2f69c6bf0247a447c48a1b4c733a882a233 Reviewed-on: https://go-review.googlesource.com/c/go/+/234237 Reviewed-by: Filippo Valsorda <filippo@golang.org>
2020-06-04crypto/tls: set CipherSuite for VerifyConnectionKatie Hockman
The ConnectionState's CipherSuite was not set prior to the VerifyConnection callback in TLS 1.2 servers, both for full handshakes and resumptions. Change-Id: Iab91783eff84d1b42ca09c8df08e07861e18da30 Reviewed-on: https://go-review.googlesource.com/c/go/+/236558 Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
2020-06-03crypto/tls: fix duplicate calls to VerifyConnectionKatie Hockman
Also add a test that could reproduce this error and ensure it doesn't occur in other configurations. Fixes #39012 Change-Id: If792b5131f312c269fd2c5f08c9ed5c00188d1af Reviewed-on: https://go-review.googlesource.com/c/go/+/233957 Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
2020-05-18crypto/tls: persist the createdAt time when re-wrapping session ticketsKatie Hockman
Change-Id: I33fcde2d544943fb04c2599810cf7fb773aeba1f Reviewed-on: https://go-review.googlesource.com/c/go/+/234483 Run-TryBot: Katie Hockman <katie@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-05-08crypto/tls: add Config.VerifyConnection callbackKatie Hockman
Since the ConnectionState will now be available during verification, some code was moved around in order to initialize and make available as much of the fields on Conn as possible before the ConnectionState is verified. Fixes #36736 Change-Id: I0e3efa97565ead7de5c48bb8a87e3ea54fbde140 Reviewed-on: https://go-review.googlesource.com/c/go/+/229122 Run-TryBot: Katie Hockman <katie@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-05-08crypto/tls: rotate session ticket keysKatie Hockman
Automatically rotate session ticket keys for servers that don't already have sessionTicketKeys and that haven't called SetSessionTicketKeys. Now, session ticket keys will be rotated every 24 hours with a lifetime of 7 days. This adds a small performance cost to existing clients that don't provide a session ticket encrypted with a fresh enough session ticket key, which would require a full handshake. Updates #25256 Change-Id: I15b46af7a82aab9a108bceb706bbf66243a1510f Reviewed-on: https://go-review.googlesource.com/c/go/+/230679 Run-TryBot: Katie Hockman <katie@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Filippo Valsorda <filippo@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>
2020-05-05crypto/tls: enforce TLS 1.3 (and TLS 1.2) downgrade protection checksFilippo Valsorda
Fixes #37763 Change-Id: Ic6bcc9af0d164966f4ae31087998e5b546540038 Reviewed-on: https://go-review.googlesource.com/c/go/+/231038 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Katie Hockman <katie@golang.org>
2020-02-27all: fix incorrect channel and API usage in some unit testsZiheng Liu
This CL changes some unit test functions, making sure that these tests (and goroutines spawned during test) won't block. Since they are just test functions, I use one CL to fix them all. I hope this won't cause trouble to reviewers and can save time for us. There are three main categories of incorrect logic fixed by this CL: 1. Use testing.Fatal()/Fatalf() in spawned goroutines, which is forbidden by Go's document. 2. Channels are used in such a way that, when errors or timeout happen, the test will be blocked and never return. 3. Channels are used in such a way that, when errors or timeout happen, the test can return but some spawned goroutines will be leaked, occupying resource until all other tests return and the process is killed. Change-Id: I3df931ec380794a0cf1404e632c1dd57c65d63e8 Reviewed-on: https://go-review.googlesource.com/c/go/+/219380 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@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-11-04crypto/tls: make -update only regenerate transcripts for failing testsFilippo Valsorda
Change-Id: Ie68fd4fe2879e6b5417a1a4240971e3d837bf115 Reviewed-on: https://go-review.googlesource.com/c/go/+/204377 Run-TryBot: Filippo Valsorda <filippo@golang.org> Run-TryBot: Katie Hockman <katie@golang.org> Reviewed-by: Katie Hockman <katie@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-06-20crypto/tls: move shared code and resources to handshake_test.goFilippo Valsorda
Removed cross-dependencies between handshake_server_test.go and handshake_client_test.go; moved all initialization to TestMain; replaced SSLKEYLOGFILE environment variable with -keylog flag. Change-Id: Ida6712daa44e01a2c00658e8a1896087ee88bcb0 Reviewed-on: https://go-review.googlesource.com/c/go/+/183057 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@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-22all: shorten some testsRuss Cox
Shorten some of the longest tests that run during all.bash. Removes 7r 50u 21s from all.bash. After this change, all.bash is under 5 minutes again on my laptop. For #26473. Change-Id: Ie0460aa935808d65460408feaed210fbaa1d5d79 Reviewed-on: https://go-review.googlesource.com/c/go/+/177559 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@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-26crypto/tls: fix typoYasser Abdolmaleki
Change-Id: If9332bae87449c94fc14710133614fcd84d2815c Reviewed-on: https://go-review.googlesource.com/c/161726 Reviewed-by: Filippo Valsorda <filippo@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 downgrade protectionFilippo Valsorda
TLS_FALLBACK_SCSV is extremely fragile in the presence of sparse supported_version, but gave it the best try I could. Set the server random canaries but don't check them yet, waiting for the browsers to clear the way of misbehaving middleboxes. Updates #9671 Change-Id: Ie55efdec671d639cf1e716acef0c5f103e91a7ce Reviewed-on: https://go-review.googlesource.com/c/147617 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 PSK authentication (client side)Filippo Valsorda
Also check original certificate validity when resuming TLS 1.0–1.2. Will refuse to resume a session if the certificate is expired or if the original connection had InsecureSkipVerify and the resumed one doesn't. Support only PSK+DHE to protect forward secrecy even with lack of a strong session ticket rotation story. Tested with NSS because s_server does not provide any way of getting the same session ticket key across invocations. Will self-test like TLS 1.0–1.2 once server side is implemented. Incorporates CL 128477 by @santoshankr. Fixes #24919 Updates #9671 Change-Id: Id3eaa5b6c77544a1357668bf9ff255f3420ecc34 Reviewed-on: https://go-review.googlesource.com/c/147420 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-12crypto/tls: implement TLS 1.3 KeyLogWriter supportFilippo Valsorda
Also, add support for the SSLKEYLOGFILE environment variable to the tests, to simplify debugging of unexpected failures. Updates #9671 Change-Id: I20a34a5824f083da93097b793d51e796d6eb302b Reviewed-on: https://go-review.googlesource.com/c/147417 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-11-02crypto/tls: implement TLS 1.3 version negotiationFilippo Valsorda
RFC 8446 recommends using the supported_versions extension to negotiate lower versions as well, so begin by implementing it to negotiate the currently supported versions. Note that pickTLSVersion was incorrectly negotiating the ServerHello version down on the client. If the server had illegally sent a version higher than the ClientHello version, the client would have just downgraded it, hopefully failing later in the handshake. In TestGetConfigForClient, we were hitting the record version check because the server would select TLS 1.1, the handshake would fail on the client which required TLS 1.2, which would then send a TLS 1.0 record header on its fatal alert (not having negotiated a version), while the server would expect a TLS 1.1 header at that point. Now, the client gets to communicate the minimum version through the extension and the handshake fails on the server. Updates #9671 Change-Id: Ie33c7124c0c769f62e10baad51cbed745c424e5b Reviewed-on: https://go-review.googlesource.com/c/146217 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2018-10-27crypto/tls: bump test timeouts from 1s to 1m for slow buildersFilippo Valsorda
The arm5 and mips builders are can't-send-a-packet-to-localhost-in-1s slow apparently. 1m is less useful, but still better than an obscure test timeout panic. Fixes #28405 Change-Id: I2feeae6ea1b095114caccaab4f6709f405faebad Reviewed-on: https://go-review.googlesource.com/c/145037 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-10-25crypto/tls: add timeouts to recorded testsFilippo Valsorda
If something causes the recorded tests to deviate from the expected flows, they might wait forever for data that is not coming. Add a short timeout, after which a useful error message is shown. Change-Id: Ib11ccc0e17dcb8b2180493556017275678abbb08 Reviewed-on: https://go-review.googlesource.com/c/144116 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2018-10-19crypto/tls: replace net.Pipe in tests with real TCP connectionsFilippo Valsorda
crypto/tls is meant to work over network connections with buffering, not synchronous connections, as explained in #24198. Tests based on net.Pipe are unrealistic as reads and writes are matched one to one. Such tests worked just thanks to the implementation details of the tls.Conn internal buffering, and would break if for example the flush of the first flight of the server was not entirely assimilated by the client rawInput buffer before the client attempted to reply to the ServerHello. Note that this might run into the Darwin network issues at #25696. Fixed a few test races that were either hidden or synchronized by the use of the in-memory net.Pipe. Also, this gets us slightly more realistic benchmarks, reflecting some syscall cost of Read and Write operations. Change-Id: I5a597b3d7a81b8ccc776030cc837133412bf50f8 Reviewed-on: https://go-review.googlesource.com/c/142817 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@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-07-25crypto/tls: fix deadlock when Read and Close called concurrentlyMinaev Mike
The existing implementation of TLS connection has a deadlock. It occurs when client connects to TLS server and doesn't send data for handshake, so server calls Close on this connection. This is because server reads data under locked mutex, while Close method tries to lock the same mutex. Fixes #23518 Change-Id: I4fb0a2a770f3d911036bfd9a7da7cc41c1b27e19 Reviewed-on: https://go-review.googlesource.com/90155 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
2018-06-27crypto/tls: add RSASSA-PSS support for handshake messagesPeter Wu
This adds support for RSASSA-PSS signatures in handshake messages as required by TLS 1.3. Even if TLS 1.2 is negotiated, it must support PSS when advertised in the Client Hello (this will be done later as the testdata will change). Updates #9671 Change-Id: I8006b92e017453ae408c153233ce5ccef99b5c3f Reviewed-on: https://go-review.googlesource.com/79736 Reviewed-by: Filippo Valsorda <filippo@golang.org>
2017-09-27all: prefer bytes.IndexByte over bytes.IndexMarvin Stenger
bytes.IndexByte can be used wherever the second argument to strings.Index is exactly one byte long, so we do that with this change. This avoids generating unnecessary string symbols/converison and saves a few calls to bytes.Index. Change-Id: If31c775790e01edfece1169e398ad6a754fb4428 Reviewed-on: https://go-review.googlesource.com/66373 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 05:03:42 +0000