crypto/tls: add support for TLS 1.3 #9671

mikioh · 2015-01-23T03:28:46Z

See https://tools.ietf.org/html/draft-ietf-tls-tls13.

Coexistence of IPv4 and IPv6 harms the net package.
Coexistence of HTTP/1.x and HTTP/2 will harm the net/http package.
For now looks coexistence of TLS 1.2 and 1.3 won't harm the crypto/tls package.
How about a variety of compositions on HTTP over TLS over IP?

bradfitz · 2015-01-23T08:12:16Z

Coexistence of IPv4 and IPv6 harms the net package.

Huh?

Coexistence of HTTP/1.x and HTTP/2 will harm the net/http package.

Huh?

This whole bug report seems to start on unfounded premises, or at least isn't clear.

rsc · 2015-04-10T04:05:54Z

The draft is still being updated. We can talk about having TLS 1.3 once it's actually an RFC.

[I have no idea what the text in the issue report body is supposed to mean, but the issue title is at least clear.]

joshuarubin · 2016-09-26T02:58:30Z

maybe it's time to consider this again?

minux · 2016-09-26T03:01:14Z

TLS 1.3 is still not approved, so I think we should delay this a bit further.

FiloSottile · 2016-11-12T20:21:44Z

https://go-review.googlesource.com/#/c/33115/ opened a branch for TLS 1.3 development.

gopherbot · 2016-11-12T20:40:09Z

CL https://golang.org/cl/33164 mentions this issue.

gopherbot · 2016-11-19T22:15:06Z

CL https://golang.org/cl/33416 mentions this issue.

gopherbot · 2016-11-20T15:35:06Z

CL https://golang.org/cl/33419 mentions this issue.

mholt · 2017-02-23T00:32:21Z

I see this is still "Unplanned" -- any possibility of getting this on track for Go 1.9? (Or is the final draft still too far out. I can never figure out where to find the status of these things.)

bradfitz · 2017-02-23T00:41:12Z

@FiloSottile is working on this. Status?

FiloSottile · 2017-02-23T19:17:36Z

The server codebase we are using is pretty battle tested and complete now, so the commits starting crypto/tls in https://github.com/cloudflare/tls-tris will make their way into CLs after cleanup. Some already did.

If @agl has the review bandwidth, I can probably power through the client implementation in March. (Or maybe we can consider shipping server first?)

BTW, @bradfitz it would be useful if I could submit for review on Gerrit commits I don't Author. There are a couple in there made by other people that agreed to have them submitted and signed the CLA.

(Feel free to assign me this issue.)

bradfitz · 2017-02-24T21:25:56Z

@FiloSottile, email me the list of author email addresses you wish to push forged commits to Gerrit with. I'll then check their CLAs and verify they're cool with you spoofing them. (Maybe cc them on your email to me and have them confirm?)

gopherbot · 2017-07-13T22:54:58Z

CL https://golang.org/cl/48455 mentions this issue.

gopherbot · 2017-07-13T22:54:58Z

CL https://golang.org/cl/48454 mentions this issue.


        crypto/tls: add RSASSA-PSS support for handshake messages

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 golang#9671 Change-Id: I8006b92e017453ae408c153233ce5ccef99b5c3f


        [RFC] crypto/tls: advertise PSS support, add tests

PSS signatures in X509 certificates are already supported, and now that handshake messages also support PSS, let's advertise it in the client and enable it for the server. Add test that checks for PSS signatures in (1) handshake messages and (2) certificates. Updates golang#9671 Tested with: go test -race crypto/tls -v -test.run TestHandshakeClientCertRSAPSS -args -update TODO update many other tests since signature_algorithms is updated. RFC force s_server to disable PSS for other tests, and use PKCS#1 v1.5? RFC ok to change tests to require openssl from git? Change-Id: I1b2ce2d13a07f5dda98b918313f3c581ce1d7b1d


        crypto/tls: add RSASSA-PSS support for handshake messages

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 golang#9671 Change-Id: I8006b92e017453ae408c153233ce5ccef99b5c3f


        [RFC] crypto/tls: advertise PSS support, add tests

PSS signatures in X509 certificates are already supported, and now that handshake messages also support PSS, let's advertise it in the client and enable it for the server. Add test that checks for PSS signatures in (1) handshake messages and (2) certificates. Updates golang#9671 Tested with: go test -race crypto/tls -v -test.run TestHandshakeClientCertRSAPSS -args -update TODO update many other tests since signature_algorithms is updated. RFC force s_server to disable PSS for other tests, and use PKCS#1 v1.5? RFC ok to change tests to require openssl from git? Change-Id: I1b2ce2d13a07f5dda98b918313f3c581ce1d7b1d

gopherbot · 2017-11-23T17:18:08Z

Change https://golang.org/cl/79738 mentions this issue: [RFC] crypto/tls: advertise PSS support, add tests

timcooijmans · 2018-11-09T08:08:10Z

@FiloSottile With this last commit, is TLS 1.3 support ready for testing?

FiloSottile · 2018-11-09T17:21:07Z

Once it gets merged (and this issue closed), you are very welcome to test TLS 1.3 by using Go master. Please file feedback and bugs as new GitHub issues and tag me. Note that the codebase will undergo much more testing before we are ok with shipping it in 1.12, so you shouldn't rely on its security the same way you shouldn't rely on master to be bug free.


        crypto/tls: implement TLS 1.3 KeyLogWriter support

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>


        crypto/tls: implement TLS 1.3 KeyUpdate messages

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>


        crypto/tls: implement TLS 1.3 middlebox compatibility mode

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>


        crypto/tls: implement TLS 1.3 PSK authentication (client side)

