It's sufficient to pass in the *tls.Certificate (resp.
*x509.Certificate) to the server functions (resp. client funcctions),
but not necessary; the existing keyAgreement implementations only makes
use of the private key (resp. public key). Moreover, this change is
necessary for implementing the delegated credentials extension, which
replaces the private key (resp. public key) used in the handshake.
* Changes tests so that they pass with draft-23
* BoringSSL interoperability: uses code at most recent commit. It uses
"-tls13-variant draft23" flag to indicate compatibility with draft23
* NSS interoperability: Uses release 3.35
* PicoTLS interoperability: blocked. Doesn't seem to implement draft23
* Uses updated bogo from
https://github.com/henrydcase/crypto-tls-bogo-shim
Goal of this PR is to rework testing script so that actual testing is
easy to extend and perform during development cycle.
* For interoperability testing I use python script and test framework,
instead of complicated bsah scripts. Script itself is not yet perfect
but it makes it much easier to extend tests and work with them during
development time
* Makefile has been extended and now includes all steps needed to build
the library and run tests. It's now possible to run any kind of tests
without exporting environment variables. Thanks to this change it is
stupid-easy to run any kind of tests.
* There are 3 kinds of tests implemented in the library - unittests,
interoperability tests and bogo. Travis has been changed and now
dashbord will show only results for those 3 targets.
* 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>
