ConfirmHandshake should block on a Read until the handshakeConfirmed
state is reached, but past that it shouldn't.

See https://groups.google.com/forum/#!topic/golang-dev/Xxiai-R_jH0

Change-Id: I6052695ece9aff9e3112c2fb176596fde8aa9cb2

Phase should only be accessed under in.Mutex. Handshake and all Read
operations obtain that lock. However, many functions checking for
handshakeRunning only obtain handshakeMutex: reintroduce
handshakeCompleted for them. ConnectionState and Close check for
handshakeConfirmed, introduce an atomic flag for them.

There is no reason a server can't just send a CloseNotify in its first
flight, and then close the connection without reading the 0-RTT data.

Also, it's not expected of Close to block on reading, and interlocking
with a Read can cause a deadlock.

Fixes NCC-2016-001

Fixes NCC-2016-002

I opted for adding a separate TLS13CipherSuites field to the Config
because library users that did not set Config.MaxVersion are
supposed to get TLS 1.3 support automatically, like it has been for
HTTP/2, but having set CipherSuites would effectively disable it.

Updates #9671

Change-Id: I26a2776b68374d6f5ee45629da09f9494fe723ad

Updates #9671

Change-Id: Ia1b06ae518a4b2821a584a420d99859a2666c8f0

Opening the 1.3 dances with the record layer because it has been the
most stable through the drafts, has the least dependencies, and has been
tricky in my experience.

Note that the record layer version check is entirely removed according
to https://tools.ietf.org/html/draft-ietf-tls-tls13-18#appendix-C.2.

A test that happened to hit that check (but was not made to test for it)
has changed to the next error in the stack.

There are no 1.3 tests at the moment, and I suspect they will all have to
wait for the patch cycle to reach interoperability.

Using > / <= VersionTLS13 for all conditionals to transparently support
draft versions and hypotetical future versions.

See https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-5.

Updates #9671

Change-Id: I97f0a59439728f194a1c50b48cff041469a0f00b

Closes #21519

Change-Id: I1247e9435de93aae7e4db2b6e8e5be1b010c296b
Reviewed-on: https://go-review.googlesource.com/56832
Reviewed-by: Avelino <t@avelino.xxx>
Reviewed-by: Adam Langley <agl@golang.org>

Detected by BoGo test FragmentAcrossChangeCipherSpec-Server-Packed.

Change-Id: I9a76697b9cdeb010642766041971de5c7e533481
Reviewed-on: https://go-review.googlesource.com/48811
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>

name                                       time/op
HandshakeServer/RSA-4                      1.10ms ± 0%
HandshakeServer/ECDHE-P256-RSA-4           1.23ms ± 1%
HandshakeServer/ECDHE-P256-ECDSA-P256-4     178µs ± 1%
HandshakeServer/ECDHE-X25519-ECDSA-P256-4   180µs ± 2%
HandshakeServer/ECDHE-P521-ECDSA-P521-4    19.8ms ± 1%

Change-Id: I6b2c79392995d259cfdfc5199be44cc7cc40e155
Reviewed-on: https://go-review.googlesource.com/44730
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>

The processClientKeyExchange and processServerKeyExchange functions unmarshal an
encoded EC point and explicitly check whether the point is on the curve. The explicit
check can be omitted because elliptic.Unmarshal fails if the point is not on the curve
and the returned error would always be the same.

Fixes #20496

Change-Id: I5231a655eace79acee2737dd036a0c255ed42dbb
Reviewed-on: https://go-review.googlesource.com/44311
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Avelino <t@avelino.xxx>
Run-TryBot: Adam Langley <agl@golang.org>

Change-Id: I23bfaa7e03a21aad4e85baa3bf52bb00c09b75d0
Reviewed-on: https://go-review.googlesource.com/44354
Reviewed-by: Adam Langley <agl@golang.org>

Updates #20164.

Change-Id: Ib900095e7885f25cd779750674a712c770603ca8
Reviewed-on: https://go-review.googlesource.com/42137
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Users (like myself) may be tempted to think the higher-numbered curve
is somehow better or more secure, but P256 is currently the best
ECDSA implementation, due to its better support in TLS clients, and a
constant time implementation.

For example, sites that present a certificate signed with P521
currently fail to load in Chrome stable, and the error on the Go side
says simply "remote error: tls: illegal parameter".

Fixes #19901.

Change-Id: Ia5e689e7027ec423624627420e33029c56f0bd82
Reviewed-on: https://go-review.googlesource.com/40211
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Using GetClientCertificate with the http client is currently completely
broken because inside the transport we clone the tls.Config and pass it
off to the tls.Client. Since tls.Config.Clone() does not pass forward
the GetClientCertificate field, GetClientCertificate is ignored in this
context.

Fixes #19264

