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>

This makes it easier to validate the handshake contents using Wireshark.

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.

Fixes: "tris: add picotls interop"

a -> an

Change-Id: I7362bdc199e83073a712be657f5d9ba16df3077e
Reviewed-on: https://go-review.googlesource.com/63850
Reviewed-by: Rob Pike <r@golang.org>

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>

Use Go 1.9 (go1.9) with a patch to enable users to access the 0RTT API:

    net/http: attach TLSConnContextKey to the request Context

HEAD is currently breaking the build.

#23 -- CLA ok -- re-author to me+google@tomthorogood.co.uk

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