* 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>
This is merge of commit 5158aab7d662e274aed870ae6bf9cf8ae0786f5b
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>
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.
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.
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
