I was confused about how to start an HTTP server if the server
cert/key are in memory, not on disk. I thought it would be good to
show an example of how to use these two functions to accomplish that.
example-cert.pem and example-key.pem were generated using
crypto/tls/generate_cert.go.
parsePrivateKey can't return useful error messages because it does trial
decoding of multiple formats. Try ParseCertificate first in case it
offers a useful error message.
Fixes#23591
Change-Id: I380490a5850bee593a7d2f584a27b2a14153d768
Reviewed-on: https://go-review.googlesource.com/90435
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@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>
Minimal amount of changes needed to switch to GO 1.11
* crypto/internal/cipherhw was removed and internal/cpu was introduced
* wrong code formatting in handhsake_server_test.go was breaking
the build
Implements two tests for SIDH/P503-X25519 interoperability. BoringSSL
initiates connection to TRIS and TRIS initiates connection to BoringSSL.
SIDH server always listens on port 7443
generateKeyShare has nothing to do with Config receiver. It doesn't
configure anything. It has everything with connection so moved to Conn.
Making deriveECDHESecret also a method of Conn will make it possible to
access 'isClient' field.
serverHandshakeState::readClientHello was setting selected ALPN protocol
always on hs.hello.alpnProtocol, which is specific to TLS 1.2 and older.
Because of that server was marshalling ALPN to SH instead of EE.
Before AEAD encryption data are stored in a buffer. Last possition
of this buffer store data type. When subsequent TLS record is shorter
than previous, the buffer is shrinked. This causes to remove data
type, which results in wrong MAC calculation. Only in case of TLS 1.3.
* Drop DC test data for draft23
* DC: Change public key type
There was a last minute change to spec that changes the public key type
from a byte string of length at most 2^16 to a byte string of length at
most 2^24.
* includes AD in authentication check of TLS records
As per 5.2 of TLS 1.3 draft-28, the additional data is record header.
* tests: Update tests in order to support draft-28
* Interoperability: Updates NSS and BoringSSL versions to the
one supporting draft-28
* Bogo: Updates revision number to use tests for draft-28
* FIX: makefile was using test-compat target instead of
test-interop
* DC test: constify
* Use binary interface to encode in big-endian
The test in subcerts_test.go only passes if maxVersion ==
VersionTLS13Draft23. This is because DCs are cryptographically bound to
the protocol version on the wire. To work around this as we move towards
the RFC, this PR adds test data for VersionTLS13Draft28 and VersionTLS13
and uses maxVersion to pick which data to load. # Please enter the
commit message for your changes. Lines starting
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
