Merge tls1.3 #11
Merged
Merge tls1.3 #11
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ServerKeyExchange and CertificateVerify can share the same logic for picking a signature algorithm (based on the certificate public key and advertised algorithms), selecting a hash algorithm (depending on TLS version) and signature verification. Refactor the code to achieve code reuse, have common error checking (especially for intersecting supported signature algorithms) and to prepare for addition of new signature algorithms. Code should be easier to read since version-dependent logic is concentrated at one place. Change-Id: I978dec3815d28e33c3cfbc85f0c704b1894c25a3 Reviewed-on: https://go-review.googlesource.com/79735 Reviewed-by: Filippo Valsorda <filippo@golang.org> Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
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>
Use the dedicated AES* and PMULL* instructions to accelerate AES-GCM name old time/op new time/op delta AESGCMSeal1K-46 12.1µs ± 0% 0.9µs ± 0% -92.66% (p=0.000 n=9+10) AESGCMOpen1K-46 12.1µs ± 0% 0.9µs ± 0% -92.43% (p=0.000 n=10+10) AESGCMSign8K-46 58.6µs ± 0% 2.1µs ± 0% -96.41% (p=0.000 n=9+8) AESGCMSeal8K-46 92.8µs ± 0% 5.7µs ± 0% -93.86% (p=0.000 n=9+9) AESGCMOpen8K-46 92.9µs ± 0% 5.7µs ± 0% -93.84% (p=0.000 n=8+9) name old speed new speed delta AESGCMSeal1K-46 84.7MB/s ± 0% 1153.4MB/s ± 0% +1262.21% (p=0.000 n=9+10) AESGCMOpen1K-46 84.4MB/s ± 0% 1115.2MB/s ± 0% +1220.53% (p=0.000 n=10+10) AESGCMSign8K-46 140MB/s ± 0% 3894MB/s ± 0% +2687.50% (p=0.000 n=9+10) AESGCMSeal8K-46 88.2MB/s ± 0% 1437.5MB/s ± 0% +1529.30% (p=0.000 n=9+9) AESGCMOpen8K-46 88.2MB/s ± 0% 1430.5MB/s ± 0% +1522.01% (p=0.000 n=8+9) This change mirrors the current amd64 implementation, and provides optimal performance on a range of arm64 processors including Centriq 2400 and Apple A12. By and large it is implicitly tested by the robustness of the already existing amd64 implementation. The implementation interleaves GHASH with CTR mode to achieve the highest possible throughput, it also aggregates GHASH with a factor of 8, to decrease the cost of the reduction step. Even thought there is a significant amount of assembly, the code reuses the go code for the amd64 implementation, so there is little additional go code. Since AES-GCM is critical for performance of all web servers, this change is required to level the playfield for arm64 CPUs, where amd64 currently enjoys an unfair advantage. Ideally both amd64 and arm64 codepaths could be replaced by hypothetical AES and CLMUL intrinsics, with a few additional vector instructions. Fixes #18498 Fixes #19840 Change-Id: Icc57b868cd1f67ac695c1ac163a8e215f74c7910 Reviewed-on: https://go-review.googlesource.com/107298 Run-TryBot: Vlad Krasnov <vlad@cloudflare.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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>
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>
According to https://tools.ietf.org/html/rfc6962#section-3.3, the SCT must be at least one byte long. The parsing code correctly checks for this condition, but rarely the test does generate an empty SCT. Change-Id: If36a34985b4470a5a9f96affc159195c04f6bfad Reviewed-on: https://go-review.googlesource.com/c/129755 Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Use the format "RFC XXXX, Section X.X" (or "Appendix Y.X") as it fits more properly in prose than a link, is more future-proof, and as there are multiple ways to render an RFC. Capital "S" to follow the quoting standard of RFCs themselves. Applied the new goimports grouping to all files in those packages, too. Change-Id: I01267bb3a3b02664f8f822e97b129075bb14d404 Reviewed-on: https://go-review.googlesource.com/c/141918 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
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>
The crypto/tls record layer used a custom buffer implementation with its own semantics, freelist, and offset management. Replace it all with per-task bytes.Buffer, bytes.Reader and byte slices, along with a refactor of all the encrypt and decrypt code. The main quirk of *block was to do a best-effort read past the record boundary, so that if a closeNotify was waiting it would be peeked and surfaced along with the last Read. Address that with atLeastReader and ReadFrom to avoid a useless copy (instead of a LimitReader or CopyN). There was also an optimization to split blocks along record boundary lines without having to copy in and out the data. Replicate that by aliasing c.input into consumed c.rawInput (after an in-place decrypt operation). This is safe because c.rawInput is not used until c.input is drained. The benchmarks are noisy but look like an improvement across the board, which is a nice side effect :) name old time/op new time/op delta HandshakeServer/RSA-8 817µs ± 2% 797µs ± 2% -2.52% (p=0.000 n=10+9) HandshakeServer/ECDHE-P256-RSA-8 984µs ±11% 897µs ± 0% -8.89% (p=0.000 n=10+9) HandshakeServer/ECDHE-P256-ECDSA-P256-8 206µs ±10% 199µs ± 3% ~ (p=0.113 n=10+9) HandshakeServer/ECDHE-X25519-ECDSA-P256-8 204µs ± 3% 202µs ± 1% -1.06% (p=0.013 n=10+9) HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.5ms ± 0% 15.6ms ± 1% ~ (p=0.095 n=9+10) Throughput/MaxPacket/1MB-8 5.35ms ±19% 5.39ms ±36% ~ (p=1.000 n=9+10) Throughput/MaxPacket/2MB-8 9.20ms ±15% 8.30ms ± 8% -9.79% (p=0.035 n=10+9) Throughput/MaxPacket/4MB-8 13.8ms ± 7% 13.6ms ± 8% ~ (p=0.315 n=10+10) Throughput/MaxPacket/8MB-8 25.1ms ± 3% 23.2ms ± 2% -7.66% (p=0.000 n=10+9) Throughput/MaxPacket/16MB-8 46.9ms ± 1% 43.0ms ± 3% -8.29% (p=0.000 n=9+10) Throughput/MaxPacket/32MB-8 88.9ms ± 2% 82.3ms ± 2% -7.40% (p=0.000 n=9+9) Throughput/MaxPacket/64MB-8 175ms ± 2% 164ms ± 4% -6.18% (p=0.000 n=10+10) Throughput/DynamicPacket/1MB-8 5.79ms ±26% 5.82ms ±22% ~ (p=0.912 n=10+10) Throughput/DynamicPacket/2MB-8 9.23ms ±14% 9.50ms ±23% ~ (p=0.971 n=10+10) Throughput/DynamicPacket/4MB-8 14.5ms ±11% 13.8ms ± 6% -4.66% (p=0.019 n=10+10) Throughput/DynamicPacket/8MB-8 25.6ms ± 4% 23.5ms ± 3% -8.33% (p=0.000 n=10+10) Throughput/DynamicPacket/16MB-8 47.3ms ± 3% 44.6ms ± 7% -5.65% (p=0.000 n=10+10) Throughput/DynamicPacket/32MB-8 91.9ms ±14% 85.0ms ± 4% -7.55% (p=0.000 n=10+10) Throughput/DynamicPacket/64MB-8 177ms ± 2% 168ms ± 4% -4.97% (p=0.000 n=8+10) Latency/MaxPacket/200kbps-8 694ms ± 0% 694ms ± 0% ~ (p=0.315 n=10+9) Latency/MaxPacket/500kbps-8 279ms ± 0% 279ms ± 0% ~ (p=0.447 n=9+10) Latency/MaxPacket/1000kbps-8 140ms ± 0% 140ms ± 0% ~ (p=0.661 n=9+10) Latency/MaxPacket/2000kbps-8 71.1ms ± 0% 71.1ms ± 0% +0.05% (p=0.019 n=9+9) Latency/MaxPacket/5000kbps-8 30.4ms ± 7% 30.5ms ± 4% ~ (p=0.720 n=9+10) Latency/DynamicPacket/200kbps-8 134ms ± 0% 134ms ± 0% ~ (p=0.075 n=10+10) Latency/DynamicPacket/500kbps-8 54.8ms ± 0% 54.8ms ± 0% ~ (p=0.631 n=10+10) Latency/DynamicPacket/1000kbps-8 28.5ms ± 0% 28.5ms ± 0% ~ (p=1.000 n=8+8) Latency/DynamicPacket/2000kbps-8 15.7ms ±12% 16.1ms ± 0% ~ (p=0.109 n=10+7) Latency/DynamicPacket/5000kbps-8 8.20ms ±26% 8.17ms ±13% ~ (p=1.000 n=9+9) name old speed new speed delta Throughput/MaxPacket/1MB-8 193MB/s ±14% 202MB/s ±30% ~ (p=0.897 n=8+10) Throughput/MaxPacket/2MB-8 230MB/s ±14% 249MB/s ±17% ~ (p=0.089 n=10+10) Throughput/MaxPacket/4MB-8 304MB/s ± 6% 309MB/s ± 7% ~ (p=0.315 n=10+10) Throughput/MaxPacket/8MB-8 334MB/s ± 3% 362MB/s ± 2% +8.29% (p=0.000 n=10+9) Throughput/MaxPacket/16MB-8 358MB/s ± 1% 390MB/s ± 3% +9.08% (p=0.000 n=9+10) Throughput/MaxPacket/32MB-8 378MB/s ± 2% 408MB/s ± 2% +8.00% (p=0.000 n=9+9) Throughput/MaxPacket/64MB-8 384MB/s ± 2% 410MB/s ± 4% +6.61% (p=0.000 n=10+10) Throughput/DynamicPacket/1MB-8 178MB/s ±24% 182MB/s ±24% ~ (p=0.604 n=9+10) Throughput/DynamicPacket/2MB-8 228MB/s ±13% 225MB/s ±20% ~ (p=0.971 n=10+10) Throughput/DynamicPacket/4MB-8 291MB/s ±10% 305MB/s ± 6% +4.83% (p=0.019 n=10+10) Throughput/DynamicPacket/8MB-8 327MB/s ± 4% 357MB/s ± 3% +9.08% (p=0.000 n=10+10) Throughput/DynamicPacket/16MB-8 355MB/s ± 3% 376MB/s ± 6% +6.07% (p=0.000 n=10+10) Throughput/DynamicPacket/32MB-8 366MB/s ±12% 395MB/s ± 4% +7.91% (p=0.000 n=10+10) Throughput/DynamicPacket/64MB-8 380MB/s ± 2% 400MB/s ± 4% +5.26% (p=0.000 n=8+10) Note that this reduced the buffer for the first read from 1024 to 5+512, so it triggered the issue described at #24198 when using a synchronous net.Pipe: the first server flight was not being consumed entirely by the first read anymore, causing a deadlock as both the client and the server were trying to send (the client a reply to the ServerHello, the server the rest of the buffer). Fixed by rebasing on top of CL 142817. Change-Id: Ie31b0a572b2ad37878469877798d5c6a5276f931 Reviewed-on: https://go-review.googlesource.com/c/142818 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
This adds a crypto/tls.RecordHeaderError.Conn field containing the TLS underlying net.Conn for non-TLS handshake errors, and then uses it in the net/http Server to return plaintext HTTP 400 errors when a client mistakenly sends a plaintext HTTP request to an HTTPS server. This is the same behavior as Apache. Also in crypto/tls: swap two error paths to not use a value before it's valid, and don't send a alert record when a handshake contains a bogus TLS record (a TLS record in response won't help a non-TLS client). Fixes #23689 Change-Id: Ife774b1e3886beb66f25ae4587c62123ccefe847 Reviewed-on: https://go-review.googlesource.com/c/143177 Reviewed-by: Filippo Valsorda <filippo@golang.org>
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>
The equal methods were only there for testing, and I remember regularly getting them wrong while developing tls-tris. Replace them with simple reflect.DeepEqual calls. The only special thing that equal() would do is ignore the difference between a nil and a zero-length slice. Fixed the Generate methods so that they create the same value that unmarshal will decode. The difference is not important: it wasn't tested, all checks are "len(slice) > 0", and all cases in which presence matters are accompanied by a boolean. Change-Id: Iaabf56ea17c2406b5107c808c32f6c85b611aaa8 Reviewed-on: https://go-review.googlesource.com/c/144114 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
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>
As a first round, rewrite those handshake message types which can be reused in TLS 1.3 with golang.org/x/crypto/cryptobyte. All other types changed significantly in TLS 1.3 and will require separate implementations. They will be ported to cryptobyte in a later CL. The only semantic changes should be enforcing the random length on the marshaling side, enforcing a couple more "must not be empty" on the unmarshaling side, and checking the rest of the SNI list even if we only take the first. Change-Id: Idd2ced60c558fafcf02ee489195b6f3b4735fe22 Reviewed-on: https://go-review.googlesource.com/c/144115 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
Updates #28269 Change-Id: Iae765f85e6ae49f4b581161ed489b2f5ee27cdba Reviewed-on: https://go-review.googlesource.com/c/145737 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
This change will aid users to make less mistakes where you, for example, define both HTTP/1.1 and H2, but in the wrong order.
package main
import (
"crypto/tls"
"net"
)
func main() {
srv := &http.Server{
TLSConfig: &tls.Config{
NextProtos: []string{"http/1.1", "h2"},
},
}
srv.ListenAndServeTLS("server.crt", "server.key")
}
When using major browsers or curl, they will never be served H2 since they also support HTTP/1.0 and the list is processed in order.
Change-Id: Id14098b5e48f624ca308137917874d475c2f22a0
GitHub-Last-Rev: f3594a6411bf7dde71c850f3e85a2b5a21974129
GitHub-Pull-Request: golang/go#28367
Reviewed-on: https://go-review.googlesource.com/c/144387
Reviewed-by: Filippo Valsorda <filippo@golang.org>
I am working on a TLS server program, which issues new TLS certificates on demand. The new certificates will be added into tls.Config.Certificates. BuildNameToCertificate will be called to refresh the name table afterwards. This change will reduce some workload on existing certificates. Note that you can’t modify the Certificates field (or call BuildNameToCertificate) on a Config in use by a Server. You can however modify an unused Config that gets cloned in GetConfigForClient with appropriate locking. Change-Id: I7bdb7d23fc5d68df83c73f3bfa3ba9181d38fbde GitHub-Last-Rev: c3788f4116be47f2fdb777935c421e7dd694f5c8 GitHub-Pull-Request: golang/go#24920 Reviewed-on: https://go-review.googlesource.com/c/107627 Reviewed-by: Filippo Valsorda <filippo@golang.org>
Updates #9671 Change-Id: Ia68224aca866dc3c98af1fccbe56bfb3f22da9f6 Reviewed-on: https://go-review.googlesource.com/c/144578 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
Updates #9671 Change-Id: I1ea7b724975c0841d01f4536eebb23956b30d5ea Reviewed-on: https://go-review.googlesource.com/c/145297 Reviewed-by: Adam Langley <agl@golang.org>
Vendors golang.org/x/crypto/hkdf at e84da0312774c21d64ee2317962ef669b27ffb41 Updates #9671 Change-Id: I2610c4a66756e2a6f21f9823dcbe39edd9c9ea21 Reviewed-on: https://go-review.googlesource.com/c/145298 Reviewed-by: Adam Langley <agl@golang.org>
Note that there is significant code duplication due to extensions with the same format appearing in different messages in TLS 1.3. This will be cleaned up in a future refactor once CL 145317 is merged. Enforcing the presence/absence of each extension in each message is left to the upper layer, based on both protocol version and extensions advertised in CH and CR. Duplicated extensions and unknown extensions in SH, EE, HRR, and CT will be tightened up in a future CL. The TLS 1.2 CertificateStatus message was restricted to accepting only type OCSP as any other type (none of which are specified so far) would have to be negotiated. Updates #9671 Change-Id: I7c42394c5cc0af01faa84b9b9f25fdc6e7cfbb9e Reviewed-on: https://go-review.googlesource.com/c/145477 Reviewed-by: Adam Langley <agl@golang.org>
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>
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>
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>
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>
Now, this is embarrassing. While preparing CL 142818, I noticed a
possible vulnerability in the existing code which I was rewriting. I
took a note to go back and assess if it was indeed an issue, and in case
start the security release process. The note unintentionally slipped
into the commit. Fortunately, there was no vulnerability.
What caught my eye was that I had fixed the calculation of the minimum
encrypted payload length from
roundUp(explicitIVLen+macSize+1, blockSize)
to (using the same variable names)
explicitIVLen + roundUp(macSize+1, blockSize)
The explicit nonce sits outside of the encrypted payload, so it should
not be part of the value rounded up to the CBC block size.
You can see that for some values of the above, the old result could be
lower than the correct value. An unexpectedly short payload might cause
a panic during decryption (a DoS vulnerability) or even more serious
issues due to the constant time code that follows it (see for example
Yet Another Padding Oracle in OpenSSL CBC Ciphersuites [1]).
In practice, explicitIVLen is either zero or equal to blockSize, so it
does not change the amount of rounding up necessary and the two
formulations happen to be identical. Nothing to see here.
It looked more suspicious than it is in part due to the fact that the
explicitIVLen definition moved farther into hc.explicitNonceLen() and
changed name from IV (which suggests a block length) to nonce (which
doesn't necessarily). But anyway it was never meant to surface or be
noted, except it slipped, so here we are for a boring explanation.
[1] https://blog.cloudflare.com/yet-another-padding-oracle-in-openssl-cbc-ciphersuites/
Change-Id: I365560dfe006513200fa877551ce7afec9115fdf
Reviewed-on: https://go-review.googlesource.com/c/147637
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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>
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>
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>
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>
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>
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>
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>
…TLS 1.3 Fix a couple overlooked ConnectionState fields noticed by net/http tests, and add a test in crypto/tls. Spun off CL 147638 to keep that one cleanly about enabling TLS 1.3. Change-Id: I9a6c2e68d64518a44be2a5d7b0b7b8d78c98c95d Reviewed-on: https://go-review.googlesource.com/c/148900 Run-TryBot: Filippo Valsorda <filippo@golang.org> Reviewed-by: Andrew Bonventre <andybons@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
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>
The Config does not own the memory pointed to by the Certificate slice. Instead, opportunistically use Certificate.Leaf and let the application set it if it desires the performance gain. This is a partial rollback of CL 107627. See the linked issue for the full explanation. Fixes #28744 Change-Id: I33ce9e6712e3f87939d9d0932a06d24e48ba4567 Reviewed-on: https://go-review.googlesource.com/c/149098 Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
uTLS not adapted to this change yet, uTLS changes will be in a separate commmit.
gaukas
added a commit
that referenced
this pull request
Aug 2, 2023
* sync: merge with upstream tag/go-1.21rc3 (#11) * fix: all tests pass * impl: UQUIC Transport * deps: bump up min Go version * new: uquic * fix: add QUICTransportParameter --------- Co-authored-by: Russ Cox <rsc@golang.org> Co-authored-by: Filippo Valsorda <filippo@golang.org> Co-authored-by: Filippo Valsorda <hi@filippo.io> Co-authored-by: Katie Hockman <katie@golang.org> Co-authored-by: Ainar Garipov <gugl.zadolbal@gmail.com> Co-authored-by: Brad Fitzpatrick <bradfitz@golang.org> Co-authored-by: fenos <fabri.feno@gmail.com> Co-authored-by: Bryan C. Mills <bcmills@google.com> Co-authored-by: Josh Bleecher Snyder <josharian@gmail.com> Co-authored-by: Olivier Poitrey <rs@netflix.com> Co-authored-by: Ville Skyttä <ville.skytta@iki.fi> Co-authored-by: Alex Harford <alex.harford@saucelabs.com> Co-authored-by: Johan Jansson <johan.jansson@iki.fi> Co-authored-by: Ziheng Liu <lzhfromustc@gmail.com> Co-authored-by: Chris Le Roy <brompwnie@users.noreply.github.com> Co-authored-by: Brad Fitzpatrick <brad@danga.com> Co-authored-by: Dmitri Shuralyov <dmitshur@golang.org> Co-authored-by: Roland Shoemaker <rolandshoemaker@gmail.com> Co-authored-by: Daniel <cpu@letsencrypt.org> Co-authored-by: Chen.Zhidong <njutczd@gmail.com> Co-authored-by: Cherry Zhang <cherryyz@google.com> Co-authored-by: Luca Spiller <luca@stackednotion.com> Co-authored-by: Thom Wiggers <thom@thomwiggers.nl> Co-authored-by: cch123 <buaa.cch@gmail.com> Co-authored-by: Johan Brandhorst <johan.brandhorst@gmail.com> Co-authored-by: Roland Shoemaker <roland@golang.org> Co-authored-by: John Bampton <jbampton@gmail.com> Co-authored-by: Matt T. Proud <matt.proud@gmail.com> Co-authored-by: Naman Gera <namangera15@gmail.com> Co-authored-by: vinckr <vincent@ory.sh> Co-authored-by: Sofía Celi <cherenkovd69@gmail.com> Co-authored-by: Watson Ladd <watson@cloudflare.com> Co-authored-by: Agniva De Sarker <agnivade@yahoo.co.in> Co-authored-by: Heschi Kreinick <heschi@google.com> Co-authored-by: Chressie Himpel <chressie@google.com> Co-authored-by: Dan Kortschak <dan@kortschak.io> Co-authored-by: Nicolas Hillegeer <aktau@google.com> Co-authored-by: Ian Lance Taylor <iant@golang.org> Co-authored-by: Lasse Folger <lassefolger@google.com> Co-authored-by: Daniel Martí <mvdan@mvdan.cc> Co-authored-by: David Taylor <tinystatemachine@gmail.com> Co-authored-by: Tatiana Bradley <tatiana@golang.org> Co-authored-by: cuiweixie <cuiweixie@gmail.com> Co-authored-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Co-authored-by: Ludi Rehak <ludi317@gmail.com> Co-authored-by: Mike Faraponov <mikefaraponov@gmail.com> Co-authored-by: Abirdcfly <fp544037857@gmail.com> Co-authored-by: cui fliter <imcusg@gmail.com> Co-authored-by: Gabor Tanz <gabor.tanz@swisscom.com> Co-authored-by: Tobias Klauser <tklauser@distanz.ch> Co-authored-by: Anit Gandhi <agandhi@digitalocean.com> Co-authored-by: Tero Saarni <tero.saarni@gmail.com> Co-authored-by: Sebastiaan van Stijn <github@gone.nl> Co-authored-by: Damien Neil <dneil@google.com> Co-authored-by: Monis Khan <i@monis.app> Co-authored-by: Marten Seemann <martenseemann@gmail.com>
gaukas
added a commit
that referenced
this pull request
Aug 4, 2023
* sync: Go 1.21rc3, QUIC support added (#207) * sync: merge with upstream tag/go-1.21rc3 (#11) * fix: all tests pass * impl: UQUIC Transport * deps: bump up min Go version * new: uquic * fix: add QUICTransportParameter * deprecated: Go 1.19 no longer supported Go 1.19 will fail to build or pass the test once we bump up to the new version. * sync: crypto/tls: restrict RSA keys in certificates to <= 8192 bits (#209) * [release-branch.go1.21] crypto/tls: restrict RSA keys in certificates to <= 8192 bits Extremely large RSA keys in certificate chains can cause a client/server to expend significant CPU time verifying signatures. Limit this by restricting the size of RSA keys transmitted during handshakes to <= 8192 bits. Based on a survey of publicly trusted RSA keys, there are currently only three certificates in circulation with keys larger than this, and all three appear to be test certificates that are not actively deployed. It is possible there are larger keys in use in private PKIs, but we target the web PKI, so causing breakage here in the interests of increasing the default safety of users of crypto/tls seems reasonable. Thanks to Mateusz Poliwczak for reporting this issue. Fixes CVE-2023-29409 * build: [ci skip] boring not included * fix: typo [ci skip] * docs: replenish readme [ci skip] replace old build status badge with new ones, bump up required version noted in docs, update developer contact to reflect current status.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Does not include any parrots(mimicry specs for browsers and other popular clients) yet.