There should be no data in the Handshake buffer on encryption state
changes (including implicit 1.3 transitions). Checking that also blocks
all Handshake messages fragmented across CCS.

BoGo: PartialClientFinishedWithClientHello

BoGo: FragmentAcrossChangeCipherSpec-Server-Packed

BoGo: Resume-Server-PSKBinderFirstExtension
BoGo: Resume-Server-ExtraPSKBinder
BoGo: Resume-Server-ExtraIdentityNoBinder
BoGo: Renegotiate-Server-Forbidden
BoGo: NoNullCompression
BoGo: TrailingMessageData-*

BoGo: Resume-Server-ExtraPSKBinder

BoGo: PointFormat-Server-*

BoGo: IgnoreClientVersionOrder
BoGO: *VersionTolerance
BoGo: RejectFinalTLS13

BoGo: FallbackSCSV-VersionMatch-TLS13

It was causing mysterious fuzzing failure because it affects the
unmarshaling of the secureNegotiationSupported field.

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>