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.
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.
The default version (TLS 1.2) is no longer overridden with TLS 1.3 so
the server must explicitly set it.
Fixes: ("crypto/tls: allow client to pick TLS 1.3, do not enable it by default.")
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