@santoshankr

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>


        crypto/tls: implement TLS 1.3 PSK authentication (server side)

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>


        crypto/tls: implement TLS 1.3 client authentication

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>


        crypto/tls: implement TLS 1.3 downgrade protection

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>

tie · 2018-11-15T09:19:06Z

@FiloSottile, thanks for your awesome work!

I've looked through the commits and didn't find anything related to the encrypted SNI. Are there any plans on implementing the spec? Mozilla and Cloudflare have already implemented ESNI (though it's currently not enabled by default in Firefox).

FiloSottile · 2018-11-16T23:40:26Z

We generally wait for the browsers to experiment with new TLS features before implementing them, and anyway we are extremely unlikely to implement an Internet-Draft, so there are no plans for encrypted SNI.

Also, crypto/tls has a high benefit/complexity bar, so we will want to wait until encrypted SNI is widely deployed before implementing it.

lvht · 2018-11-21T13:37:55Z

hi @FiloSottile , does the current implement support the 0-RRT?

bradfitz · 2018-11-21T14:22:13Z

@lvht, no, it does not. Not for Go 1.12.

lvht · 2018-11-21T15:01:44Z

@bradfitz is there a roadmap to implement the 0-RRT?

bradfitz · 2018-11-21T15:48:34Z

I can't find the email now, but I recall @FiloSottile saying somewhere it could come later once we have more time to think about the API for it. (For security reasons, it can't be automatic, but perhaps net/http's Transport could use it for idempotent requests on new connections...)

Henrocker · 2019-08-07T13:16:03Z

@FiloSottile Is there any update on the 0-rtt earlydata progress?

FiloSottile · 2019-08-07T18:10:33Z

@Henrocker It's not currently on the roadmap. It will also depend on how the ecosystem develops.

kf6nux · 2019-08-07T21:20:21Z

@Henrocker , did you mean to post that question to github.com/caddyserver/caddy ? They maintain their issues in their own repo.

rsc added this to the Unplanned milestone Apr 10, 2015

bradfitz modified the milestones: Go1.9Maybe, Unplanned Feb 23, 2017

bradfitz assigned FiloSottile Feb 24, 2017

bradfitz modified the milestones: Go1.10, Go1.9Maybe Jun 29, 2017

bradfitz added FeatureRequest NeedsFix labels Jun 29, 2017

ginuerzh mentioned this issue Aug 25, 2017

关于TLS的建议 #151

Closed

bradfitz modified the milestones: Go1.10, Go1.11 Nov 15, 2017

gopherbot closed this in 30cc978 Nov 12, 2018

htfy96 mentioned this issue Nov 15, 2018

TLS 1.3 #2080

Closed

slanterns mentioned this issue Nov 17, 2018

Feature Request: TLS 1.3 Support with Encrypted SNI #35

Open

htfy96 mentioned this issue Nov 17, 2018

TLS 1.3 support #28

Closed

francislavoie mentioned this issue Nov 18, 2018

feature request: encrypted SNI #2327

Open

lgcde mentioned this issue Nov 24, 2018

v2ray现在能不能用上tls1.3 #78

Closed

whalehub mentioned this issue Dec 6, 2018

Add TLS 1.3 to Go and Caddy #181

Closed

ldez mentioned this issue Dec 6, 2018

Support for TLS 1.3 #4275

Closed

J0WI mentioned this issue Jan 30, 2019

Support ESNI #7482

Open

ameshkov mentioned this issue Mar 9, 2019

Early data #35

Closed

Lekensteyn mentioned this issue Apr 3, 2019

Support ESNI #138

Open

ivandeex mentioned this issue Oct 5, 2019

1.49.4 is slow (uploading) vs 1.48 ? #3578

Closed

golang / go

Join GitHub today

crypto/tls: add support for TLS 1.3 #9671

crypto/tls: add support for TLS 1.3 #9671

Comments

mikioh commented Jan 23, 2015

This comment has been minimized.

bradfitz commented Jan 23, 2015

This comment has been minimized.

rsc commented Apr 10, 2015

This comment has been minimized.

joshuarubin commented Sep 26, 2016

This comment has been minimized.

minux commented Sep 26, 2016

This comment has been minimized.

FiloSottile commented Nov 12, 2016

This comment has been minimized.

gopherbot commented Nov 12, 2016

This comment has been minimized.

gopherbot commented Nov 19, 2016

This comment has been minimized.

gopherbot commented Nov 20, 2016

This comment has been minimized.

mholt commented Feb 23, 2017 • edited

This comment has been minimized.

bradfitz commented Feb 23, 2017

This comment has been minimized.

FiloSottile commented Feb 23, 2017

This comment has been minimized.

bradfitz commented Feb 24, 2017

This comment has been minimized.

gopherbot commented Jul 13, 2017

This comment has been minimized.

gopherbot commented Jul 13, 2017

This comment has been minimized.

gopherbot commented Nov 23, 2017

This comment has been minimized.

timcooijmans commented Nov 9, 2018

This comment has been minimized.

FiloSottile commented Nov 9, 2018 • edited

This comment has been minimized.

tie commented Nov 15, 2018

This comment has been minimized.

FiloSottile commented Nov 16, 2018 • edited

This comment has been minimized.

lvht commented Nov 21, 2018

This comment has been minimized.

bradfitz commented Nov 21, 2018

This comment has been minimized.

lvht commented Nov 21, 2018 • edited

This comment has been minimized.

bradfitz commented Nov 21, 2018

This comment has been minimized.

Henrocker commented Aug 7, 2019

This comment has been minimized.

FiloSottile commented Aug 7, 2019

This comment has been minimized.

kf6nux commented Aug 7, 2019

mholt commented Feb 23, 2017 •

edited

FiloSottile commented Nov 9, 2018 •

edited

FiloSottile commented Nov 16, 2018 •

edited

lvht commented Nov 21, 2018 •

edited