* Also alignes some tests which were broken because of this
  change

* Implements verifyPeerCertificate common for client and server
* Removes processCertsFromServer13 and processCertsFromClient13
  and implements getCertsFromEntries common to server and client
  which is used instead.

* TLS 1.3 requries specific marshalling/unmarshalling of data
* This code should probably be rewritten in order ot use
  a bit cleaner approach for dealing with bytes

Follows the wording in RFC4366 more precisely which allows a server
to optionally return a "certificate_status" when responding to a
client hello containing "status_request" extension.

fixes #8549

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

Change-Id: I3ff478912a5a178492d544d2f4ee9cc7570d9acc
Reviewed-on: https://go-review.googlesource.com/84475
Reviewed-by: Filippo Valsorda <hi@filippo.io>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Temporarily reverts update to go1.10

This is merge of commit 5158aab7d6
from https://github.com/golang/go.git for go/crypto/tls only.

iana.org, www.iana.org and data.iana.org all present a valid TLS
certificate, so let's use it when fetching data or linking to
resources to avoid errors in transit.

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

I don't expect these to hit often, but we should still alert users if
we fail to write the correct data to the file, or fail to close it.

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

Follows the wording in RFC4366 more precisely which allows a server
to optionally return a "certificate_status" when responding to a
client hello containing "status_request" extension.

fixes #8549

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

Change-Id: I3ff478912a5a178492d544d2f4ee9cc7570d9acc
Reviewed-on: https://go-review.googlesource.com/84475
Reviewed-by: Filippo Valsorda <hi@filippo.io>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Makefile improvement

Following things where added/changed:
* Builds correctly tls-tris. Previously go had a problem with
  a symbolic link resulting in not building tls-tris at all. I've
  used `rsync' instead.
* Can build for selected platform with "ARCH=platform make -f Makefile"
* Possible to build from any directory. Previously ``cd _dev; make``
  was required, it's possible to ``cd /whever/you/want; make -f /tris/Makefile``

Over time the amount of custom Go patches reduced, and tris got less
tangled to the underlying Go. Finally sever the link.

This allows more flexibility in what base Go is used (the system one),
doesn't require coordinating two repositories, and simplifies the black
magic considerably.

Make sure to use tris with Go 1.9.X.

Force boringssl client and server to use draft 22 instead of draft 18.
Other clients (tstclnt from NSS, picotls) support only draft 22.

Disable mint, it only supports draft 21.

Send/Skip CCS, set legacy record version to 3,3 and echo session ID.
CCS must be ignored while the handshake is running, but not thereafter:
https://tools.ietf.org/html/draft-ietf-tls-tls13-22#section-5

Unconditionally send CCS as server because bogo requires it, even if no
session ID is included in the Client Hello. TLS 1.3 clients MUST ignore
it anyway, so it should not hurt.

Fixes interop with boringssl and openssl and passes bogo.

Check SupportedVersions for the actual version and verify that the
server sets the correct SeverHello.legacy_version. Change D21 to D22.

Draft 21 changed end_of_early_data from an alert into a handshake
message to allow it to integrate better with the handshake. This change
does that, rather than handling EOD at the record layer, it moves
processing up to the actual readers of (early) application data.

D19: use early_data instead of custom ticket_early_data_info extension
codepoint. D21: new ticket nonce field and change in PSK calculation.
This nonce provides some minor security advantage in case one of the PSK
is compromised (which would leak the resumption master secret).

Rename "resumptionSecret" to "pskSecret" in sessionState13 to reflect
the D21 change and use constant-time comparison for the secret.

Also fix potential panic if the ticket is large enough, but the
extensions are missing.

D19 added an additional pre-extract Derive-Secret stage. D20 shortened
labels. Bump from D18 to D21 with no backwards compat option for now
since older drafts are considered undeployable.

Similar to boringssl, reuse the NSS client image for the NSS server test
against the tris client. Bump the NSS version to 3.34.1 gain support
for TLS 1.3 keylogging which is useful while debugging.

Adjust read check to fix intermittent NSS test failures:
https://github.com/cloudflare/tls-tris/issues/58

Prepare framework for testing tls-tris as client against other servers.
Currently only boringssl is implemented, but the idea is to add support
for others too (NSS, OpenSSL, picotls, tris, ...).

To test multiple certificate types, copy ecdsa.pem and rsa.pem from
tris-localserver for boringssl. The boringssl image is reused for the
server since the binaries were built anyway. Revision is bumped to
something to fix a build error and make the -loop and -www options work.

Support validation of ECDSA and RSASSA-PSS signatures. Explicitly do not
support PKCS1-v1_5 signatures since these are not allowed for handshake
messages.

Until PSS support is finalized for TLS 1.2, let's not advertise support
for that. Since TLS 1.3 however mandates PSS, we have no other option
than advertising this even if we have not added complete support.

Another reason why I apply it to just TLS 1.3 and not 1.2 is because the
latter would require updating the testdata.

Moved some code and added a comment in preparation for extending the TLS
1.3 client with certificate validation. No functional change.

Advertise TLS 1.3 in supported_versions and send a key share for the
first preferred curve. Missing are HRR, certificate validation and
Encrypted Extensions processing (see TODO notes).

For simplicity only a single key share is remembered. This key share
should be updated with a HRR (when implemented).

This change splits handshake processing for TLS 1.3, reindenting the TLS
1.2 code path and splitting initializationg of the handshake hash. No
equivalent is added for processServerHello because session resumption is
not supported yet.

Skip reading the session cache if TLS 1.3 is in use (the cache has no
use), skip storing a session if TLS 1.3 is in use (sessionCache can
still be set when TLS 1.2 is allowed).

This adds support for RSASSA-PSS signatures in handshake messages as
required by TLS 1.3. Even if TLS 1.2 is negotiated, it must support PSS
when advertised in the Client Hello (this will be done later as the
testdata will change).

Updates #9671

Change-Id: I8006b92e017453ae408c153233ce5ccef99b5c3f

ServerKeyExchange and CertificateVerify can share the same logic for
picking a signature algorithm (based on the certificate public key and
advertised algorithms), selecting a hash algorithm (depending on TLS
version) and signature verification.

Refactor the code to achieve code reuse, have common error checking
(especially for intersecting supported signature algorithms) and to
prepare for addition of new signature algorithms. Code should be easier
to read since version-dependent logic is concentrated at one place.

Change-Id: I978dec3815d28e33c3cfbc85f0c704b1894c25a3

All TLS 1.3 cipher suites so far use a nonce length of 12, but that does
not have to be the case. Correct the cipher suite definition and use it.
Spec: https://tools.ietf.org/html/draft-ietf-tls-tls13-22#section-5.3

Note: there is no functional change, the values were previously unused.

Fixes: ("[dev.tls] crypto/tls: implement TLS 1.3 cipher suites")