In particular move it to after cipher suite negotiation and after
HelloRetryRequest check.

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

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>