Support for Ed25519 certificates was added in CL 175478, this wires them
up into the TLS stack according to RFC 8422 (TLS 1.2) and RFC 8446 (TLS 1.3).
RFC 8422 also specifies support for TLS 1.0 and 1.1, and I initially
implemented that, but even OpenSSL doesn't take the complexity, so I
just dropped it. It would have required keeping a buffer of the
handshake transcript in order to do the direct Ed25519 signatures. We
effectively need to support TLS 1.2 because it shares ClientHello
signature algorithms with TLS 1.3.
While at it, reordered the advertised signature algorithms in the rough
order we would want to use them, also based on what curves have fast
constant-time implementations.
Client and client auth tests changed because of the change in advertised
signature algorithms in ClientHello and CertificateRequest.
Fixes#25355
Change-Id: I9fdd839afde4fd6b13fcbc5cc7017fd8c35085ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/177698
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>
Users (like myself) may be tempted to think the higher-numbered curve
is somehow better or more secure, but P256 is currently the best
ECDSA implementation, due to its better support in TLS clients, and a
constant time implementation.
For example, sites that present a certificate signed with P521
currently fail to load in Chrome stable, and the error on the Go side
says simply "remote error: tls: illegal parameter".
Fixes#19901.
Change-Id: Ia5e689e7027ec423624627420e33029c56f0bd82
Reviewed-on: https://go-review.googlesource.com/40211
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