Change-Id: Ie214f9f0039ac7c3a2dab8ffd14d30668bdb4c71
Signed-off-by: Mike Danese <mikedanese@google.com>
Reviewed-on: https://go-review.googlesource.com/37541
Reviewed-by: Filippo Valsorda <hi@filippo.io>
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

An io.Reader does not guarantee that it will read in the entire buffer.
To ensure that property, io.ReadFull should be used instead.

Change-Id: I0b863135ab9abc40e813f9dac07bfb2a76199950
Reviewed-on: https://go-review.googlesource.com/37403
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

There's no need to hold the handshake lock across this call and it can
lead to deadlocks if the net.Conn calls back into the tls.Conn.

Fixes #18426.

Change-Id: Ib1b2813cce385949d970f8ad2e52cfbd1390e624
Reviewed-on: https://go-review.googlesource.com/36561
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Link in the description of TLSUnique field of ConnectionState struct
leads to an article that is no longer available, so this commit
replaces it with link to a copy of the very same article on another
site.

Fixes #18842.

Change-Id: I8f8d298c4774dc0fbbad5042db0684bb3220aee8
Reviewed-on: https://go-review.googlesource.com/36052
Reviewed-by: Filippo Valsorda <hi@filippo.io>
Reviewed-by: Adam Langley <agl@golang.org>

This change clarifies that only ticket-based resumption is supported by
crypto/tls. It's not clear where to document this for a server,
although perhaps it's obvious there because there's nowhere to plug in
the storage that would be needed by SessionID-based resumption.

Fixes #18607

Change-Id: Iaaed53e8d8f2f45c2f24c0683052df4be6340922
Reviewed-on: https://go-review.googlesource.com/36560
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: Ib47e295e8646b769c30fd81e5c7f20f964df163e
Reviewed-on: https://go-review.googlesource.com/36335
Reviewed-by: Filippo Valsorda <hi@filippo.io>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

SNI values may not include a trailing dot according to
https://tools.ietf.org/html/rfc6066#section-3. Although crypto/tls
handled this correctly as a client, it didn't reject this as a server.

This change makes sending an SNI value with a trailing dot a fatal
error.

Updates #18114.

Change-Id: Ib7897ab40e98d4a7a4646ff8469a55233621f631
Reviewed-on: https://go-review.googlesource.com/33904
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

ConnectionState.NegotiatedProtocol's documentation implies that it will
always be from Config.NextProtos. This commit clarifies that there is no
guarantee.

This commit also adds a note to
ConnectionState.NegotiatedProtocolIsMutual, making it clear that it is
client side only.

Fixes #18841

Change-Id: Icd028af8042f31e45575f1080c5e9bd3012e03d7
Reviewed-on: https://go-review.googlesource.com/35917
Reviewed-by: Filippo Valsorda <hi@filippo.io>
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

As is, they were fully vulnerable to the Lucky13 attack. The SHA1
variants implement limited countermeasures (see f28cf8346c4) but the
SHA256 ones are apparently used rarely enough (see 8741504888b) that
it's not worth the extra code.

Instead, disable them by default and update the warning.

Updates #13385
Updates #15487

Change-Id: I45b8b716001e2fa0811b17e25be76e2512e5abb2
Reviewed-on: https://go-review.googlesource.com/35290
Reviewed-by: Adam Langley <alangley@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Matt Layher <mdlayher@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: Id0044c45c23c12ee0bca362a9cdd25369ed7776c
Reviewed-on: https://go-review.googlesource.com/34533
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Some countermeasures were implemented in https://golang.org/cl/18130

Updates #13385

Change-Id: I723e1e3be0fa6d13767b65b145d90c89e92b2774
Reviewed-on: https://go-review.googlesource.com/33665
Reviewed-by: Adam Langley <agl@golang.org>

The SignedCertificateTimestampList[1] specifies that both the list and
each element must not be empty. Checking that the list is not empty was
handled in [2] and this change checks that the SCTs themselves are not
zero-length.

[1] https://tools.ietf.org/html/rfc6962#section-3.3
[2] https://golang.org/cl/33265

Change-Id: Iabaae7a15f6d111eb079e5086e0bd2005fae9e48
Reviewed-on: https://go-review.googlesource.com/33355
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

When the CT extension is enabled but no SCTs are present, the existing
code calls "continue" which causes resizing the data byte slice to be
skipped. In fact, such extensions should be rejected.

Fixes #17958

Change-Id: Iad12da10d1ea72d04ae2e1012c28bb2636f06bcd
Reviewed-on: https://go-review.googlesource.com/33265
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

For #13057.

Change-Id: Idbc50d5b08e055a23ab7cc9eb62dbc47b65b1815
Reviewed-on: https://go-review.googlesource.com/29050
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #17900.

Change-Id: I42cda6ac9cf48ed739d3a015a90b3cb15edf8ddf
Reviewed-on: https://go-review.googlesource.com/33243
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>