To allow clients to advertise both TLS 1.2 and TLS 1.3 cipher suites,
remove the distinction between both suites. TLS 1.3 suites are now
always included in the default cipher list (and the client will send it
if MaxVersion allows for it).
Since TLS 1.3 is expected to become the default MaxVersion and
applications might have set only TLS 1.2 cipher suites in their
configuration, TLS 1.3 cipher suites are added when none are present.
Alternatively, I considered disallowing overriding the TLS 1.3 suites,
but that requires more complexity and has not much benefits. Provide a
mechanism and do not dictate policy, application developers might want
to fix a cipher suite for testing other implementations for example.
Fixes https://github.com/cloudflare/tls-tris/pull/22
bytes.IndexByte can be used wherever the second argument to
strings.Index is exactly one byte long, so we do that with this change.
This avoids generating unnecessary string symbols/converison and saves
a few calls to bytes.Index.
Change-Id: If31c775790e01edfece1169e398ad6a754fb4428
Reviewed-on: https://go-review.googlesource.com/66373
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
strings.LastIndexByte was introduced in go1.5 and it can be used
effectively wherever the second argument to strings.LastIndex is
exactly one byte long.
This avoids generating unnecessary string symbols and saves
a few calls to strings.LastIndex.
Change-Id: I7b5679d616197b055cffe6882a8675d24a98b574
Reviewed-on: https://go-review.googlesource.com/66372
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Use the new keySchedule13 type instead of hash.Hash to avoid tracking
the hashContext and intermediate secrets manually.
checkPSK is modified not to return the calculated early secret, this is
internal to keySchedule13 now. The caller just learns whether it was
resumed using a PSK or not.
In order to reduce repetitive complexity (extract handshake context,
pass the right secrets around to calculate a secret and build a cipher),
create a new type that tracks the hash type, the handshake context and
intermediate secrets.
Advantages: facilitates reuse between client and server code, makes it
easier to update labels for draft-19, makes it easier to add central
KeyLogWriter functionality.
It was causing mysterious fuzzing failure because it affects the
unmarshaling of the secureNegotiationSupported field.
Change-Id: Id396b84eab90a3b22fb6e306b10bdd7e39707012
Reviewed-on: https://go-review.googlesource.com/60912
Run-TryBot: Filippo Valsorda <hi@filippo.io>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
TestGetClientCertificate had disabled verification, and was only passing
because it was mistakenly checking for empty verifiedChains.
Change-Id: Iea0ddbdbbdf8ac34b499569820a2e4ce543a69c7
Reviewed-on: https://go-review.googlesource.com/47430
Run-TryBot: Filippo Valsorda <hi@filippo.io>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
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
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
