2009-11-05 15:44:32 -08:00
|
|
|
// Copyright 2009 The Go Authors. All rights reserved.
|
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
|
|
|
|
package tls
|
|
|
|
|
|
|
|
|
|
import (
|
2010-12-15 11:49:55 -05:00
|
|
|
"bytes"
|
2020-08-01 12:18:31 +01:00
|
|
|
"context"
|
2017-06-02 12:33:50 -07:00
|
|
|
"crypto"
|
crypto/ecdh: new package
We use crypto/internal/edwards25519/field to implement X25519 directly,
so that golang.org/x/crypto/curve25519 can be dropped from the src
module dependencies, and eventually replaced with a crypto/ecdh wrapper,
removing the need to keep golang.org/x/crypto/curve25519/internal/field
in sync with crypto/internal/edwards25519/field.
In crypto/internal/nistec, we add BytesX to serialize only the x
coordinate, which we'll need for the horrible ECDSA x-coord-to-scalar
operation, too.
In crypto/tls, we replace the ECDHE implementation with crypto/ecdh,
dropping the X25519 special cases and related scaffolding.
Finally, FINALLY, we deprecate the ~white whale~ big.Int-based APIs of
the crypto/elliptic package. •_•) ( •_•)>⌐■-■ (⌐■_■)
Fixes #52182
Fixes #34648
Fixes #52221
Change-Id: Iccdda210319cc892e96bb28a0e7b7123551982c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/398914
Reviewed-by: Fernando Lobato Meeser <felobato@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-04-07 15:15:31 -04:00
|
|
|
"crypto/ecdh"
|
2013-07-17 12:33:16 -04:00
|
|
|
"crypto/elliptic"
|
crypto/ecdh: new package
We use crypto/internal/edwards25519/field to implement X25519 directly,
so that golang.org/x/crypto/curve25519 can be dropped from the src
module dependencies, and eventually replaced with a crypto/ecdh wrapper,
removing the need to keep golang.org/x/crypto/curve25519/internal/field
in sync with crypto/internal/edwards25519/field.
In crypto/internal/nistec, we add BytesX to serialize only the x
coordinate, which we'll need for the horrible ECDSA x-coord-to-scalar
operation, too.
In crypto/tls, we replace the ECDHE implementation with crypto/ecdh,
dropping the X25519 special cases and related scaffolding.
Finally, FINALLY, we deprecate the ~white whale~ big.Int-based APIs of
the crypto/elliptic package. •_•) ( •_•)>⌐■-■ (⌐■_■)
Fixes #52182
Fixes #34648
Fixes #52221
Change-Id: Iccdda210319cc892e96bb28a0e7b7123551982c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/398914
Reviewed-by: Fernando Lobato Meeser <felobato@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-04-07 15:15:31 -04:00
|
|
|
"crypto/rand"
|
crypto/tls: select only compatible chains from Certificates
Now that we have a full implementation of the logic to check certificate
compatibility, we can let applications just list multiple chains in
Certificates (for example, an RSA and an ECDSA one) and choose the most
appropriate automatically.
NameToCertificate only maps each name to one chain, so simply deprecate
it, and while at it simplify its implementation by not stripping
trailing dots from the SNI (which is specified not to have any, see RFC
6066, Section 3) and by not supporting multi-level wildcards, which are
not a thing in the WebPKI (and in crypto/x509).
The performance of SupportsCertificate without Leaf is poor, but doesn't
affect current users. For now document that, and address it properly in
the next cycle. See #35504.
While cleaning up the Certificates/GetCertificate/GetConfigForClient
behavior, also support leaving Certificates/GetCertificate nil if
GetConfigForClient is set, and send unrecognized_name when there are no
available certificates.
Fixes #29139
Fixes #18377
Change-Id: I26604db48806fe4d608388e55da52f34b7ca4566
Reviewed-on: https://go-review.googlesource.com/c/go/+/205059
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
2019-11-02 14:43:34 -04:00
|
|
|
"crypto/x509"
|
2012-01-05 12:05:38 -05:00
|
|
|
"encoding/pem"
|
2013-12-20 11:37:05 -05:00
|
|
|
"errors"
|
2012-04-11 12:55:57 -04:00
|
|
|
"fmt"
|
2010-04-26 22:19:04 -07:00
|
|
|
"io"
|
|
|
|
|
"net"
|
2012-04-11 12:55:57 -04:00
|
|
|
"os"
|
2013-12-20 11:37:05 -05:00
|
|
|
"os/exec"
|
|
|
|
|
"path/filepath"
|
2020-08-01 12:18:31 +01:00
|
|
|
"runtime"
|
2024-06-23 14:10:14 +02:00
|
|
|
"slices"
|
2014-02-12 11:20:01 -05:00
|
|
|
"strings"
|
2009-12-15 15:33:31 -08:00
|
|
|
"testing"
|
2011-11-30 12:01:46 -05:00
|
|
|
"time"
|
2009-11-05 15:44:32 -08:00
|
|
|
)
|
|
|
|
|
|
2015-04-02 16:19:46 -07:00
|
|
|
func testClientHello(t *testing.T, serverConfig *Config, m handshakeMessage) {
|
|
|
|
|
testClientHelloFailure(t, serverConfig, m, "")
|
|
|
|
|
}
|
|
|
|
|
|
crypto/tls: replace all usages of BytesOrPanic
Message marshalling makes use of BytesOrPanic a lot, under the
assumption that it will never panic. This assumption was incorrect, and
specifically crafted handshakes could trigger panics. Rather than just
surgically replacing the usages of BytesOrPanic in paths that could
panic, replace all usages of it with proper error returns in case there
are other ways of triggering panics which we didn't find.
In one specific case, the tree routed by expandLabel, we replace the
usage of BytesOrPanic, but retain a panic. This function already
explicitly panicked elsewhere, and returning an error from it becomes
rather painful because it requires changing a large number of APIs.
The marshalling is unlikely to ever panic, as the inputs are all either
fixed length, or already limited to the sizes required. If it were to
panic, it'd likely only be during development. A close inspection shows
no paths for a user to cause a panic currently.
This patches ends up being rather large, since it requires routing
errors back through functions which previously had no error returns.
Where possible I've tried to use helpers that reduce the verbosity
of frequently repeated stanzas, and to make the diffs as minimal as
possible.
Thanks to Marten Seemann for reporting this issue.
Fixes #58001
Fixes CVE-2022-41724
Change-Id: Ieb55867ef0a3e1e867b33f09421932510cb58851
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1679436
Reviewed-by: Julie Qiu <julieqiu@google.com>
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/468125
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
2022-12-14 09:43:16 -08:00
|
|
|
// testFatal is a hack to prevent the compiler from complaining that there is a
|
|
|
|
|
// call to t.Fatal from a non-test goroutine
|
|
|
|
|
func testFatal(t *testing.T, err error) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
t.Fatal(err)
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-16 17:13:10 -07:00
|
|
|
func testClientHelloFailure(t *testing.T, serverConfig *Config, m handshakeMessage, expectedSubStr string) {
|
2018-10-16 23:47:55 -04:00
|
|
|
c, s := localPipe(t)
|
2010-04-26 22:19:04 -07:00
|
|
|
go func() {
|
|
|
|
|
cli := Client(c, testConfig)
|
|
|
|
|
if ch, ok := m.(*clientHelloMsg); ok {
|
|
|
|
|
cli.vers = ch.vers
|
|
|
|
|
}
|
crypto/tls: replace all usages of BytesOrPanic
Message marshalling makes use of BytesOrPanic a lot, under the
assumption that it will never panic. This assumption was incorrect, and
specifically crafted handshakes could trigger panics. Rather than just
surgically replacing the usages of BytesOrPanic in paths that could
panic, replace all usages of it with proper error returns in case there
are other ways of triggering panics which we didn't find.
In one specific case, the tree routed by expandLabel, we replace the
usage of BytesOrPanic, but retain a panic. This function already
explicitly panicked elsewhere, and returning an error from it becomes
rather painful because it requires changing a large number of APIs.
The marshalling is unlikely to ever panic, as the inputs are all either
fixed length, or already limited to the sizes required. If it were to
panic, it'd likely only be during development. A close inspection shows
no paths for a user to cause a panic currently.
This patches ends up being rather large, since it requires routing
errors back through functions which previously had no error returns.
Where possible I've tried to use helpers that reduce the verbosity
of frequently repeated stanzas, and to make the diffs as minimal as
possible.
Thanks to Marten Seemann for reporting this issue.
Fixes #58001
Fixes CVE-2022-41724
Change-Id: Ieb55867ef0a3e1e867b33f09421932510cb58851
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1679436
Reviewed-by: Julie Qiu <julieqiu@google.com>
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/468125
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
2022-12-14 09:43:16 -08:00
|
|
|
if _, err := cli.writeHandshakeRecord(m, nil); err != nil {
|
|
|
|
|
testFatal(t, err)
|
|
|
|
|
}
|
2010-04-26 22:19:04 -07:00
|
|
|
c.Close()
|
|
|
|
|
}()
|
2020-08-01 12:18:31 +01:00
|
|
|
ctx := context.Background()
|
2018-11-02 00:57:30 -04:00
|
|
|
conn := Server(s, serverConfig)
|
2020-08-01 12:18:31 +01:00
|
|
|
ch, err := conn.readClientHello(ctx)
|
2024-05-18 19:35:39 +02:00
|
|
|
if conn.vers == VersionTLS13 {
|
|
|
|
|
hs := serverHandshakeStateTLS13{
|
|
|
|
|
c: conn,
|
|
|
|
|
ctx: ctx,
|
|
|
|
|
clientHello: ch,
|
|
|
|
|
}
|
|
|
|
|
if err == nil {
|
|
|
|
|
err = hs.processClientHello()
|
|
|
|
|
}
|
|
|
|
|
if err == nil {
|
|
|
|
|
err = hs.checkForResumption()
|
|
|
|
|
}
|
|
|
|
|
if err == nil {
|
|
|
|
|
err = hs.pickCertificate()
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
hs := serverHandshakeState{
|
|
|
|
|
c: conn,
|
|
|
|
|
ctx: ctx,
|
|
|
|
|
clientHello: ch,
|
|
|
|
|
}
|
|
|
|
|
if err == nil {
|
|
|
|
|
err = hs.processClientHello()
|
|
|
|
|
}
|
|
|
|
|
if err == nil {
|
|
|
|
|
err = hs.pickCipherSuite()
|
|
|
|
|
}
|
2016-02-26 14:17:29 -05:00
|
|
|
}
|
2010-04-26 22:19:04 -07:00
|
|
|
s.Close()
|
2024-05-18 20:15:38 +02:00
|
|
|
t.Helper()
|
2015-04-02 16:19:46 -07:00
|
|
|
if len(expectedSubStr) == 0 {
|
|
|
|
|
if err != nil && err != io.EOF {
|
2015-08-11 15:29:40 +10:00
|
|
|
t.Errorf("Got error: %s; expected to succeed", err)
|
2015-04-02 16:19:46 -07:00
|
|
|
}
|
|
|
|
|
} else if err == nil || !strings.Contains(err.Error(), expectedSubStr) {
|
2018-11-02 00:57:30 -04:00
|
|
|
t.Errorf("Got error: %v; expected to match substring '%s'", err, expectedSubStr)
|
2009-11-05 15:44:32 -08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestSimpleError(t *testing.T) {
|
2015-03-16 17:13:10 -07:00
|
|
|
testClientHelloFailure(t, testConfig, &serverHelloDoneMsg{}, "unexpected handshake message")
|
2009-11-05 15:44:32 -08:00
|
|
|
}
|
|
|
|
|
|
2019-08-27 17:27:45 -04:00
|
|
|
var badProtocolVersions = []uint16{0x0000, 0x0005, 0x0100, 0x0105, 0x0200, 0x0205, VersionSSL30}
|
2009-11-05 15:44:32 -08:00
|
|
|
|
|
|
|
|
func TestRejectBadProtocolVersion(t *testing.T) {
|
2019-08-27 17:27:45 -04:00
|
|
|
config := testConfig.Clone()
|
|
|
|
|
config.MinVersion = VersionSSL30
|
2010-04-26 22:19:04 -07:00
|
|
|
for _, v := range badProtocolVersions {
|
2019-08-27 17:27:45 -04:00
|
|
|
testClientHelloFailure(t, config, &clientHelloMsg{
|
2018-10-24 21:22:00 -04:00
|
|
|
vers: v,
|
|
|
|
|
random: make([]byte, 32),
|
2018-10-31 09:34:10 -04:00
|
|
|
}, "unsupported versions")
|
2009-11-05 15:44:32 -08:00
|
|
|
}
|
2019-08-26 16:18:24 -04:00
|
|
|
testClientHelloFailure(t, config, &clientHelloMsg{
|
|
|
|
|
vers: VersionTLS12,
|
2019-08-27 17:27:45 -04:00
|
|
|
supportedVersions: badProtocolVersions,
|
2019-08-26 16:18:24 -04:00
|
|
|
random: make([]byte, 32),
|
|
|
|
|
}, "unsupported versions")
|
|
|
|
|
}
|
|
|
|
|
|
2009-11-05 15:44:32 -08:00
|
|
|
func TestNoSuiteOverlap(t *testing.T) {
|
2012-09-24 16:52:43 -04:00
|
|
|
clientHello := &clientHelloMsg{
|
2016-02-26 18:26:04 -05:00
|
|
|
vers: VersionTLS10,
|
2018-10-24 21:22:00 -04:00
|
|
|
random: make([]byte, 32),
|
2012-09-24 16:52:43 -04:00
|
|
|
cipherSuites: []uint16{0xff00},
|
2016-02-26 18:26:04 -05:00
|
|
|
compressionMethods: []uint8{compressionNone},
|
2012-09-24 16:52:43 -04:00
|
|
|
}
|
2015-03-16 17:13:10 -07:00
|
|
|
testClientHelloFailure(t, testConfig, clientHello, "no cipher suite supported by both client and server")
|
2009-11-05 15:44:32 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestNoCompressionOverlap(t *testing.T) {
|
2012-09-24 16:52:43 -04:00
|
|
|
clientHello := &clientHelloMsg{
|
2016-02-26 18:26:04 -05:00
|
|
|
vers: VersionTLS10,
|
2018-10-24 21:22:00 -04:00
|
|
|
random: make([]byte, 32),
|
2012-09-24 16:52:43 -04:00
|
|
|
cipherSuites: []uint16{TLS_RSA_WITH_RC4_128_SHA},
|
|
|
|
|
compressionMethods: []uint8{0xff},
|
|
|
|
|
}
|
2015-03-16 17:13:10 -07:00
|
|
|
testClientHelloFailure(t, testConfig, clientHello, "client does not support uncompressed connections")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestNoRC4ByDefault(t *testing.T) {
|
|
|
|
|
clientHello := &clientHelloMsg{
|
2016-02-26 18:26:04 -05:00
|
|
|
vers: VersionTLS10,
|
2018-10-24 21:22:00 -04:00
|
|
|
random: make([]byte, 32),
|
2015-03-16 17:13:10 -07:00
|
|
|
cipherSuites: []uint16{TLS_RSA_WITH_RC4_128_SHA},
|
2016-02-26 18:26:04 -05:00
|
|
|
compressionMethods: []uint8{compressionNone},
|
2015-03-16 17:13:10 -07:00
|
|
|
}
|
2016-08-30 03:19:01 +00:00
|
|
|
serverConfig := testConfig.Clone()
|
2015-03-16 17:13:10 -07:00
|
|
|
// Reset the enabled cipher suites to nil in order to test the
|
|
|
|
|
// defaults.
|
|
|
|
|
serverConfig.CipherSuites = nil
|
2016-06-21 07:00:41 -07:00
|
|
|
testClientHelloFailure(t, serverConfig, clientHello, "no cipher suite supported by both client and server")
|
2009-11-05 15:44:32 -08:00
|
|
|
}
|
|
|
|
|
|
2016-12-05 10:24:30 -08:00
|
|
|
func TestRejectSNIWithTrailingDot(t *testing.T) {
|
2018-10-24 21:22:00 -04:00
|
|
|
testClientHelloFailure(t, testConfig, &clientHelloMsg{
|
|
|
|
|
vers: VersionTLS12,
|
|
|
|
|
random: make([]byte, 32),
|
|
|
|
|
serverName: "foo.com.",
|
|
|
|
|
}, "unexpected message")
|
2016-12-05 10:24:30 -08:00
|
|
|
}
|
|
|
|
|
|
2015-04-02 16:19:46 -07:00
|
|
|
func TestDontSelectECDSAWithRSAKey(t *testing.T) {
|
|
|
|
|
// Test that, even when both sides support an ECDSA cipher suite, it
|
|
|
|
|
// won't be selected if the server's private key doesn't support it.
|
|
|
|
|
clientHello := &clientHelloMsg{
|
2016-02-26 18:26:04 -05:00
|
|
|
vers: VersionTLS10,
|
2018-10-24 21:22:00 -04:00
|
|
|
random: make([]byte, 32),
|
2015-04-02 16:19:46 -07:00
|
|
|
cipherSuites: []uint16{TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA},
|
2016-02-26 18:26:04 -05:00
|
|
|
compressionMethods: []uint8{compressionNone},
|
2015-04-02 16:19:46 -07:00
|
|
|
supportedCurves: []CurveID{CurveP256},
|
|
|
|
|
supportedPoints: []uint8{pointFormatUncompressed},
|
|
|
|
|
}
|
2016-08-30 03:19:01 +00:00
|
|
|
serverConfig := testConfig.Clone()
|
2015-04-02 16:19:46 -07:00
|
|
|
serverConfig.CipherSuites = clientHello.cipherSuites
|
|
|
|
|
serverConfig.Certificates = make([]Certificate, 1)
|
|
|
|
|
serverConfig.Certificates[0].Certificate = [][]byte{testECDSACertificate}
|
|
|
|
|
serverConfig.Certificates[0].PrivateKey = testECDSAPrivateKey
|
|
|
|
|
serverConfig.BuildNameToCertificate()
|
|
|
|
|
// First test that it *does* work when the server's key is ECDSA.
|
2016-06-21 07:00:41 -07:00
|
|
|
testClientHello(t, serverConfig, clientHello)
|
2015-04-02 16:19:46 -07:00
|
|
|
|
|
|
|
|
// Now test that switching to an RSA key causes the expected error (and
|
|
|
|
|
// not an internal error about a signing failure).
|
|
|
|
|
serverConfig.Certificates = testConfig.Certificates
|
2016-06-21 07:00:41 -07:00
|
|
|
testClientHelloFailure(t, serverConfig, clientHello, "no cipher suite supported by both client and server")
|
2015-04-02 16:19:46 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestDontSelectRSAWithECDSAKey(t *testing.T) {
|
|
|
|
|
// Test that, even when both sides support an RSA cipher suite, it
|
|
|
|
|
// won't be selected if the server's private key doesn't support it.
|
|
|
|
|
clientHello := &clientHelloMsg{
|
2016-02-26 18:26:04 -05:00
|
|
|
vers: VersionTLS10,
|
2018-10-24 21:22:00 -04:00
|
|
|
random: make([]byte, 32),
|
2015-04-02 16:19:46 -07:00
|
|
|
cipherSuites: []uint16{TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA},
|
2016-02-26 18:26:04 -05:00
|
|
|
compressionMethods: []uint8{compressionNone},
|
2015-04-02 16:19:46 -07:00
|
|
|
supportedCurves: []CurveID{CurveP256},
|
|
|
|
|
supportedPoints: []uint8{pointFormatUncompressed},
|
|
|
|
|
}
|
2016-08-30 03:19:01 +00:00
|
|
|
serverConfig := testConfig.Clone()
|
2015-04-02 16:19:46 -07:00
|
|
|
serverConfig.CipherSuites = clientHello.cipherSuites
|
|
|
|
|
// First test that it *does* work when the server's key is RSA.
|
2016-06-21 07:00:41 -07:00
|
|
|
testClientHello(t, serverConfig, clientHello)
|
2015-04-02 16:19:46 -07:00
|
|
|
|
|
|
|
|
// Now test that switching to an ECDSA key causes the expected error
|
|
|
|
|
// (and not an internal error about a signing failure).
|
|
|
|
|
serverConfig.Certificates = make([]Certificate, 1)
|
|
|
|
|
serverConfig.Certificates[0].Certificate = [][]byte{testECDSACertificate}
|
|
|
|
|
serverConfig.Certificates[0].PrivateKey = testECDSAPrivateKey
|
|
|
|
|
serverConfig.BuildNameToCertificate()
|
2016-06-21 07:00:41 -07:00
|
|
|
testClientHelloFailure(t, serverConfig, clientHello, "no cipher suite supported by both client and server")
|
2015-04-02 16:19:46 -07:00
|
|
|
}
|
|
|
|
|
|
2014-12-19 15:14:03 -08:00
|
|
|
func TestRenegotiationExtension(t *testing.T) {
|
|
|
|
|
clientHello := &clientHelloMsg{
|
go/printer, gofmt: tuned table alignment for better results
The go/printer (and thus gofmt) uses a heuristic to determine
whether to break alignment between elements of an expression
list which is spread across multiple lines. The heuristic only
kicked in if the entry sizes (character length) was above a
certain threshold (20) and the ratio between the previous and
current entry size was above a certain value (4).
This heuristic worked reasonably most of the time, but also
led to unfortunate breaks in many cases where a single entry
was suddenly much smaller (or larger) then the previous one.
The behavior of gofmt was sufficiently mysterious in some of
these situations that many issues were filed against it.
The simplest solution to address this problem is to remove
the heuristic altogether and have a programmer introduce
empty lines to force different alignments if it improves
readability. The problem with that approach is that the
places where it really matters, very long tables with many
(hundreds, or more) entries, may be machine-generated and
not "post-processed" by a human (e.g., unicode/utf8/tables.go).
If a single one of those entries is overlong, the result
would be that the alignment would force all comments or
values in key:value pairs to be adjusted to that overlong
value, making the table hard to read (e.g., that entry may
not even be visible on screen and all other entries seem
spaced out too wide).
Instead, we opted for a slightly improved heuristic that
behaves much better for "normal", human-written code.
1) The threshold is increased from 20 to 40. This disables
the heuristic for many common cases yet even if the alignment
is not "ideal", 40 is not that many characters per line with
todays screens, making it very likely that the entire line
remains "visible" in an editor.
2) Changed the heuristic to not simply look at the size ratio
between current and previous line, but instead considering the
geometric mean of the sizes of the previous (aligned) lines.
This emphasizes the "overall picture" of the previous lines,
rather than a single one (which might be an outlier).
3) Changed the ratio from 4 to 2.5. Now that we ignore sizes
below 40, a ratio of 4 would mean that a new entry would have
to be 4 times bigger (160) or smaller (10) before alignment
would be broken. A ratio of 2.5 seems more sensible.
Applied updated gofmt to all of src and misc. Also tested
against several former issues that complained about this
and verified that the output for the given examples is
satisfactory (added respective test cases).
Some of the files changed because they were not gofmt-ed
in the first place.
For #644.
For #7335.
For #10392.
(and probably more related issues)
Fixes #22852.
Change-Id: I5e48b3d3b157a5cf2d649833b7297b33f43a6f6e
2018-04-03 17:05:47 -07:00
|
|
|
vers: VersionTLS12,
|
|
|
|
|
compressionMethods: []uint8{compressionNone},
|
|
|
|
|
random: make([]byte, 32),
|
2016-04-26 10:45:35 -07:00
|
|
|
secureRenegotiationSupported: true,
|
|
|
|
|
cipherSuites: []uint16{TLS_RSA_WITH_RC4_128_SHA},
|
2014-12-19 15:14:03 -08:00
|
|
|
}
|
|
|
|
|
|
2020-02-13 16:20:30 -05:00
|
|
|
bufChan := make(chan []byte, 1)
|
2018-10-16 23:47:55 -04:00
|
|
|
c, s := localPipe(t)
|
2014-12-19 15:14:03 -08:00
|
|
|
|
|
|
|
|
go func() {
|
|
|
|
|
cli := Client(c, testConfig)
|
|
|
|
|
cli.vers = clientHello.vers
|
crypto/tls: replace all usages of BytesOrPanic
Message marshalling makes use of BytesOrPanic a lot, under the
assumption that it will never panic. This assumption was incorrect, and
specifically crafted handshakes could trigger panics. Rather than just
surgically replacing the usages of BytesOrPanic in paths that could
panic, replace all usages of it with proper error returns in case there
are other ways of triggering panics which we didn't find.
In one specific case, the tree routed by expandLabel, we replace the
usage of BytesOrPanic, but retain a panic. This function already
explicitly panicked elsewhere, and returning an error from it becomes
rather painful because it requires changing a large number of APIs.
The marshalling is unlikely to ever panic, as the inputs are all either
fixed length, or already limited to the sizes required. If it were to
panic, it'd likely only be during development. A close inspection shows
no paths for a user to cause a panic currently.
This patches ends up being rather large, since it requires routing
errors back through functions which previously had no error returns.
Where possible I've tried to use helpers that reduce the verbosity
of frequently repeated stanzas, and to make the diffs as minimal as
possible.
Thanks to Marten Seemann for reporting this issue.
Fixes #58001
Fixes CVE-2022-41724
Change-Id: Ieb55867ef0a3e1e867b33f09421932510cb58851
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1679436
Reviewed-by: Julie Qiu <julieqiu@google.com>
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/468125
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
2022-12-14 09:43:16 -08:00
|
|
|
if _, err := cli.writeHandshakeRecord(clientHello, nil); err != nil {
|
|
|
|
|
testFatal(t, err)
|
|
|
|
|
}
|
2014-12-19 15:14:03 -08:00
|
|
|
|
2018-10-16 23:47:55 -04:00
|
|
|
buf := make([]byte, 1024)
|
2014-12-19 15:14:03 -08:00
|
|
|
n, err := c.Read(buf)
|
|
|
|
|
if err != nil {
|
2016-11-14 21:34:58 -08:00
|
|
|
t.Errorf("Server read returned error: %s", err)
|
|
|
|
|
return
|
2014-12-19 15:14:03 -08:00
|
|
|
}
|
|
|
|
|
c.Close()
|
2018-10-16 23:47:55 -04:00
|
|
|
bufChan <- buf[:n]
|
2014-12-19 15:14:03 -08:00
|
|
|
}()
|
|
|
|
|
|
|
|
|
|
Server(s, testConfig).Handshake()
|
2018-10-16 23:47:55 -04:00
|
|
|
buf := <-bufChan
|
2014-12-19 15:14:03 -08:00
|
|
|
|
|
|
|
|
if len(buf) < 5+4 {
|
|
|
|
|
t.Fatalf("Server returned short message of length %d", len(buf))
|
|
|
|
|
}
|
|
|
|
|
// buf contains a TLS record, with a 5 byte record header and a 4 byte
|
|
|
|
|
// handshake header. The length of the ServerHello is taken from the
|
|
|
|
|
// handshake header.
|
|
|
|
|
serverHelloLen := int(buf[6])<<16 | int(buf[7])<<8 | int(buf[8])
|
|
|
|
|
|
|
|
|
|
var serverHello serverHelloMsg
|
|
|
|
|
// unmarshal expects to be given the handshake header, but
|
|
|
|
|
// serverHelloLen doesn't include it.
|
|
|
|
|
if !serverHello.unmarshal(buf[5 : 9+serverHelloLen]) {
|
|
|
|
|
t.Fatalf("Failed to parse ServerHello")
|
|
|
|
|
}
|
|
|
|
|
|
2016-04-26 10:45:35 -07:00
|
|
|
if !serverHello.secureRenegotiationSupported {
|
2014-12-19 15:14:03 -08:00
|
|
|
t.Errorf("Secure renegotiation extension was not echoed.")
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-09-26 17:09:56 -04:00
|
|
|
func TestTLS12OnlyCipherSuites(t *testing.T) {
|
|
|
|
|
// Test that a Server doesn't select a TLS 1.2-only cipher suite when
|
|
|
|
|
// the client negotiates TLS 1.1.
|
|
|
|
|
clientHello := &clientHelloMsg{
|
|
|
|
|
vers: VersionTLS11,
|
2018-10-24 21:22:00 -04:00
|
|
|
random: make([]byte, 32),
|
2013-09-26 17:09:56 -04:00
|
|
|
cipherSuites: []uint16{
|
|
|
|
|
// The Server, by default, will use the client's
|
|
|
|
|
// preference order. So the GCM cipher suite
|
|
|
|
|
// will be selected unless it's excluded because
|
|
|
|
|
// of the version in this ClientHello.
|
|
|
|
|
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
|
|
|
|
|
TLS_RSA_WITH_RC4_128_SHA,
|
|
|
|
|
},
|
|
|
|
|
compressionMethods: []uint8{compressionNone},
|
2014-02-24 17:57:51 -05:00
|
|
|
supportedCurves: []CurveID{CurveP256, CurveP384, CurveP521},
|
2013-09-26 17:09:56 -04:00
|
|
|
supportedPoints: []uint8{pointFormatUncompressed},
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-16 23:47:55 -04:00
|
|
|
c, s := localPipe(t)
|
2021-12-01 12:15:45 -05:00
|
|
|
replyChan := make(chan any)
|
2013-09-26 17:09:56 -04:00
|
|
|
go func() {
|
|
|
|
|
cli := Client(c, testConfig)
|
|
|
|
|
cli.vers = clientHello.vers
|
crypto/tls: replace all usages of BytesOrPanic
Message marshalling makes use of BytesOrPanic a lot, under the
assumption that it will never panic. This assumption was incorrect, and
specifically crafted handshakes could trigger panics. Rather than just
surgically replacing the usages of BytesOrPanic in paths that could
panic, replace all usages of it with proper error returns in case there
are other ways of triggering panics which we didn't find.
In one specific case, the tree routed by expandLabel, we replace the
usage of BytesOrPanic, but retain a panic. This function already
explicitly panicked elsewhere, and returning an error from it becomes
rather painful because it requires changing a large number of APIs.
The marshalling is unlikely to ever panic, as the inputs are all either
fixed length, or already limited to the sizes required. If it were to
panic, it'd likely only be during development. A close inspection shows
no paths for a user to cause a panic currently.
This patches ends up being rather large, since it requires routing
errors back through functions which previously had no error returns.
Where possible I've tried to use helpers that reduce the verbosity
of frequently repeated stanzas, and to make the diffs as minimal as
possible.
Thanks to Marten Seemann for reporting this issue.
Fixes #58001
Fixes CVE-2022-41724
Change-Id: Ieb55867ef0a3e1e867b33f09421932510cb58851
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1679436
Reviewed-by: Julie Qiu <julieqiu@google.com>
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/468125
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
2022-12-14 09:43:16 -08:00
|
|
|
if _, err := cli.writeHandshakeRecord(clientHello, nil); err != nil {
|
|
|
|
|
testFatal(t, err)
|
|
|
|
|
}
|
|
|
|
|
reply, err := cli.readHandshake(nil)
|
2013-09-26 17:09:56 -04:00
|
|
|
c.Close()
|
2018-10-16 23:47:55 -04:00
|
|
|
if err != nil {
|
|
|
|
|
replyChan <- err
|
|
|
|
|
} else {
|
|
|
|
|
replyChan <- reply
|
|
|
|
|
}
|
2013-09-26 17:09:56 -04:00
|
|
|
}()
|
2016-08-30 03:19:01 +00:00
|
|
|
config := testConfig.Clone()
|
2013-09-26 17:09:56 -04:00
|
|
|
config.CipherSuites = clientHello.cipherSuites
|
2016-06-21 07:00:41 -07:00
|
|
|
Server(s, config).Handshake()
|
2013-09-26 17:09:56 -04:00
|
|
|
s.Close()
|
2018-10-16 23:47:55 -04:00
|
|
|
reply := <-replyChan
|
|
|
|
|
if err, ok := reply.(error); ok {
|
|
|
|
|
t.Fatal(err)
|
2013-09-26 17:09:56 -04:00
|
|
|
}
|
|
|
|
|
serverHello, ok := reply.(*serverHelloMsg)
|
|
|
|
|
if !ok {
|
|
|
|
|
t.Fatalf("didn't get ServerHello message in reply. Got %v\n", reply)
|
|
|
|
|
}
|
|
|
|
|
if s := serverHello.cipherSuite; s != TLS_RSA_WITH_RC4_128_SHA {
|
|
|
|
|
t.Fatalf("bad cipher suite from server: %x", s)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-05-09 17:31:34 -07:00
|
|
|
func TestTLSPointFormats(t *testing.T) {
|
2019-11-15 19:49:30 +00:00
|
|
|
// Test that a Server returns the ec_point_format extension when ECC is
|
2022-08-24 12:39:20 +02:00
|
|
|
// negotiated, and not on a RSA handshake or if ec_point_format is missing.
|
2019-05-09 17:31:34 -07:00
|
|
|
tests := []struct {
|
|
|
|
|
name string
|
|
|
|
|
cipherSuites []uint16
|
|
|
|
|
supportedCurves []CurveID
|
|
|
|
|
supportedPoints []uint8
|
|
|
|
|
wantSupportedPoints bool
|
|
|
|
|
}{
|
2022-08-24 12:39:20 +02:00
|
|
|
{"ECC", []uint16{TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA}, []CurveID{CurveP256}, []uint8{pointFormatUncompressed}, true},
|
|
|
|
|
{"ECC without ec_point_format", []uint16{TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA}, []CurveID{CurveP256}, nil, false},
|
|
|
|
|
{"ECC with extra values", []uint16{TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA}, []CurveID{CurveP256}, []uint8{13, 37, pointFormatUncompressed, 42}, true},
|
2019-05-09 17:31:34 -07:00
|
|
|
{"RSA", []uint16{TLS_RSA_WITH_AES_256_GCM_SHA384}, nil, nil, false},
|
2022-08-24 12:39:20 +02:00
|
|
|
{"RSA with ec_point_format", []uint16{TLS_RSA_WITH_AES_256_GCM_SHA384}, nil, []uint8{pointFormatUncompressed}, false},
|
2019-05-09 17:31:34 -07:00
|
|
|
}
|
|
|
|
|
for _, tt := range tests {
|
|
|
|
|
t.Run(tt.name, func(t *testing.T) {
|
|
|
|
|
clientHello := &clientHelloMsg{
|
|
|
|
|
vers: VersionTLS12,
|
|
|
|
|
random: make([]byte, 32),
|
|
|
|
|
cipherSuites: tt.cipherSuites,
|
|
|
|
|
compressionMethods: []uint8{compressionNone},
|
|
|
|
|
supportedCurves: tt.supportedCurves,
|
|
|
|
|
supportedPoints: tt.supportedPoints,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
c, s := localPipe(t)
|
2021-12-01 12:15:45 -05:00
|
|
|
replyChan := make(chan any)
|
2019-05-09 17:31:34 -07:00
|
|
|
go func() {
|
|
|
|
|
cli := Client(c, testConfig)
|
|
|
|
|
cli.vers = clientHello.vers
|
crypto/tls: replace all usages of BytesOrPanic
Message marshalling makes use of BytesOrPanic a lot, under the
assumption that it will never panic. This assumption was incorrect, and
specifically crafted handshakes could trigger panics. Rather than just
surgically replacing the usages of BytesOrPanic in paths that could
panic, replace all usages of it with proper error returns in case there
are other ways of triggering panics which we didn't find.
In one specific case, the tree routed by expandLabel, we replace the
usage of BytesOrPanic, but retain a panic. This function already
explicitly panicked elsewhere, and returning an error from it becomes
rather painful because it requires changing a large number of APIs.
The marshalling is unlikely to ever panic, as the inputs are all either
fixed length, or already limited to the sizes required. If it were to
panic, it'd likely only be during development. A close inspection shows
no paths for a user to cause a panic currently.
This patches ends up being rather large, since it requires routing
errors back through functions which previously had no error returns.
Where possible I've tried to use helpers that reduce the verbosity
of frequently repeated stanzas, and to make the diffs as minimal as
possible.
Thanks to Marten Seemann for reporting this issue.
Fixes #58001
Fixes CVE-2022-41724
Change-Id: Ieb55867ef0a3e1e867b33f09421932510cb58851
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1679436
Reviewed-by: Julie Qiu <julieqiu@google.com>
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/468125
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
2022-12-14 09:43:16 -08:00
|
|
|
if _, err := cli.writeHandshakeRecord(clientHello, nil); err != nil {
|
|
|
|
|
testFatal(t, err)
|
|
|
|
|
}
|
|
|
|
|
reply, err := cli.readHandshake(nil)
|
2019-05-09 17:31:34 -07:00
|
|
|
c.Close()
|
|
|
|
|
if err != nil {
|
|
|
|
|
replyChan <- err
|
|
|
|
|
} else {
|
|
|
|
|
replyChan <- reply
|
|
|
|
|
}
|
|
|
|
|
}()
|
|
|
|
|
config := testConfig.Clone()
|
|
|
|
|
config.CipherSuites = clientHello.cipherSuites
|
|
|
|
|
Server(s, config).Handshake()
|
|
|
|
|
s.Close()
|
|
|
|
|
reply := <-replyChan
|
|
|
|
|
if err, ok := reply.(error); ok {
|
|
|
|
|
t.Fatal(err)
|
|
|
|
|
}
|
|
|
|
|
serverHello, ok := reply.(*serverHelloMsg)
|
|
|
|
|
if !ok {
|
|
|
|
|
t.Fatalf("didn't get ServerHello message in reply. Got %v\n", reply)
|
|
|
|
|
}
|
|
|
|
|
if tt.wantSupportedPoints {
|
2022-08-24 12:39:20 +02:00
|
|
|
if !bytes.Equal(serverHello.supportedPoints, []uint8{pointFormatUncompressed}) {
|
|
|
|
|
t.Fatal("incorrect ec_point_format extension from server")
|
2019-05-09 17:31:34 -07:00
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
if len(serverHello.supportedPoints) != 0 {
|
2022-05-17 17:09:28 +00:00
|
|
|
t.Fatalf("unexpected ec_point_format extension from server: %v", serverHello.supportedPoints)
|
2019-05-09 17:31:34 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-11-05 15:44:32 -08:00
|
|
|
func TestAlertForwarding(t *testing.T) {
|
2018-10-16 23:47:55 -04:00
|
|
|
c, s := localPipe(t)
|
2010-04-26 22:19:04 -07:00
|
|
|
go func() {
|
|
|
|
|
Client(c, testConfig).sendAlert(alertUnknownCA)
|
|
|
|
|
c.Close()
|
|
|
|
|
}()
|
|
|
|
|
|
|
|
|
|
err := Server(s, testConfig).Handshake()
|
|
|
|
|
s.Close()
|
2020-04-10 10:06:29 -04:00
|
|
|
var opErr *net.OpError
|
|
|
|
|
if !errors.As(err, &opErr) || opErr.Err != error(alertUnknownCA) {
|
2013-07-02 19:58:56 -04:00
|
|
|
t.Errorf("Got error: %s; expected: %s", err, error(alertUnknownCA))
|
2009-11-05 15:44:32 -08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestClose(t *testing.T) {
|
2018-10-16 23:47:55 -04:00
|
|
|
c, s := localPipe(t)
|
2010-04-26 22:19:04 -07:00
|
|
|
go c.Close()
|
2009-11-05 15:44:32 -08:00
|
|
|
|
2010-04-26 22:19:04 -07:00
|
|
|
err := Server(s, testConfig).Handshake()
|
|
|
|
|
s.Close()
|
2011-11-01 22:04:37 -04:00
|
|
|
if err != io.EOF {
|
|
|
|
|
t.Errorf("Got error: %s; expected: %s", err, io.EOF)
|
2009-11-05 15:44:32 -08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2014-02-24 18:01:28 -05:00
|
|
|
func TestVersion(t *testing.T) {
|
|
|
|
|
serverConfig := &Config{
|
|
|
|
|
Certificates: testConfig.Certificates,
|
2023-11-10 10:12:48 -08:00
|
|
|
MaxVersion: VersionTLS13,
|
2014-02-24 18:01:28 -05:00
|
|
|
}
|
|
|
|
|
clientConfig := &Config{
|
|
|
|
|
InsecureSkipVerify: true,
|
2023-11-10 10:12:48 -08:00
|
|
|
MinVersion: VersionTLS12,
|
2014-02-24 18:01:28 -05:00
|
|
|
}
|
2018-10-16 23:47:55 -04:00
|
|
|
state, _, err := testHandshake(t, clientConfig, serverConfig)
|
2014-02-24 18:01:28 -05:00
|
|
|
if err != nil {
|
|
|
|
|
t.Fatalf("handshake failed: %s", err)
|
|
|
|
|
}
|
2023-11-10 10:12:48 -08:00
|
|
|
if state.Version != VersionTLS13 {
|
2021-10-31 23:13:18 -04:00
|
|
|
t.Fatalf("incorrect version %x, should be %x", state.Version, VersionTLS11)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
clientConfig.MinVersion = 0
|
2023-11-10 10:12:48 -08:00
|
|
|
serverConfig.MaxVersion = VersionTLS11
|
2021-10-31 23:13:18 -04:00
|
|
|
_, _, err = testHandshake(t, clientConfig, serverConfig)
|
|
|
|
|
if err == nil {
|
|
|
|
|
t.Fatalf("expected failure to connect with TLS 1.0/1.1")
|
|
|
|
|
}
|
2014-02-24 18:01:28 -05:00
|
|
|
}
|
|
|
|
|
|
2013-01-22 10:10:38 -05:00
|
|
|
func TestCipherSuitePreference(t *testing.T) {
|
|
|
|
|
serverConfig := &Config{
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
CipherSuites: []uint16{TLS_RSA_WITH_RC4_128_SHA, TLS_AES_128_GCM_SHA256,
|
|
|
|
|
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256},
|
2013-01-22 10:10:38 -05:00
|
|
|
Certificates: testConfig.Certificates,
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
MaxVersion: VersionTLS12,
|
|
|
|
|
GetConfigForClient: func(chi *ClientHelloInfo) (*Config, error) {
|
|
|
|
|
if chi.CipherSuites[0] != TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 {
|
|
|
|
|
t.Error("the advertised order should not depend on Config.CipherSuites")
|
|
|
|
|
}
|
|
|
|
|
if len(chi.CipherSuites) != 2+len(defaultCipherSuitesTLS13) {
|
|
|
|
|
t.Error("the advertised TLS 1.2 suites should be filtered by Config.CipherSuites")
|
|
|
|
|
}
|
|
|
|
|
return nil, nil
|
|
|
|
|
},
|
2013-01-22 10:10:38 -05:00
|
|
|
}
|
|
|
|
|
clientConfig := &Config{
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
CipherSuites: []uint16{TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256},
|
2013-01-22 10:10:38 -05:00
|
|
|
InsecureSkipVerify: true,
|
|
|
|
|
}
|
2018-10-16 23:47:55 -04:00
|
|
|
state, _, err := testHandshake(t, clientConfig, serverConfig)
|
2013-01-22 10:10:38 -05:00
|
|
|
if err != nil {
|
|
|
|
|
t.Fatalf("handshake failed: %s", err)
|
|
|
|
|
}
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
if state.CipherSuite != TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 {
|
|
|
|
|
t.Error("the preference order should not depend on Config.CipherSuites")
|
2013-01-22 10:10:38 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-04-16 14:59:22 -04:00
|
|
|
func TestSCTHandshake(t *testing.T) {
|
crypto/tls: enable TLS 1.3 and update tests
To disable TLS 1.3, simply remove VersionTLS13 from supportedVersions,
as tested by TestEscapeRoute, and amend documentation. To make it
opt-in, revert the change to (*Config).supportedVersions from this CL.
I did not have the heart to implement the early data skipping feature
when I realized that it did not offer a choice between two
abstraction-breaking options, but demanded them both (look for handshake
type in case of HelloRetryRequest, trial decryption otherwise). It's a
lot of complexity for an apparently small gain, but if anyone has strong
opinions about it let me know.
Note that in TLS 1.3 alerts are encrypted, so the close_notify peeking
to return (n > 0, io.EOF) from Read doesn't work. If we are lucky, those
servers that unexpectedly close connections after serving a single
request will have stopped (maybe thanks to H/2) before they got updated
to TLS 1.3.
Relatedly, session tickets are now provisioned on the client first Read
instead of at Handshake time, because they are, well, post-handshake
messages. If this proves to be a problem we might try to peek at them.
Doubled the tests that cover logic that's different in TLS 1.3.
The benchmarks for TLS 1.2 compared to be0f3c286b5 (before TLS 1.3 and
its refactors, after CL 142817 changed them to use real connections)
show little movement.
name old time/op new time/op delta
HandshakeServer/RSA-8 795µs ± 1% 798µs ± 1% ~ (p=0.057 n=10+18)
HandshakeServer/ECDHE-P256-RSA-8 903µs ± 0% 909µs ± 1% +0.68% (p=0.000 n=8+17)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 198µs ± 0% 204µs ± 1% +3.24% (p=0.000 n=9+18)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 202µs ± 3% 208µs ± 1% +2.98% (p=0.000 n=9+20)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.5ms ± 1% 15.9ms ± 2% +2.49% (p=0.000 n=10+20)
Throughput/MaxPacket/1MB-8 5.81ms ±23% 6.14ms ±44% ~ (p=0.605 n=8+18)
Throughput/MaxPacket/2MB-8 8.91ms ±22% 8.74ms ±33% ~ (p=0.498 n=9+19)
Throughput/MaxPacket/4MB-8 12.8ms ± 3% 14.0ms ±10% +9.74% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 25.1ms ± 7% 24.6ms ±16% ~ (p=0.129 n=9+19)
Throughput/MaxPacket/16MB-8 46.3ms ± 4% 45.9ms ±12% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 88.5ms ± 4% 86.0ms ± 4% -2.82% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 173ms ± 2% 167ms ± 7% -3.42% (p=0.001 n=10+19)
Throughput/DynamicPacket/1MB-8 5.88ms ± 4% 6.59ms ±64% ~ (p=0.232 n=9+18)
Throughput/DynamicPacket/2MB-8 9.08ms ±12% 8.73ms ±21% ~ (p=0.408 n=10+18)
Throughput/DynamicPacket/4MB-8 14.2ms ± 5% 14.0ms ±11% ~ (p=0.188 n=9+19)
Throughput/DynamicPacket/8MB-8 25.1ms ± 6% 24.0ms ± 7% -4.39% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 45.6ms ± 3% 43.3ms ± 1% -5.22% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 88.4ms ± 3% 84.8ms ± 2% -4.06% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 175ms ± 3% 167ms ± 2% -4.63% (p=0.000 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 694ms ± 0% -0.02% (p=0.000 n=9+9)
Latency/MaxPacket/500kbps-8 279ms ± 0% 279ms ± 0% -0.09% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 140ms ± 0% -0.15% (p=0.000 n=10+9)
Latency/MaxPacket/2000kbps-8 71.1ms ± 0% 71.0ms ± 0% -0.09% (p=0.001 n=8+9)
Latency/MaxPacket/5000kbps-8 30.5ms ± 6% 30.1ms ± 6% ~ (p=0.905 n=10+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 134ms ± 0% ~ (p=0.796 n=9+9)
Latency/DynamicPacket/500kbps-8 54.8ms ± 0% 54.7ms ± 0% -0.18% (p=0.000 n=8+10)
Latency/DynamicPacket/1000kbps-8 28.5ms ± 0% 29.1ms ± 8% ~ (p=0.173 n=8+10)
Latency/DynamicPacket/2000kbps-8 15.3ms ± 6% 15.9ms ±10% ~ (p=0.905 n=9+10)
Latency/DynamicPacket/5000kbps-8 9.14ms ±21% 9.65ms ±82% ~ (p=0.529 n=10+10)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 175MB/s ±13% 167MB/s ±64% ~ (p=0.646 n=7+20)
Throughput/MaxPacket/2MB-8 241MB/s ±25% 241MB/s ±40% ~ (p=0.660 n=9+20)
Throughput/MaxPacket/4MB-8 328MB/s ± 3% 300MB/s ± 9% -8.70% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 335MB/s ± 7% 340MB/s ±17% ~ (p=0.212 n=9+20)
Throughput/MaxPacket/16MB-8 363MB/s ± 4% 367MB/s ±11% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 379MB/s ± 4% 390MB/s ± 4% +2.93% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 388MB/s ± 2% 401MB/s ± 7% +3.25% (p=0.004 n=10+20)
Throughput/DynamicPacket/1MB-8 178MB/s ± 4% 157MB/s ±73% ~ (p=0.127 n=9+20)
Throughput/DynamicPacket/2MB-8 232MB/s ±11% 243MB/s ±18% ~ (p=0.415 n=10+18)
Throughput/DynamicPacket/4MB-8 296MB/s ± 5% 299MB/s ±15% ~ (p=0.295 n=9+20)
Throughput/DynamicPacket/8MB-8 334MB/s ± 6% 350MB/s ± 7% +4.58% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 368MB/s ± 3% 388MB/s ± 1% +5.48% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 380MB/s ± 3% 396MB/s ± 2% +4.20% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 384MB/s ± 3% 403MB/s ± 2% +4.83% (p=0.000 n=10+10)
Comparing TLS 1.2 and TLS 1.3 at tip shows a slight (~5-10%) slowdown of
handshakes, which might be worth looking at next cycle, but the latency
improvements are expected to overshadow that.
name old time/op new time/op delta
HandshakeServer/ECDHE-P256-RSA-8 909µs ± 1% 963µs ± 0% +5.87% (p=0.000 n=17+18)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 204µs ± 1% 225µs ± 2% +10.20% (p=0.000 n=18+20)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 208µs ± 1% 230µs ± 2% +10.35% (p=0.000 n=20+18)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.9ms ± 2% 15.9ms ± 1% ~ (p=0.444 n=20+19)
Throughput/MaxPacket/1MB-8 6.14ms ±44% 7.07ms ±46% ~ (p=0.057 n=18+19)
Throughput/MaxPacket/2MB-8 8.74ms ±33% 8.61ms ± 9% ~ (p=0.552 n=19+17)
Throughput/MaxPacket/4MB-8 14.0ms ±10% 14.1ms ±12% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 24.6ms ±16% 25.6ms ±14% ~ (p=0.107 n=19+20)
Throughput/MaxPacket/16MB-8 45.9ms ±12% 44.7ms ± 6% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 86.0ms ± 4% 87.9ms ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 167ms ± 7% 169ms ± 2% +1.26% (p=0.011 n=19+19)
Throughput/DynamicPacket/1MB-8 6.59ms ±64% 6.79ms ±43% ~ (p=0.480 n=18+19)
Throughput/DynamicPacket/2MB-8 8.73ms ±21% 9.58ms ±13% +9.71% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 14.0ms ±11% 13.9ms ±10% ~ (p=0.687 n=19+20)
Throughput/DynamicPacket/8MB-8 24.0ms ± 7% 24.6ms ± 8% +2.36% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 43.3ms ± 1% 44.3ms ± 2% +2.48% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 84.8ms ± 2% 86.7ms ± 2% +2.27% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 167ms ± 2% 170ms ± 3% +1.89% (p=0.005 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 699ms ± 0% +0.65% (p=0.000 n=9+10)
Latency/MaxPacket/500kbps-8 279ms ± 0% 280ms ± 0% +0.68% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 141ms ± 0% +0.59% (p=0.000 n=9+9)
Latency/MaxPacket/2000kbps-8 71.0ms ± 0% 71.3ms ± 0% +0.42% (p=0.000 n=9+9)
Latency/MaxPacket/5000kbps-8 30.1ms ± 6% 30.7ms ±10% +1.93% (p=0.019 n=9+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 138ms ± 0% +3.22% (p=0.000 n=9+10)
Latency/DynamicPacket/500kbps-8 54.7ms ± 0% 56.3ms ± 0% +3.03% (p=0.000 n=10+8)
Latency/DynamicPacket/1000kbps-8 29.1ms ± 8% 29.1ms ± 0% ~ (p=0.173 n=10+8)
Latency/DynamicPacket/2000kbps-8 15.9ms ±10% 16.4ms ±36% ~ (p=0.633 n=10+8)
Latency/DynamicPacket/5000kbps-8 9.65ms ±82% 8.32ms ± 8% ~ (p=0.573 n=10+8)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 167MB/s ±64% 155MB/s ±55% ~ (p=0.224 n=20+19)
Throughput/MaxPacket/2MB-8 241MB/s ±40% 244MB/s ± 9% ~ (p=0.407 n=20+17)
Throughput/MaxPacket/4MB-8 300MB/s ± 9% 298MB/s ±11% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 340MB/s ±17% 330MB/s ±13% ~ (p=0.201 n=20+20)
Throughput/MaxPacket/16MB-8 367MB/s ±11% 375MB/s ± 5% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 390MB/s ± 4% 382MB/s ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 401MB/s ± 7% 397MB/s ± 2% -0.96% (p=0.030 n=20+19)
Throughput/DynamicPacket/1MB-8 157MB/s ±73% 156MB/s ±39% ~ (p=0.738 n=20+20)
Throughput/DynamicPacket/2MB-8 243MB/s ±18% 220MB/s ±14% -9.65% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 299MB/s ±15% 303MB/s ± 9% ~ (p=0.512 n=20+20)
Throughput/DynamicPacket/8MB-8 350MB/s ± 7% 342MB/s ± 8% -2.27% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 388MB/s ± 1% 378MB/s ± 2% -2.41% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 396MB/s ± 2% 387MB/s ± 2% -2.21% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 403MB/s ± 2% 396MB/s ± 3% -1.84% (p=0.005 n=10+10)
Fixes #9671
Change-Id: Ieb57c5140eb2c083b8be0d42b240cd2eeec0dcf6
Reviewed-on: https://go-review.googlesource.com/c/147638
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2018-11-05 22:52:51 -05:00
|
|
|
t.Run("TLSv12", func(t *testing.T) { testSCTHandshake(t, VersionTLS12) })
|
|
|
|
|
t.Run("TLSv13", func(t *testing.T) { testSCTHandshake(t, VersionTLS13) })
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func testSCTHandshake(t *testing.T, version uint16) {
|
2015-04-16 14:59:22 -04:00
|
|
|
expected := [][]byte{[]byte("certificate"), []byte("transparency")}
|
|
|
|
|
serverConfig := &Config{
|
|
|
|
|
Certificates: []Certificate{{
|
|
|
|
|
Certificate: [][]byte{testRSACertificate},
|
|
|
|
|
PrivateKey: testRSAPrivateKey,
|
|
|
|
|
SignedCertificateTimestamps: expected,
|
|
|
|
|
}},
|
crypto/tls: enable TLS 1.3 and update tests
To disable TLS 1.3, simply remove VersionTLS13 from supportedVersions,
as tested by TestEscapeRoute, and amend documentation. To make it
opt-in, revert the change to (*Config).supportedVersions from this CL.
I did not have the heart to implement the early data skipping feature
when I realized that it did not offer a choice between two
abstraction-breaking options, but demanded them both (look for handshake
type in case of HelloRetryRequest, trial decryption otherwise). It's a
lot of complexity for an apparently small gain, but if anyone has strong
opinions about it let me know.
Note that in TLS 1.3 alerts are encrypted, so the close_notify peeking
to return (n > 0, io.EOF) from Read doesn't work. If we are lucky, those
servers that unexpectedly close connections after serving a single
request will have stopped (maybe thanks to H/2) before they got updated
to TLS 1.3.
Relatedly, session tickets are now provisioned on the client first Read
instead of at Handshake time, because they are, well, post-handshake
messages. If this proves to be a problem we might try to peek at them.
Doubled the tests that cover logic that's different in TLS 1.3.
The benchmarks for TLS 1.2 compared to be0f3c286b5 (before TLS 1.3 and
its refactors, after CL 142817 changed them to use real connections)
show little movement.
name old time/op new time/op delta
HandshakeServer/RSA-8 795µs ± 1% 798µs ± 1% ~ (p=0.057 n=10+18)
HandshakeServer/ECDHE-P256-RSA-8 903µs ± 0% 909µs ± 1% +0.68% (p=0.000 n=8+17)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 198µs ± 0% 204µs ± 1% +3.24% (p=0.000 n=9+18)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 202µs ± 3% 208µs ± 1% +2.98% (p=0.000 n=9+20)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.5ms ± 1% 15.9ms ± 2% +2.49% (p=0.000 n=10+20)
Throughput/MaxPacket/1MB-8 5.81ms ±23% 6.14ms ±44% ~ (p=0.605 n=8+18)
Throughput/MaxPacket/2MB-8 8.91ms ±22% 8.74ms ±33% ~ (p=0.498 n=9+19)
Throughput/MaxPacket/4MB-8 12.8ms ± 3% 14.0ms ±10% +9.74% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 25.1ms ± 7% 24.6ms ±16% ~ (p=0.129 n=9+19)
Throughput/MaxPacket/16MB-8 46.3ms ± 4% 45.9ms ±12% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 88.5ms ± 4% 86.0ms ± 4% -2.82% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 173ms ± 2% 167ms ± 7% -3.42% (p=0.001 n=10+19)
Throughput/DynamicPacket/1MB-8 5.88ms ± 4% 6.59ms ±64% ~ (p=0.232 n=9+18)
Throughput/DynamicPacket/2MB-8 9.08ms ±12% 8.73ms ±21% ~ (p=0.408 n=10+18)
Throughput/DynamicPacket/4MB-8 14.2ms ± 5% 14.0ms ±11% ~ (p=0.188 n=9+19)
Throughput/DynamicPacket/8MB-8 25.1ms ± 6% 24.0ms ± 7% -4.39% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 45.6ms ± 3% 43.3ms ± 1% -5.22% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 88.4ms ± 3% 84.8ms ± 2% -4.06% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 175ms ± 3% 167ms ± 2% -4.63% (p=0.000 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 694ms ± 0% -0.02% (p=0.000 n=9+9)
Latency/MaxPacket/500kbps-8 279ms ± 0% 279ms ± 0% -0.09% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 140ms ± 0% -0.15% (p=0.000 n=10+9)
Latency/MaxPacket/2000kbps-8 71.1ms ± 0% 71.0ms ± 0% -0.09% (p=0.001 n=8+9)
Latency/MaxPacket/5000kbps-8 30.5ms ± 6% 30.1ms ± 6% ~ (p=0.905 n=10+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 134ms ± 0% ~ (p=0.796 n=9+9)
Latency/DynamicPacket/500kbps-8 54.8ms ± 0% 54.7ms ± 0% -0.18% (p=0.000 n=8+10)
Latency/DynamicPacket/1000kbps-8 28.5ms ± 0% 29.1ms ± 8% ~ (p=0.173 n=8+10)
Latency/DynamicPacket/2000kbps-8 15.3ms ± 6% 15.9ms ±10% ~ (p=0.905 n=9+10)
Latency/DynamicPacket/5000kbps-8 9.14ms ±21% 9.65ms ±82% ~ (p=0.529 n=10+10)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 175MB/s ±13% 167MB/s ±64% ~ (p=0.646 n=7+20)
Throughput/MaxPacket/2MB-8 241MB/s ±25% 241MB/s ±40% ~ (p=0.660 n=9+20)
Throughput/MaxPacket/4MB-8 328MB/s ± 3% 300MB/s ± 9% -8.70% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 335MB/s ± 7% 340MB/s ±17% ~ (p=0.212 n=9+20)
Throughput/MaxPacket/16MB-8 363MB/s ± 4% 367MB/s ±11% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 379MB/s ± 4% 390MB/s ± 4% +2.93% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 388MB/s ± 2% 401MB/s ± 7% +3.25% (p=0.004 n=10+20)
Throughput/DynamicPacket/1MB-8 178MB/s ± 4% 157MB/s ±73% ~ (p=0.127 n=9+20)
Throughput/DynamicPacket/2MB-8 232MB/s ±11% 243MB/s ±18% ~ (p=0.415 n=10+18)
Throughput/DynamicPacket/4MB-8 296MB/s ± 5% 299MB/s ±15% ~ (p=0.295 n=9+20)
Throughput/DynamicPacket/8MB-8 334MB/s ± 6% 350MB/s ± 7% +4.58% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 368MB/s ± 3% 388MB/s ± 1% +5.48% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 380MB/s ± 3% 396MB/s ± 2% +4.20% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 384MB/s ± 3% 403MB/s ± 2% +4.83% (p=0.000 n=10+10)
Comparing TLS 1.2 and TLS 1.3 at tip shows a slight (~5-10%) slowdown of
handshakes, which might be worth looking at next cycle, but the latency
improvements are expected to overshadow that.
name old time/op new time/op delta
HandshakeServer/ECDHE-P256-RSA-8 909µs ± 1% 963µs ± 0% +5.87% (p=0.000 n=17+18)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 204µs ± 1% 225µs ± 2% +10.20% (p=0.000 n=18+20)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 208µs ± 1% 230µs ± 2% +10.35% (p=0.000 n=20+18)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.9ms ± 2% 15.9ms ± 1% ~ (p=0.444 n=20+19)
Throughput/MaxPacket/1MB-8 6.14ms ±44% 7.07ms ±46% ~ (p=0.057 n=18+19)
Throughput/MaxPacket/2MB-8 8.74ms ±33% 8.61ms ± 9% ~ (p=0.552 n=19+17)
Throughput/MaxPacket/4MB-8 14.0ms ±10% 14.1ms ±12% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 24.6ms ±16% 25.6ms ±14% ~ (p=0.107 n=19+20)
Throughput/MaxPacket/16MB-8 45.9ms ±12% 44.7ms ± 6% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 86.0ms ± 4% 87.9ms ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 167ms ± 7% 169ms ± 2% +1.26% (p=0.011 n=19+19)
Throughput/DynamicPacket/1MB-8 6.59ms ±64% 6.79ms ±43% ~ (p=0.480 n=18+19)
Throughput/DynamicPacket/2MB-8 8.73ms ±21% 9.58ms ±13% +9.71% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 14.0ms ±11% 13.9ms ±10% ~ (p=0.687 n=19+20)
Throughput/DynamicPacket/8MB-8 24.0ms ± 7% 24.6ms ± 8% +2.36% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 43.3ms ± 1% 44.3ms ± 2% +2.48% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 84.8ms ± 2% 86.7ms ± 2% +2.27% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 167ms ± 2% 170ms ± 3% +1.89% (p=0.005 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 699ms ± 0% +0.65% (p=0.000 n=9+10)
Latency/MaxPacket/500kbps-8 279ms ± 0% 280ms ± 0% +0.68% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 141ms ± 0% +0.59% (p=0.000 n=9+9)
Latency/MaxPacket/2000kbps-8 71.0ms ± 0% 71.3ms ± 0% +0.42% (p=0.000 n=9+9)
Latency/MaxPacket/5000kbps-8 30.1ms ± 6% 30.7ms ±10% +1.93% (p=0.019 n=9+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 138ms ± 0% +3.22% (p=0.000 n=9+10)
Latency/DynamicPacket/500kbps-8 54.7ms ± 0% 56.3ms ± 0% +3.03% (p=0.000 n=10+8)
Latency/DynamicPacket/1000kbps-8 29.1ms ± 8% 29.1ms ± 0% ~ (p=0.173 n=10+8)
Latency/DynamicPacket/2000kbps-8 15.9ms ±10% 16.4ms ±36% ~ (p=0.633 n=10+8)
Latency/DynamicPacket/5000kbps-8 9.65ms ±82% 8.32ms ± 8% ~ (p=0.573 n=10+8)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 167MB/s ±64% 155MB/s ±55% ~ (p=0.224 n=20+19)
Throughput/MaxPacket/2MB-8 241MB/s ±40% 244MB/s ± 9% ~ (p=0.407 n=20+17)
Throughput/MaxPacket/4MB-8 300MB/s ± 9% 298MB/s ±11% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 340MB/s ±17% 330MB/s ±13% ~ (p=0.201 n=20+20)
Throughput/MaxPacket/16MB-8 367MB/s ±11% 375MB/s ± 5% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 390MB/s ± 4% 382MB/s ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 401MB/s ± 7% 397MB/s ± 2% -0.96% (p=0.030 n=20+19)
Throughput/DynamicPacket/1MB-8 157MB/s ±73% 156MB/s ±39% ~ (p=0.738 n=20+20)
Throughput/DynamicPacket/2MB-8 243MB/s ±18% 220MB/s ±14% -9.65% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 299MB/s ±15% 303MB/s ± 9% ~ (p=0.512 n=20+20)
Throughput/DynamicPacket/8MB-8 350MB/s ± 7% 342MB/s ± 8% -2.27% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 388MB/s ± 1% 378MB/s ± 2% -2.41% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 396MB/s ± 2% 387MB/s ± 2% -2.21% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 403MB/s ± 2% 396MB/s ± 3% -1.84% (p=0.005 n=10+10)
Fixes #9671
Change-Id: Ieb57c5140eb2c083b8be0d42b240cd2eeec0dcf6
Reviewed-on: https://go-review.googlesource.com/c/147638
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2018-11-05 22:52:51 -05:00
|
|
|
MaxVersion: version,
|
2015-04-16 14:59:22 -04:00
|
|
|
}
|
|
|
|
|
clientConfig := &Config{
|
|
|
|
|
InsecureSkipVerify: true,
|
|
|
|
|
}
|
2018-10-16 23:47:55 -04:00
|
|
|
_, state, err := testHandshake(t, clientConfig, serverConfig)
|
2015-04-16 14:59:22 -04:00
|
|
|
if err != nil {
|
|
|
|
|
t.Fatalf("handshake failed: %s", err)
|
|
|
|
|
}
|
|
|
|
|
actual := state.SignedCertificateTimestamps
|
|
|
|
|
if len(actual) != len(expected) {
|
|
|
|
|
t.Fatalf("got %d scts, want %d", len(actual), len(expected))
|
|
|
|
|
}
|
|
|
|
|
for i, sct := range expected {
|
|
|
|
|
if !bytes.Equal(sct, actual[i]) {
|
|
|
|
|
t.Fatalf("SCT #%d was %x, but expected %x", i, actual[i], sct)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-15 11:41:40 -05:00
|
|
|
func TestCrossVersionResume(t *testing.T) {
|
crypto/tls: enable TLS 1.3 and update tests
To disable TLS 1.3, simply remove VersionTLS13 from supportedVersions,
as tested by TestEscapeRoute, and amend documentation. To make it
opt-in, revert the change to (*Config).supportedVersions from this CL.
I did not have the heart to implement the early data skipping feature
when I realized that it did not offer a choice between two
abstraction-breaking options, but demanded them both (look for handshake
type in case of HelloRetryRequest, trial decryption otherwise). It's a
lot of complexity for an apparently small gain, but if anyone has strong
opinions about it let me know.
Note that in TLS 1.3 alerts are encrypted, so the close_notify peeking
to return (n > 0, io.EOF) from Read doesn't work. If we are lucky, those
servers that unexpectedly close connections after serving a single
request will have stopped (maybe thanks to H/2) before they got updated
to TLS 1.3.
Relatedly, session tickets are now provisioned on the client first Read
instead of at Handshake time, because they are, well, post-handshake
messages. If this proves to be a problem we might try to peek at them.
Doubled the tests that cover logic that's different in TLS 1.3.
The benchmarks for TLS 1.2 compared to be0f3c286b5 (before TLS 1.3 and
its refactors, after CL 142817 changed them to use real connections)
show little movement.
name old time/op new time/op delta
HandshakeServer/RSA-8 795µs ± 1% 798µs ± 1% ~ (p=0.057 n=10+18)
HandshakeServer/ECDHE-P256-RSA-8 903µs ± 0% 909µs ± 1% +0.68% (p=0.000 n=8+17)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 198µs ± 0% 204µs ± 1% +3.24% (p=0.000 n=9+18)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 202µs ± 3% 208µs ± 1% +2.98% (p=0.000 n=9+20)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.5ms ± 1% 15.9ms ± 2% +2.49% (p=0.000 n=10+20)
Throughput/MaxPacket/1MB-8 5.81ms ±23% 6.14ms ±44% ~ (p=0.605 n=8+18)
Throughput/MaxPacket/2MB-8 8.91ms ±22% 8.74ms ±33% ~ (p=0.498 n=9+19)
Throughput/MaxPacket/4MB-8 12.8ms ± 3% 14.0ms ±10% +9.74% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 25.1ms ± 7% 24.6ms ±16% ~ (p=0.129 n=9+19)
Throughput/MaxPacket/16MB-8 46.3ms ± 4% 45.9ms ±12% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 88.5ms ± 4% 86.0ms ± 4% -2.82% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 173ms ± 2% 167ms ± 7% -3.42% (p=0.001 n=10+19)
Throughput/DynamicPacket/1MB-8 5.88ms ± 4% 6.59ms ±64% ~ (p=0.232 n=9+18)
Throughput/DynamicPacket/2MB-8 9.08ms ±12% 8.73ms ±21% ~ (p=0.408 n=10+18)
Throughput/DynamicPacket/4MB-8 14.2ms ± 5% 14.0ms ±11% ~ (p=0.188 n=9+19)
Throughput/DynamicPacket/8MB-8 25.1ms ± 6% 24.0ms ± 7% -4.39% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 45.6ms ± 3% 43.3ms ± 1% -5.22% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 88.4ms ± 3% 84.8ms ± 2% -4.06% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 175ms ± 3% 167ms ± 2% -4.63% (p=0.000 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 694ms ± 0% -0.02% (p=0.000 n=9+9)
Latency/MaxPacket/500kbps-8 279ms ± 0% 279ms ± 0% -0.09% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 140ms ± 0% -0.15% (p=0.000 n=10+9)
Latency/MaxPacket/2000kbps-8 71.1ms ± 0% 71.0ms ± 0% -0.09% (p=0.001 n=8+9)
Latency/MaxPacket/5000kbps-8 30.5ms ± 6% 30.1ms ± 6% ~ (p=0.905 n=10+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 134ms ± 0% ~ (p=0.796 n=9+9)
Latency/DynamicPacket/500kbps-8 54.8ms ± 0% 54.7ms ± 0% -0.18% (p=0.000 n=8+10)
Latency/DynamicPacket/1000kbps-8 28.5ms ± 0% 29.1ms ± 8% ~ (p=0.173 n=8+10)
Latency/DynamicPacket/2000kbps-8 15.3ms ± 6% 15.9ms ±10% ~ (p=0.905 n=9+10)
Latency/DynamicPacket/5000kbps-8 9.14ms ±21% 9.65ms ±82% ~ (p=0.529 n=10+10)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 175MB/s ±13% 167MB/s ±64% ~ (p=0.646 n=7+20)
Throughput/MaxPacket/2MB-8 241MB/s ±25% 241MB/s ±40% ~ (p=0.660 n=9+20)
Throughput/MaxPacket/4MB-8 328MB/s ± 3% 300MB/s ± 9% -8.70% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 335MB/s ± 7% 340MB/s ±17% ~ (p=0.212 n=9+20)
Throughput/MaxPacket/16MB-8 363MB/s ± 4% 367MB/s ±11% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 379MB/s ± 4% 390MB/s ± 4% +2.93% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 388MB/s ± 2% 401MB/s ± 7% +3.25% (p=0.004 n=10+20)
Throughput/DynamicPacket/1MB-8 178MB/s ± 4% 157MB/s ±73% ~ (p=0.127 n=9+20)
Throughput/DynamicPacket/2MB-8 232MB/s ±11% 243MB/s ±18% ~ (p=0.415 n=10+18)
Throughput/DynamicPacket/4MB-8 296MB/s ± 5% 299MB/s ±15% ~ (p=0.295 n=9+20)
Throughput/DynamicPacket/8MB-8 334MB/s ± 6% 350MB/s ± 7% +4.58% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 368MB/s ± 3% 388MB/s ± 1% +5.48% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 380MB/s ± 3% 396MB/s ± 2% +4.20% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 384MB/s ± 3% 403MB/s ± 2% +4.83% (p=0.000 n=10+10)
Comparing TLS 1.2 and TLS 1.3 at tip shows a slight (~5-10%) slowdown of
handshakes, which might be worth looking at next cycle, but the latency
improvements are expected to overshadow that.
name old time/op new time/op delta
HandshakeServer/ECDHE-P256-RSA-8 909µs ± 1% 963µs ± 0% +5.87% (p=0.000 n=17+18)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 204µs ± 1% 225µs ± 2% +10.20% (p=0.000 n=18+20)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 208µs ± 1% 230µs ± 2% +10.35% (p=0.000 n=20+18)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.9ms ± 2% 15.9ms ± 1% ~ (p=0.444 n=20+19)
Throughput/MaxPacket/1MB-8 6.14ms ±44% 7.07ms ±46% ~ (p=0.057 n=18+19)
Throughput/MaxPacket/2MB-8 8.74ms ±33% 8.61ms ± 9% ~ (p=0.552 n=19+17)
Throughput/MaxPacket/4MB-8 14.0ms ±10% 14.1ms ±12% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 24.6ms ±16% 25.6ms ±14% ~ (p=0.107 n=19+20)
Throughput/MaxPacket/16MB-8 45.9ms ±12% 44.7ms ± 6% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 86.0ms ± 4% 87.9ms ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 167ms ± 7% 169ms ± 2% +1.26% (p=0.011 n=19+19)
Throughput/DynamicPacket/1MB-8 6.59ms ±64% 6.79ms ±43% ~ (p=0.480 n=18+19)
Throughput/DynamicPacket/2MB-8 8.73ms ±21% 9.58ms ±13% +9.71% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 14.0ms ±11% 13.9ms ±10% ~ (p=0.687 n=19+20)
Throughput/DynamicPacket/8MB-8 24.0ms ± 7% 24.6ms ± 8% +2.36% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 43.3ms ± 1% 44.3ms ± 2% +2.48% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 84.8ms ± 2% 86.7ms ± 2% +2.27% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 167ms ± 2% 170ms ± 3% +1.89% (p=0.005 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 699ms ± 0% +0.65% (p=0.000 n=9+10)
Latency/MaxPacket/500kbps-8 279ms ± 0% 280ms ± 0% +0.68% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 141ms ± 0% +0.59% (p=0.000 n=9+9)
Latency/MaxPacket/2000kbps-8 71.0ms ± 0% 71.3ms ± 0% +0.42% (p=0.000 n=9+9)
Latency/MaxPacket/5000kbps-8 30.1ms ± 6% 30.7ms ±10% +1.93% (p=0.019 n=9+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 138ms ± 0% +3.22% (p=0.000 n=9+10)
Latency/DynamicPacket/500kbps-8 54.7ms ± 0% 56.3ms ± 0% +3.03% (p=0.000 n=10+8)
Latency/DynamicPacket/1000kbps-8 29.1ms ± 8% 29.1ms ± 0% ~ (p=0.173 n=10+8)
Latency/DynamicPacket/2000kbps-8 15.9ms ±10% 16.4ms ±36% ~ (p=0.633 n=10+8)
Latency/DynamicPacket/5000kbps-8 9.65ms ±82% 8.32ms ± 8% ~ (p=0.573 n=10+8)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 167MB/s ±64% 155MB/s ±55% ~ (p=0.224 n=20+19)
Throughput/MaxPacket/2MB-8 241MB/s ±40% 244MB/s ± 9% ~ (p=0.407 n=20+17)
Throughput/MaxPacket/4MB-8 300MB/s ± 9% 298MB/s ±11% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 340MB/s ±17% 330MB/s ±13% ~ (p=0.201 n=20+20)
Throughput/MaxPacket/16MB-8 367MB/s ±11% 375MB/s ± 5% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 390MB/s ± 4% 382MB/s ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 401MB/s ± 7% 397MB/s ± 2% -0.96% (p=0.030 n=20+19)
Throughput/DynamicPacket/1MB-8 157MB/s ±73% 156MB/s ±39% ~ (p=0.738 n=20+20)
Throughput/DynamicPacket/2MB-8 243MB/s ±18% 220MB/s ±14% -9.65% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 299MB/s ±15% 303MB/s ± 9% ~ (p=0.512 n=20+20)
Throughput/DynamicPacket/8MB-8 350MB/s ± 7% 342MB/s ± 8% -2.27% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 388MB/s ± 1% 378MB/s ± 2% -2.41% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 396MB/s ± 2% 387MB/s ± 2% -2.21% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 403MB/s ± 2% 396MB/s ± 3% -1.84% (p=0.005 n=10+10)
Fixes #9671
Change-Id: Ieb57c5140eb2c083b8be0d42b240cd2eeec0dcf6
Reviewed-on: https://go-review.googlesource.com/c/147638
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2018-11-05 22:52:51 -05:00
|
|
|
t.Run("TLSv12", func(t *testing.T) { testCrossVersionResume(t, VersionTLS12) })
|
|
|
|
|
t.Run("TLSv13", func(t *testing.T) { testCrossVersionResume(t, VersionTLS13) })
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func testCrossVersionResume(t *testing.T, version uint16) {
|
2016-02-15 11:41:40 -05:00
|
|
|
serverConfig := &Config{
|
|
|
|
|
CipherSuites: []uint16{TLS_RSA_WITH_AES_128_CBC_SHA},
|
|
|
|
|
Certificates: testConfig.Certificates,
|
|
|
|
|
}
|
|
|
|
|
clientConfig := &Config{
|
|
|
|
|
CipherSuites: []uint16{TLS_RSA_WITH_AES_128_CBC_SHA},
|
|
|
|
|
InsecureSkipVerify: true,
|
|
|
|
|
ClientSessionCache: NewLRUClientSessionCache(1),
|
|
|
|
|
ServerName: "servername",
|
2023-11-10 10:12:48 -08:00
|
|
|
MinVersion: VersionTLS12,
|
2016-02-15 11:41:40 -05:00
|
|
|
}
|
|
|
|
|
|
2023-11-10 10:12:48 -08:00
|
|
|
// Establish a session at TLS 1.3.
|
|
|
|
|
clientConfig.MaxVersion = VersionTLS13
|
2018-10-16 23:47:55 -04:00
|
|
|
_, _, err := testHandshake(t, clientConfig, serverConfig)
|
2016-02-15 11:41:40 -05:00
|
|
|
if err != nil {
|
|
|
|
|
t.Fatalf("handshake failed: %s", err)
|
|
|
|
|
}
|
|
|
|
|
|
2023-11-10 10:12:48 -08:00
|
|
|
// The client session cache now contains a TLS 1.3 session.
|
2018-10-16 23:47:55 -04:00
|
|
|
state, _, err := testHandshake(t, clientConfig, serverConfig)
|
2016-02-15 11:41:40 -05:00
|
|
|
if err != nil {
|
|
|
|
|
t.Fatalf("handshake failed: %s", err)
|
|
|
|
|
}
|
|
|
|
|
if !state.DidResume {
|
|
|
|
|
t.Fatalf("handshake did not resume at the same version")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Test that the server will decline to resume at a lower version.
|
2023-11-10 10:12:48 -08:00
|
|
|
clientConfig.MaxVersion = VersionTLS12
|
2018-10-16 23:47:55 -04:00
|
|
|
state, _, err = testHandshake(t, clientConfig, serverConfig)
|
2016-02-15 11:41:40 -05:00
|
|
|
if err != nil {
|
|
|
|
|
t.Fatalf("handshake failed: %s", err)
|
|
|
|
|
}
|
|
|
|
|
if state.DidResume {
|
|
|
|
|
t.Fatalf("handshake resumed at a lower version")
|
|
|
|
|
}
|
|
|
|
|
|
2023-11-10 10:12:48 -08:00
|
|
|
// The client session cache now contains a TLS 1.2 session.
|
2018-10-16 23:47:55 -04:00
|
|
|
state, _, err = testHandshake(t, clientConfig, serverConfig)
|
2016-02-15 11:41:40 -05:00
|
|
|
if err != nil {
|
|
|
|
|
t.Fatalf("handshake failed: %s", err)
|
|
|
|
|
}
|
|
|
|
|
if !state.DidResume {
|
|
|
|
|
t.Fatalf("handshake did not resume at the same version")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Test that the server will decline to resume at a higher version.
|
2023-11-10 10:12:48 -08:00
|
|
|
clientConfig.MaxVersion = VersionTLS13
|
2018-10-16 23:47:55 -04:00
|
|
|
state, _, err = testHandshake(t, clientConfig, serverConfig)
|
2016-02-15 11:41:40 -05:00
|
|
|
if err != nil {
|
|
|
|
|
t.Fatalf("handshake failed: %s", err)
|
|
|
|
|
}
|
|
|
|
|
if state.DidResume {
|
|
|
|
|
t.Fatalf("handshake resumed at a higher version")
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
// Note: see comment in handshake_test.go for details of how the reference
|
|
|
|
|
// tests work.
|
|
|
|
|
|
|
|
|
|
// serverTest represents a test of the TLS server handshake against a reference
|
|
|
|
|
// implementation.
|
|
|
|
|
type serverTest struct {
|
|
|
|
|
// name is a freeform string identifying the test and the file in which
|
|
|
|
|
// the expected results will be stored.
|
|
|
|
|
name string
|
|
|
|
|
// command, if not empty, contains a series of arguments for the
|
|
|
|
|
// command to run for the reference server.
|
|
|
|
|
command []string
|
|
|
|
|
// expectedPeerCerts contains a list of PEM blocks of expected
|
|
|
|
|
// certificates from the client.
|
|
|
|
|
expectedPeerCerts []string
|
|
|
|
|
// config, if not nil, contains a custom Config to use for this test.
|
|
|
|
|
config *Config
|
2014-10-15 17:54:04 -07:00
|
|
|
// expectHandshakeErrorIncluding, when not empty, contains a string
|
|
|
|
|
// that must be a substring of the error resulting from the handshake.
|
|
|
|
|
expectHandshakeErrorIncluding string
|
2014-08-05 11:36:20 -07:00
|
|
|
// validate, if not nil, is a function that will be called with the
|
|
|
|
|
// ConnectionState of the resulting connection. It returns false if the
|
|
|
|
|
// ConnectionState is unacceptable.
|
|
|
|
|
validate func(ConnectionState) error
|
2018-11-01 01:01:09 -04:00
|
|
|
// wait, if true, prevents this subtest from calling t.Parallel.
|
|
|
|
|
// If false, runServerTest* returns immediately.
|
|
|
|
|
wait bool
|
2013-12-20 11:37:05 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
var defaultClientCommand = []string{"openssl", "s_client", "-no_ticket"}
|
|
|
|
|
|
|
|
|
|
// connFromCommand starts opens a listening socket and starts the reference
|
|
|
|
|
// client to connect to it. It returns a recordingConn that wraps the resulting
|
|
|
|
|
// connection.
|
|
|
|
|
func (test *serverTest) connFromCommand() (conn *recordingConn, child *exec.Cmd, err error) {
|
|
|
|
|
l, err := net.ListenTCP("tcp", &net.TCPAddr{
|
|
|
|
|
IP: net.IPv4(127, 0, 0, 1),
|
|
|
|
|
Port: 0,
|
|
|
|
|
})
|
|
|
|
|
if err != nil {
|
|
|
|
|
return nil, nil, err
|
2012-01-05 12:05:38 -05:00
|
|
|
}
|
2013-12-20 11:37:05 -05:00
|
|
|
defer l.Close()
|
2009-11-05 15:44:32 -08:00
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
port := l.Addr().(*net.TCPAddr).Port
|
2012-01-05 12:05:38 -05:00
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
var command []string
|
|
|
|
|
command = append(command, test.command...)
|
|
|
|
|
if len(command) == 0 {
|
|
|
|
|
command = defaultClientCommand
|
2013-07-17 12:33:16 -04:00
|
|
|
}
|
2013-12-20 11:37:05 -05:00
|
|
|
command = append(command, "-connect")
|
|
|
|
|
command = append(command, fmt.Sprintf("127.0.0.1:%d", port))
|
|
|
|
|
cmd := exec.Command(command[0], command[1:]...)
|
|
|
|
|
cmd.Stdin = nil
|
|
|
|
|
var output bytes.Buffer
|
|
|
|
|
cmd.Stdout = &output
|
|
|
|
|
cmd.Stderr = &output
|
|
|
|
|
if err := cmd.Start(); err != nil {
|
|
|
|
|
return nil, nil, err
|
2012-01-05 12:05:38 -05:00
|
|
|
}
|
2011-09-12 16:52:49 -04:00
|
|
|
|
2021-12-01 12:15:45 -05:00
|
|
|
connChan := make(chan any, 1)
|
2013-12-20 11:37:05 -05:00
|
|
|
go func() {
|
|
|
|
|
tcpConn, err := l.Accept()
|
|
|
|
|
if err != nil {
|
|
|
|
|
connChan <- err
|
2020-02-13 16:20:30 -05:00
|
|
|
return
|
2013-12-20 11:37:05 -05:00
|
|
|
}
|
|
|
|
|
connChan <- tcpConn
|
|
|
|
|
}()
|
2013-09-17 13:30:36 -04:00
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
var tcpConn net.Conn
|
|
|
|
|
select {
|
|
|
|
|
case connOrError := <-connChan:
|
|
|
|
|
if err, ok := connOrError.(error); ok {
|
|
|
|
|
return nil, nil, err
|
|
|
|
|
}
|
|
|
|
|
tcpConn = connOrError.(net.Conn)
|
|
|
|
|
case <-time.After(2 * time.Second):
|
|
|
|
|
return nil, nil, errors.New("timed out waiting for connection from child process")
|
2013-09-17 13:30:36 -04:00
|
|
|
}
|
2013-08-29 17:18:59 -04:00
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
record := &recordingConn{
|
|
|
|
|
Conn: tcpConn,
|
2012-04-11 12:55:57 -04:00
|
|
|
}
|
|
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
return record, cmd, nil
|
2012-04-11 12:55:57 -04:00
|
|
|
}
|
|
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
func (test *serverTest) dataPath() string {
|
|
|
|
|
return filepath.Join("testdata", "Server-"+test.name)
|
2012-04-11 12:55:57 -04:00
|
|
|
}
|
|
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
func (test *serverTest) loadData() (flows [][]byte, err error) {
|
|
|
|
|
in, err := os.Open(test.dataPath())
|
|
|
|
|
if err != nil {
|
|
|
|
|
return nil, err
|
2012-04-11 12:55:57 -04:00
|
|
|
}
|
2013-12-20 11:37:05 -05:00
|
|
|
defer in.Close()
|
|
|
|
|
return parseTestData(in)
|
2012-04-11 12:55:57 -04:00
|
|
|
}
|
|
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
func (test *serverTest) run(t *testing.T, write bool) {
|
2024-06-23 14:10:14 +02:00
|
|
|
var serverConn net.Conn
|
2013-12-20 11:37:05 -05:00
|
|
|
var recordingConn *recordingConn
|
|
|
|
|
var childProcess *exec.Cmd
|
2013-07-17 12:33:16 -04:00
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
if write {
|
|
|
|
|
var err error
|
|
|
|
|
recordingConn, childProcess, err = test.connFromCommand()
|
2011-10-11 13:07:32 -04:00
|
|
|
if err != nil {
|
2013-12-20 11:37:05 -05:00
|
|
|
t.Fatalf("Failed to start subcommand: %s", err)
|
2011-10-11 13:07:32 -04:00
|
|
|
}
|
2013-12-20 11:37:05 -05:00
|
|
|
serverConn = recordingConn
|
2018-11-29 01:38:07 -05:00
|
|
|
defer func() {
|
|
|
|
|
if t.Failed() {
|
|
|
|
|
t.Logf("OpenSSL output:\n\n%s", childProcess.Stdout)
|
|
|
|
|
}
|
|
|
|
|
}()
|
2013-12-20 11:37:05 -05:00
|
|
|
} else {
|
2024-06-23 14:10:14 +02:00
|
|
|
flows, err := test.loadData()
|
|
|
|
|
if err != nil {
|
|
|
|
|
t.Fatalf("Failed to load data from %s", test.dataPath())
|
|
|
|
|
}
|
|
|
|
|
serverConn = &replayingConn{t: t, flows: flows, reading: true}
|
2011-10-11 13:07:32 -04:00
|
|
|
}
|
2013-12-20 11:37:05 -05:00
|
|
|
config := test.config
|
|
|
|
|
if config == nil {
|
|
|
|
|
config = testConfig
|
2013-07-17 12:33:16 -04:00
|
|
|
}
|
2013-12-20 11:37:05 -05:00
|
|
|
server := Server(serverConn, config)
|
2009-11-05 15:44:32 -08:00
|
|
|
|
2024-06-23 14:10:14 +02:00
|
|
|
_, err := server.Write([]byte("hello, world\n"))
|
|
|
|
|
if len(test.expectHandshakeErrorIncluding) > 0 {
|
|
|
|
|
if err == nil {
|
|
|
|
|
t.Errorf("Error expected, but no error returned")
|
|
|
|
|
} else if s := err.Error(); !strings.Contains(s, test.expectHandshakeErrorIncluding) {
|
|
|
|
|
t.Errorf("Error expected containing '%s' but got '%s'", test.expectHandshakeErrorIncluding, s)
|
2012-04-11 12:55:57 -04:00
|
|
|
}
|
2024-06-23 14:10:14 +02:00
|
|
|
} else {
|
|
|
|
|
if err != nil {
|
|
|
|
|
t.Logf("Error from Server.Write: '%s'", err)
|
2012-04-11 12:55:57 -04:00
|
|
|
}
|
2013-12-20 11:37:05 -05:00
|
|
|
}
|
2024-06-23 14:10:14 +02:00
|
|
|
server.Close()
|
2012-04-11 12:55:57 -04:00
|
|
|
|
2024-06-23 14:10:14 +02:00
|
|
|
connState := server.ConnectionState()
|
2014-08-05 11:36:20 -07:00
|
|
|
peerCerts := connState.PeerCertificates
|
2013-12-20 11:37:05 -05:00
|
|
|
if len(peerCerts) == len(test.expectedPeerCerts) {
|
|
|
|
|
for i, peerCert := range peerCerts {
|
|
|
|
|
block, _ := pem.Decode([]byte(test.expectedPeerCerts[i]))
|
|
|
|
|
if !bytes.Equal(block.Bytes, peerCert.Raw) {
|
|
|
|
|
t.Fatalf("%s: mismatch on peer cert %d", test.name, i+1)
|
|
|
|
|
}
|
2010-04-26 22:19:04 -07:00
|
|
|
}
|
2013-12-20 11:37:05 -05:00
|
|
|
} else {
|
|
|
|
|
t.Fatalf("%s: mismatch on peer list length: %d (wanted) != %d (got)", test.name, len(test.expectedPeerCerts), len(peerCerts))
|
|
|
|
|
}
|
2012-01-05 12:05:38 -05:00
|
|
|
|
2014-08-05 11:36:20 -07:00
|
|
|
if test.validate != nil {
|
|
|
|
|
if err := test.validate(connState); err != nil {
|
|
|
|
|
t.Fatalf("validate callback returned error: %s", err)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
if write {
|
2024-06-23 14:10:14 +02:00
|
|
|
serverConn.Close()
|
2013-12-20 11:37:05 -05:00
|
|
|
path := test.dataPath()
|
|
|
|
|
out, err := os.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0644)
|
2010-12-16 17:14:02 -05:00
|
|
|
if err != nil {
|
2013-12-20 11:37:05 -05:00
|
|
|
t.Fatalf("Failed to create output file: %s", err)
|
2010-12-16 17:14:02 -05:00
|
|
|
}
|
2013-12-20 11:37:05 -05:00
|
|
|
defer out.Close()
|
|
|
|
|
recordingConn.Close()
|
|
|
|
|
if len(recordingConn.flows) < 3 {
|
2014-10-15 17:54:04 -07:00
|
|
|
if len(test.expectHandshakeErrorIncluding) == 0 {
|
|
|
|
|
t.Fatalf("Handshake failed")
|
|
|
|
|
}
|
2013-12-20 11:37:05 -05:00
|
|
|
}
|
|
|
|
|
recordingConn.WriteTo(out)
|
2018-11-29 01:38:07 -05:00
|
|
|
t.Logf("Wrote %s\n", path)
|
2013-12-20 11:37:05 -05:00
|
|
|
childProcess.Wait()
|
2010-04-26 22:19:04 -07:00
|
|
|
}
|
|
|
|
|
}
|
2009-11-05 15:44:32 -08:00
|
|
|
|
2018-11-01 01:01:09 -04:00
|
|
|
func runServerTestForVersion(t *testing.T, template *serverTest, version, option string) {
|
2019-10-30 18:02:09 -04:00
|
|
|
// Make a deep copy of the template before going parallel.
|
|
|
|
|
test := *template
|
|
|
|
|
if template.config != nil {
|
|
|
|
|
test.config = template.config.Clone()
|
|
|
|
|
}
|
|
|
|
|
test.name = version + "-" + test.name
|
|
|
|
|
if len(test.command) == 0 {
|
|
|
|
|
test.command = defaultClientCommand
|
|
|
|
|
}
|
|
|
|
|
test.command = append([]string(nil), test.command...)
|
|
|
|
|
test.command = append(test.command, option)
|
2018-11-01 01:01:09 -04:00
|
|
|
|
2019-10-30 18:02:09 -04:00
|
|
|
runTestAndUpdateIfNeeded(t, version, test.run, test.wait)
|
2009-11-05 15:44:32 -08:00
|
|
|
}
|
|
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
func runServerTestTLS10(t *testing.T, template *serverTest) {
|
2018-11-01 01:01:09 -04:00
|
|
|
runServerTestForVersion(t, template, "TLSv10", "-tls1")
|
2013-12-20 11:37:05 -05:00
|
|
|
}
|
2012-04-12 12:35:21 -04:00
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
func runServerTestTLS11(t *testing.T, template *serverTest) {
|
2018-11-01 01:01:09 -04:00
|
|
|
runServerTestForVersion(t, template, "TLSv11", "-tls1_1")
|
2010-04-26 22:19:04 -07:00
|
|
|
}
|
|
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
func runServerTestTLS12(t *testing.T, template *serverTest) {
|
2018-11-01 01:01:09 -04:00
|
|
|
runServerTestForVersion(t, template, "TLSv12", "-tls1_2")
|
2013-07-17 12:33:16 -04:00
|
|
|
}
|
|
|
|
|
|
2018-11-02 00:57:30 -04:00
|
|
|
func runServerTestTLS13(t *testing.T, template *serverTest) {
|
|
|
|
|
runServerTestForVersion(t, template, "TLSv13", "-tls1_3")
|
|
|
|
|
}
|
|
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
func TestHandshakeServerRSARC4(t *testing.T) {
|
|
|
|
|
test := &serverTest{
|
|
|
|
|
name: "RSA-RC4",
|
|
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-cipher", "RC4-SHA"},
|
2012-01-05 12:05:38 -05:00
|
|
|
}
|
2013-12-20 11:37:05 -05:00
|
|
|
runServerTestTLS10(t, test)
|
|
|
|
|
runServerTestTLS11(t, test)
|
|
|
|
|
runServerTestTLS12(t, test)
|
2012-01-05 12:05:38 -05:00
|
|
|
}
|
|
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
func TestHandshakeServerRSA3DES(t *testing.T) {
|
|
|
|
|
test := &serverTest{
|
|
|
|
|
name: "RSA-3DES",
|
|
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-cipher", "DES-CBC3-SHA"},
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS10(t, test)
|
|
|
|
|
runServerTestTLS12(t, test)
|
2010-12-15 11:49:55 -05:00
|
|
|
}
|
2010-04-26 22:19:04 -07:00
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
func TestHandshakeServerRSAAES(t *testing.T) {
|
|
|
|
|
test := &serverTest{
|
|
|
|
|
name: "RSA-AES",
|
|
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-cipher", "AES128-SHA"},
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS10(t, test)
|
|
|
|
|
runServerTestTLS12(t, test)
|
2011-10-11 13:07:32 -04:00
|
|
|
}
|
|
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
func TestHandshakeServerAESGCM(t *testing.T) {
|
|
|
|
|
test := &serverTest{
|
|
|
|
|
name: "RSA-AES-GCM",
|
|
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-cipher", "ECDHE-RSA-AES128-GCM-SHA256"},
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS12(t, test)
|
2009-11-05 15:44:32 -08:00
|
|
|
}
|
2011-09-14 15:32:19 -04:00
|
|
|
|
2015-02-03 16:15:18 -08:00
|
|
|
func TestHandshakeServerAES256GCMSHA384(t *testing.T) {
|
|
|
|
|
test := &serverTest{
|
|
|
|
|
name: "RSA-AES256-GCM-SHA384",
|
|
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-cipher", "ECDHE-RSA-AES256-GCM-SHA384"},
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS12(t, test)
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-02 00:57:30 -04:00
|
|
|
func TestHandshakeServerAES128SHA256(t *testing.T) {
|
|
|
|
|
test := &serverTest{
|
|
|
|
|
name: "AES128-SHA256",
|
|
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-ciphersuites", "TLS_AES_128_GCM_SHA256"},
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS13(t, test)
|
|
|
|
|
}
|
|
|
|
|
func TestHandshakeServerAES256SHA384(t *testing.T) {
|
|
|
|
|
test := &serverTest{
|
|
|
|
|
name: "AES256-SHA384",
|
|
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-ciphersuites", "TLS_AES_256_GCM_SHA384"},
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS13(t, test)
|
|
|
|
|
}
|
|
|
|
|
func TestHandshakeServerCHACHA20SHA256(t *testing.T) {
|
|
|
|
|
test := &serverTest{
|
|
|
|
|
name: "CHACHA20-SHA256",
|
|
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-ciphersuites", "TLS_CHACHA20_POLY1305_SHA256"},
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS13(t, test)
|
|
|
|
|
}
|
|
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
func TestHandshakeServerECDHEECDSAAES(t *testing.T) {
|
2016-08-30 03:19:01 +00:00
|
|
|
config := testConfig.Clone()
|
2013-12-20 11:37:05 -05:00
|
|
|
config.Certificates = make([]Certificate, 1)
|
|
|
|
|
config.Certificates[0].Certificate = [][]byte{testECDSACertificate}
|
|
|
|
|
config.Certificates[0].PrivateKey = testECDSAPrivateKey
|
|
|
|
|
config.BuildNameToCertificate()
|
2013-07-17 12:33:16 -04:00
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
test := &serverTest{
|
|
|
|
|
name: "ECDHE-ECDSA-AES",
|
2018-11-02 00:57:30 -04:00
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-cipher", "ECDHE-ECDSA-AES256-SHA", "-ciphersuites", "TLS_AES_128_GCM_SHA256"},
|
2016-06-21 07:00:41 -07:00
|
|
|
config: config,
|
2013-12-20 11:37:05 -05:00
|
|
|
}
|
|
|
|
|
runServerTestTLS10(t, test)
|
|
|
|
|
runServerTestTLS12(t, test)
|
2018-11-02 00:57:30 -04:00
|
|
|
runServerTestTLS13(t, test)
|
2011-09-14 15:32:19 -04:00
|
|
|
}
|
2012-01-05 12:05:38 -05:00
|
|
|
|
2016-10-10 18:23:37 -07:00
|
|
|
func TestHandshakeServerX25519(t *testing.T) {
|
|
|
|
|
config := testConfig.Clone()
|
|
|
|
|
config.CurvePreferences = []CurveID{X25519}
|
|
|
|
|
|
|
|
|
|
test := &serverTest{
|
2018-11-02 00:57:30 -04:00
|
|
|
name: "X25519",
|
2020-10-15 18:32:20 -07:00
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-cipher", "ECDHE-RSA-CHACHA20-POLY1305", "-ciphersuites", "TLS_CHACHA20_POLY1305_SHA256", "-curves", "X25519"},
|
2016-10-10 18:23:37 -07:00
|
|
|
config: config,
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS12(t, test)
|
2018-11-02 00:57:30 -04:00
|
|
|
runServerTestTLS13(t, test)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestHandshakeServerP256(t *testing.T) {
|
|
|
|
|
config := testConfig.Clone()
|
|
|
|
|
config.CurvePreferences = []CurveID{CurveP256}
|
|
|
|
|
|
|
|
|
|
test := &serverTest{
|
|
|
|
|
name: "P256",
|
2020-10-15 18:32:20 -07:00
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-cipher", "ECDHE-RSA-CHACHA20-POLY1305", "-ciphersuites", "TLS_CHACHA20_POLY1305_SHA256", "-curves", "P-256"},
|
2018-11-02 00:57:30 -04:00
|
|
|
config: config,
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS12(t, test)
|
|
|
|
|
runServerTestTLS13(t, test)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestHandshakeServerHelloRetryRequest(t *testing.T) {
|
|
|
|
|
config := testConfig.Clone()
|
|
|
|
|
config.CurvePreferences = []CurveID{CurveP256}
|
|
|
|
|
|
|
|
|
|
test := &serverTest{
|
|
|
|
|
name: "HelloRetryRequest",
|
2020-10-15 18:32:20 -07:00
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-ciphersuites", "TLS_CHACHA20_POLY1305_SHA256", "-curves", "X25519:P-256"},
|
2018-11-02 00:57:30 -04:00
|
|
|
config: config,
|
2024-05-18 19:35:39 +02:00
|
|
|
validate: func(cs ConnectionState) error {
|
|
|
|
|
if !cs.testingOnlyDidHRR {
|
|
|
|
|
return errors.New("expected HelloRetryRequest")
|
|
|
|
|
}
|
|
|
|
|
return nil
|
|
|
|
|
},
|
2018-11-02 00:57:30 -04:00
|
|
|
}
|
|
|
|
|
runServerTestTLS13(t, test)
|
2016-10-10 18:23:37 -07:00
|
|
|
}
|
|
|
|
|
|
2024-05-18 19:35:39 +02:00
|
|
|
// TestHandshakeServerKeySharePreference checks that we prefer a key share even
|
|
|
|
|
// if it's later in the CurvePreferences order.
|
|
|
|
|
func TestHandshakeServerKeySharePreference(t *testing.T) {
|
|
|
|
|
config := testConfig.Clone()
|
|
|
|
|
config.CurvePreferences = []CurveID{X25519, CurveP256}
|
|
|
|
|
|
|
|
|
|
test := &serverTest{
|
|
|
|
|
name: "KeySharePreference",
|
|
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-ciphersuites", "TLS_CHACHA20_POLY1305_SHA256", "-curves", "P-256:X25519"},
|
|
|
|
|
config: config,
|
|
|
|
|
validate: func(cs ConnectionState) error {
|
|
|
|
|
if cs.testingOnlyDidHRR {
|
|
|
|
|
return errors.New("unexpected HelloRetryRequest")
|
|
|
|
|
}
|
|
|
|
|
return nil
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS13(t, test)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// TestHandshakeServerUnsupportedKeyShare tests a client that sends a key share
|
|
|
|
|
// that's not in the supported groups list.
|
|
|
|
|
func TestHandshakeServerUnsupportedKeyShare(t *testing.T) {
|
|
|
|
|
pk, _ := ecdh.X25519().GenerateKey(rand.Reader)
|
|
|
|
|
clientHello := &clientHelloMsg{
|
|
|
|
|
vers: VersionTLS12,
|
|
|
|
|
random: make([]byte, 32),
|
|
|
|
|
supportedVersions: []uint16{VersionTLS13},
|
|
|
|
|
cipherSuites: []uint16{TLS_CHACHA20_POLY1305_SHA256},
|
|
|
|
|
compressionMethods: []uint8{compressionNone},
|
|
|
|
|
keyShares: []keyShare{{group: X25519, data: pk.PublicKey().Bytes()}},
|
|
|
|
|
supportedCurves: []CurveID{CurveP256},
|
|
|
|
|
}
|
|
|
|
|
testClientHelloFailure(t, testConfig, clientHello, "client sent key share for group it does not support")
|
|
|
|
|
}
|
|
|
|
|
|
2014-08-05 11:36:20 -07:00
|
|
|
func TestHandshakeServerALPN(t *testing.T) {
|
2016-08-30 03:19:01 +00:00
|
|
|
config := testConfig.Clone()
|
2014-08-05 11:36:20 -07:00
|
|
|
config.NextProtos = []string{"proto1", "proto2"}
|
|
|
|
|
|
|
|
|
|
test := &serverTest{
|
|
|
|
|
name: "ALPN",
|
|
|
|
|
// Note that this needs OpenSSL 1.0.2 because that is the first
|
|
|
|
|
// version that supports the -alpn flag.
|
2020-10-15 18:32:20 -07:00
|
|
|
command: []string{"openssl", "s_client", "-alpn", "proto2,proto1", "-cipher", "ECDHE-RSA-CHACHA20-POLY1305", "-ciphersuites", "TLS_CHACHA20_POLY1305_SHA256"},
|
2016-06-21 07:00:41 -07:00
|
|
|
config: config,
|
2014-08-05 11:36:20 -07:00
|
|
|
validate: func(state ConnectionState) error {
|
|
|
|
|
// The server's preferences should override the client.
|
|
|
|
|
if state.NegotiatedProtocol != "proto1" {
|
|
|
|
|
return fmt.Errorf("Got protocol %q, wanted proto1", state.NegotiatedProtocol)
|
|
|
|
|
}
|
|
|
|
|
return nil
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS12(t, test)
|
2018-11-02 00:57:30 -04:00
|
|
|
runServerTestTLS13(t, test)
|
2014-08-05 11:36:20 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestHandshakeServerALPNNoMatch(t *testing.T) {
|
2016-08-30 03:19:01 +00:00
|
|
|
config := testConfig.Clone()
|
2014-08-05 11:36:20 -07:00
|
|
|
config.NextProtos = []string{"proto3"}
|
|
|
|
|
|
|
|
|
|
test := &serverTest{
|
|
|
|
|
name: "ALPN-NoMatch",
|
|
|
|
|
// Note that this needs OpenSSL 1.0.2 because that is the first
|
|
|
|
|
// version that supports the -alpn flag.
|
2021-02-02 12:58:30 -08:00
|
|
|
command: []string{"openssl", "s_client", "-alpn", "proto2,proto1", "-cipher", "ECDHE-RSA-CHACHA20-POLY1305", "-ciphersuites", "TLS_CHACHA20_POLY1305_SHA256"},
|
|
|
|
|
config: config,
|
|
|
|
|
expectHandshakeErrorIncluding: "client requested unsupported application protocol",
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS12(t, test)
|
|
|
|
|
runServerTestTLS13(t, test)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestHandshakeServerALPNNotConfigured(t *testing.T) {
|
|
|
|
|
config := testConfig.Clone()
|
|
|
|
|
config.NextProtos = nil
|
|
|
|
|
|
|
|
|
|
test := &serverTest{
|
|
|
|
|
name: "ALPN-NotConfigured",
|
|
|
|
|
// Note that this needs OpenSSL 1.0.2 because that is the first
|
|
|
|
|
// version that supports the -alpn flag.
|
2020-10-15 18:32:20 -07:00
|
|
|
command: []string{"openssl", "s_client", "-alpn", "proto2,proto1", "-cipher", "ECDHE-RSA-CHACHA20-POLY1305", "-ciphersuites", "TLS_CHACHA20_POLY1305_SHA256"},
|
2016-06-21 07:00:41 -07:00
|
|
|
config: config,
|
2014-08-05 11:36:20 -07:00
|
|
|
validate: func(state ConnectionState) error {
|
|
|
|
|
if state.NegotiatedProtocol != "" {
|
2021-02-02 12:58:30 -08:00
|
|
|
return fmt.Errorf("Got protocol %q, wanted nothing", state.NegotiatedProtocol)
|
2014-08-05 11:36:20 -07:00
|
|
|
}
|
|
|
|
|
return nil
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS12(t, test)
|
2018-11-02 00:57:30 -04:00
|
|
|
runServerTestTLS13(t, test)
|
2014-08-05 11:36:20 -07:00
|
|
|
}
|
|
|
|
|
|
2021-06-07 08:24:22 -04:00
|
|
|
func TestHandshakeServerALPNFallback(t *testing.T) {
|
|
|
|
|
config := testConfig.Clone()
|
|
|
|
|
config.NextProtos = []string{"proto1", "h2", "proto2"}
|
|
|
|
|
|
|
|
|
|
test := &serverTest{
|
|
|
|
|
name: "ALPN-Fallback",
|
|
|
|
|
// Note that this needs OpenSSL 1.0.2 because that is the first
|
|
|
|
|
// version that supports the -alpn flag.
|
|
|
|
|
command: []string{"openssl", "s_client", "-alpn", "proto3,http/1.1,proto4", "-cipher", "ECDHE-RSA-CHACHA20-POLY1305", "-ciphersuites", "TLS_CHACHA20_POLY1305_SHA256"},
|
|
|
|
|
config: config,
|
|
|
|
|
validate: func(state ConnectionState) error {
|
|
|
|
|
if state.NegotiatedProtocol != "" {
|
|
|
|
|
return fmt.Errorf("Got protocol %q, wanted nothing", state.NegotiatedProtocol)
|
|
|
|
|
}
|
|
|
|
|
return nil
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS12(t, test)
|
|
|
|
|
runServerTestTLS13(t, test)
|
|
|
|
|
}
|
|
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
// TestHandshakeServerSNI involves a client sending an SNI extension of
|
|
|
|
|
// "snitest.com", which happens to match the CN of testSNICertificate. The test
|
|
|
|
|
// verifies that the server correctly selects that certificate.
|
|
|
|
|
func TestHandshakeServerSNI(t *testing.T) {
|
|
|
|
|
test := &serverTest{
|
|
|
|
|
name: "SNI",
|
|
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-cipher", "AES128-SHA", "-servername", "snitest.com"},
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS12(t, test)
|
2012-09-24 16:52:43 -04:00
|
|
|
}
|
|
|
|
|
|
2024-03-22 23:31:44 +08:00
|
|
|
// TestHandshakeServerSNIGetCertificate is similar to TestHandshakeServerSNI, but
|
2014-08-06 11:22:00 -07:00
|
|
|
// tests the dynamic GetCertificate method
|
|
|
|
|
func TestHandshakeServerSNIGetCertificate(t *testing.T) {
|
2016-08-30 03:19:01 +00:00
|
|
|
config := testConfig.Clone()
|
2014-08-06 11:22:00 -07:00
|
|
|
|
|
|
|
|
// Replace the NameToCertificate map with a GetCertificate function
|
|
|
|
|
nameToCert := config.NameToCertificate
|
|
|
|
|
config.NameToCertificate = nil
|
|
|
|
|
config.GetCertificate = func(clientHello *ClientHelloInfo) (*Certificate, error) {
|
2018-10-16 23:47:55 -04:00
|
|
|
cert := nameToCert[clientHello.ServerName]
|
2014-08-06 11:22:00 -07:00
|
|
|
return cert, nil
|
|
|
|
|
}
|
|
|
|
|
test := &serverTest{
|
2015-04-15 15:00:53 -04:00
|
|
|
name: "SNI-GetCertificate",
|
2014-08-06 11:22:00 -07:00
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-cipher", "AES128-SHA", "-servername", "snitest.com"},
|
2016-06-21 07:00:41 -07:00
|
|
|
config: config,
|
2014-08-06 11:22:00 -07:00
|
|
|
}
|
|
|
|
|
runServerTestTLS12(t, test)
|
|
|
|
|
}
|
|
|
|
|
|
2024-06-02 00:51:35 +08:00
|
|
|
// TestHandshakeServerSNIGetCertificateNotFound is similar to
|
2014-08-06 11:22:00 -07:00
|
|
|
// TestHandshakeServerSNICertForName, but tests to make sure that when the
|
|
|
|
|
// GetCertificate method doesn't return a cert, we fall back to what's in
|
|
|
|
|
// the NameToCertificate map.
|
|
|
|
|
func TestHandshakeServerSNIGetCertificateNotFound(t *testing.T) {
|
2016-08-30 03:19:01 +00:00
|
|
|
config := testConfig.Clone()
|
2014-08-06 11:22:00 -07:00
|
|
|
|
|
|
|
|
config.GetCertificate = func(clientHello *ClientHelloInfo) (*Certificate, error) {
|
|
|
|
|
return nil, nil
|
|
|
|
|
}
|
|
|
|
|
test := &serverTest{
|
2015-04-15 15:00:53 -04:00
|
|
|
name: "SNI-GetCertificateNotFound",
|
2014-08-06 11:22:00 -07:00
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-cipher", "AES128-SHA", "-servername", "snitest.com"},
|
2016-06-21 07:00:41 -07:00
|
|
|
config: config,
|
2014-08-06 11:22:00 -07:00
|
|
|
}
|
|
|
|
|
runServerTestTLS12(t, test)
|
|
|
|
|
}
|
|
|
|
|
|
2024-06-02 00:51:35 +08:00
|
|
|
// TestHandshakeServerSNIGetCertificateError tests to make sure that errors in
|
2014-08-06 11:22:00 -07:00
|
|
|
// GetCertificate result in a tls alert.
|
|
|
|
|
func TestHandshakeServerSNIGetCertificateError(t *testing.T) {
|
2015-04-15 15:00:53 -04:00
|
|
|
const errMsg = "TestHandshakeServerSNIGetCertificateError error"
|
2014-08-06 11:22:00 -07:00
|
|
|
|
2016-08-30 03:19:01 +00:00
|
|
|
serverConfig := testConfig.Clone()
|
2015-04-15 15:00:53 -04:00
|
|
|
serverConfig.GetCertificate = func(clientHello *ClientHelloInfo) (*Certificate, error) {
|
|
|
|
|
return nil, errors.New(errMsg)
|
2014-08-06 11:22:00 -07:00
|
|
|
}
|
2015-04-15 15:00:53 -04:00
|
|
|
|
|
|
|
|
clientHello := &clientHelloMsg{
|
2016-02-26 18:26:04 -05:00
|
|
|
vers: VersionTLS10,
|
2018-10-24 21:22:00 -04:00
|
|
|
random: make([]byte, 32),
|
2015-04-15 15:00:53 -04:00
|
|
|
cipherSuites: []uint16{TLS_RSA_WITH_RC4_128_SHA},
|
2016-02-26 18:26:04 -05:00
|
|
|
compressionMethods: []uint8{compressionNone},
|
2015-04-15 15:00:53 -04:00
|
|
|
serverName: "test",
|
2014-08-06 11:22:00 -07:00
|
|
|
}
|
2016-06-21 07:00:41 -07:00
|
|
|
testClientHelloFailure(t, serverConfig, clientHello, errMsg)
|
2014-08-06 11:22:00 -07:00
|
|
|
}
|
|
|
|
|
|
2015-04-12 16:41:31 -07:00
|
|
|
// TestHandshakeServerEmptyCertificates tests that GetCertificates is called in
|
|
|
|
|
// the case that Certificates is empty, even without SNI.
|
|
|
|
|
func TestHandshakeServerEmptyCertificates(t *testing.T) {
|
|
|
|
|
const errMsg = "TestHandshakeServerEmptyCertificates error"
|
|
|
|
|
|
2016-08-30 03:19:01 +00:00
|
|
|
serverConfig := testConfig.Clone()
|
2015-04-12 16:41:31 -07:00
|
|
|
serverConfig.GetCertificate = func(clientHello *ClientHelloInfo) (*Certificate, error) {
|
|
|
|
|
return nil, errors.New(errMsg)
|
|
|
|
|
}
|
|
|
|
|
serverConfig.Certificates = nil
|
|
|
|
|
|
|
|
|
|
clientHello := &clientHelloMsg{
|
2016-02-26 18:26:04 -05:00
|
|
|
vers: VersionTLS10,
|
2018-10-24 21:22:00 -04:00
|
|
|
random: make([]byte, 32),
|
2015-04-12 16:41:31 -07:00
|
|
|
cipherSuites: []uint16{TLS_RSA_WITH_RC4_128_SHA},
|
2016-02-26 18:26:04 -05:00
|
|
|
compressionMethods: []uint8{compressionNone},
|
2015-04-12 16:41:31 -07:00
|
|
|
}
|
2016-06-21 07:00:41 -07:00
|
|
|
testClientHelloFailure(t, serverConfig, clientHello, errMsg)
|
2015-04-12 16:41:31 -07:00
|
|
|
|
|
|
|
|
// With an empty Certificates and a nil GetCertificate, the server
|
|
|
|
|
// should always return a “no certificates” error.
|
|
|
|
|
serverConfig.GetCertificate = nil
|
|
|
|
|
|
|
|
|
|
clientHello = &clientHelloMsg{
|
2016-02-26 18:26:04 -05:00
|
|
|
vers: VersionTLS10,
|
2018-10-24 21:22:00 -04:00
|
|
|
random: make([]byte, 32),
|
2015-04-12 16:41:31 -07:00
|
|
|
cipherSuites: []uint16{TLS_RSA_WITH_RC4_128_SHA},
|
2016-02-26 18:26:04 -05:00
|
|
|
compressionMethods: []uint8{compressionNone},
|
2015-04-12 16:41:31 -07:00
|
|
|
}
|
2016-06-21 07:00:41 -07:00
|
|
|
testClientHelloFailure(t, serverConfig, clientHello, "no certificates")
|
2015-04-12 16:41:31 -07:00
|
|
|
}
|
|
|
|
|
|
2018-11-05 15:59:08 -05:00
|
|
|
func TestServerResumption(t *testing.T) {
|
2013-12-20 11:37:05 -05:00
|
|
|
sessionFilePath := tempFile("")
|
|
|
|
|
defer os.Remove(sessionFilePath)
|
|
|
|
|
|
2018-11-05 15:59:08 -05:00
|
|
|
testIssue := &serverTest{
|
2013-12-20 11:37:05 -05:00
|
|
|
name: "IssueTicket",
|
2020-10-15 18:32:20 -07:00
|
|
|
command: []string{"openssl", "s_client", "-cipher", "AES128-SHA", "-ciphersuites", "TLS_AES_128_GCM_SHA256", "-sess_out", sessionFilePath},
|
2018-11-01 01:01:09 -04:00
|
|
|
wait: true,
|
2013-12-20 11:37:05 -05:00
|
|
|
}
|
2018-11-05 15:59:08 -05:00
|
|
|
testResume := &serverTest{
|
2013-12-20 11:37:05 -05:00
|
|
|
name: "Resume",
|
2020-10-15 18:32:20 -07:00
|
|
|
command: []string{"openssl", "s_client", "-cipher", "AES128-SHA", "-ciphersuites", "TLS_AES_128_GCM_SHA256", "-sess_in", sessionFilePath},
|
2018-11-05 15:59:08 -05:00
|
|
|
validate: func(state ConnectionState) error {
|
|
|
|
|
if !state.DidResume {
|
|
|
|
|
return errors.New("did not resume")
|
|
|
|
|
}
|
|
|
|
|
return nil
|
|
|
|
|
},
|
2013-12-20 11:37:05 -05:00
|
|
|
}
|
2018-11-05 15:59:08 -05:00
|
|
|
|
|
|
|
|
runServerTestTLS12(t, testIssue)
|
|
|
|
|
runServerTestTLS12(t, testResume)
|
|
|
|
|
|
|
|
|
|
runServerTestTLS13(t, testIssue)
|
|
|
|
|
runServerTestTLS13(t, testResume)
|
|
|
|
|
|
|
|
|
|
config := testConfig.Clone()
|
|
|
|
|
config.CurvePreferences = []CurveID{CurveP256}
|
|
|
|
|
|
|
|
|
|
testResumeHRR := &serverTest{
|
2020-10-15 18:32:20 -07:00
|
|
|
name: "Resume-HelloRetryRequest",
|
|
|
|
|
command: []string{"openssl", "s_client", "-curves", "X25519:P-256", "-cipher", "AES128-SHA", "-ciphersuites",
|
|
|
|
|
"TLS_AES_128_GCM_SHA256", "-sess_in", sessionFilePath},
|
|
|
|
|
config: config,
|
2018-11-05 15:59:08 -05:00
|
|
|
validate: func(state ConnectionState) error {
|
|
|
|
|
if !state.DidResume {
|
|
|
|
|
return errors.New("did not resume")
|
|
|
|
|
}
|
|
|
|
|
return nil
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
runServerTestTLS13(t, testResumeHRR)
|
2013-07-02 19:58:56 -04:00
|
|
|
}
|
|
|
|
|
|
2018-11-05 15:59:08 -05:00
|
|
|
func TestServerResumptionDisabled(t *testing.T) {
|
2014-09-26 11:02:09 +10:00
|
|
|
sessionFilePath := tempFile("")
|
|
|
|
|
defer os.Remove(sessionFilePath)
|
|
|
|
|
|
2016-08-30 03:19:01 +00:00
|
|
|
config := testConfig.Clone()
|
2014-09-26 11:02:09 +10:00
|
|
|
|
2018-11-05 15:59:08 -05:00
|
|
|
testIssue := &serverTest{
|
2014-09-26 11:02:09 +10:00
|
|
|
name: "IssueTicketPreDisable",
|
2020-10-15 18:32:20 -07:00
|
|
|
command: []string{"openssl", "s_client", "-cipher", "AES128-SHA", "-ciphersuites", "TLS_AES_128_GCM_SHA256", "-sess_out", sessionFilePath},
|
2016-06-21 07:00:41 -07:00
|
|
|
config: config,
|
2018-11-01 01:01:09 -04:00
|
|
|
wait: true,
|
2014-09-26 11:02:09 +10:00
|
|
|
}
|
2018-11-05 15:59:08 -05:00
|
|
|
testResume := &serverTest{
|
2014-09-26 11:02:09 +10:00
|
|
|
name: "ResumeDisabled",
|
2020-10-15 18:32:20 -07:00
|
|
|
command: []string{"openssl", "s_client", "-cipher", "AES128-SHA", "-ciphersuites", "TLS_AES_128_GCM_SHA256", "-sess_in", sessionFilePath},
|
2016-06-21 07:00:41 -07:00
|
|
|
config: config,
|
2018-11-05 15:59:08 -05:00
|
|
|
validate: func(state ConnectionState) error {
|
|
|
|
|
if state.DidResume {
|
|
|
|
|
return errors.New("resumed with SessionTicketsDisabled")
|
|
|
|
|
}
|
|
|
|
|
return nil
|
|
|
|
|
},
|
2014-09-26 11:02:09 +10:00
|
|
|
}
|
|
|
|
|
|
2018-11-05 15:59:08 -05:00
|
|
|
config.SessionTicketsDisabled = false
|
|
|
|
|
runServerTestTLS12(t, testIssue)
|
|
|
|
|
config.SessionTicketsDisabled = true
|
|
|
|
|
runServerTestTLS12(t, testResume)
|
|
|
|
|
|
|
|
|
|
config.SessionTicketsDisabled = false
|
|
|
|
|
runServerTestTLS13(t, testIssue)
|
|
|
|
|
config.SessionTicketsDisabled = true
|
|
|
|
|
runServerTestTLS13(t, testResume)
|
2014-09-26 11:02:09 +10:00
|
|
|
}
|
|
|
|
|
|
2014-10-15 17:54:04 -07:00
|
|
|
func TestFallbackSCSV(t *testing.T) {
|
2016-06-21 07:00:41 -07:00
|
|
|
serverConfig := Config{
|
2014-12-18 10:17:54 -08:00
|
|
|
Certificates: testConfig.Certificates,
|
2023-11-10 10:12:48 -08:00
|
|
|
MinVersion: VersionTLS11,
|
2014-12-18 10:17:54 -08:00
|
|
|
}
|
2014-10-15 17:54:04 -07:00
|
|
|
test := &serverTest{
|
2014-12-18 10:17:54 -08:00
|
|
|
name: "FallbackSCSV",
|
2016-06-21 07:00:41 -07:00
|
|
|
config: &serverConfig,
|
2014-10-15 17:54:04 -07:00
|
|
|
// OpenSSL 1.0.1j is needed for the -fallback_scsv option.
|
go/printer, gofmt: tuned table alignment for better results
The go/printer (and thus gofmt) uses a heuristic to determine
whether to break alignment between elements of an expression
list which is spread across multiple lines. The heuristic only
kicked in if the entry sizes (character length) was above a
certain threshold (20) and the ratio between the previous and
current entry size was above a certain value (4).
This heuristic worked reasonably most of the time, but also
led to unfortunate breaks in many cases where a single entry
was suddenly much smaller (or larger) then the previous one.
The behavior of gofmt was sufficiently mysterious in some of
these situations that many issues were filed against it.
The simplest solution to address this problem is to remove
the heuristic altogether and have a programmer introduce
empty lines to force different alignments if it improves
readability. The problem with that approach is that the
places where it really matters, very long tables with many
(hundreds, or more) entries, may be machine-generated and
not "post-processed" by a human (e.g., unicode/utf8/tables.go).
If a single one of those entries is overlong, the result
would be that the alignment would force all comments or
values in key:value pairs to be adjusted to that overlong
value, making the table hard to read (e.g., that entry may
not even be visible on screen and all other entries seem
spaced out too wide).
Instead, we opted for a slightly improved heuristic that
behaves much better for "normal", human-written code.
1) The threshold is increased from 20 to 40. This disables
the heuristic for many common cases yet even if the alignment
is not "ideal", 40 is not that many characters per line with
todays screens, making it very likely that the entire line
remains "visible" in an editor.
2) Changed the heuristic to not simply look at the size ratio
between current and previous line, but instead considering the
geometric mean of the sizes of the previous (aligned) lines.
This emphasizes the "overall picture" of the previous lines,
rather than a single one (which might be an outlier).
3) Changed the ratio from 4 to 2.5. Now that we ignore sizes
below 40, a ratio of 4 would mean that a new entry would have
to be 4 times bigger (160) or smaller (10) before alignment
would be broken. A ratio of 2.5 seems more sensible.
Applied updated gofmt to all of src and misc. Also tested
against several former issues that complained about this
and verified that the output for the given examples is
satisfactory (added respective test cases).
Some of the files changed because they were not gofmt-ed
in the first place.
For #644.
For #7335.
For #10392.
(and probably more related issues)
Fixes #22852.
Change-Id: I5e48b3d3b157a5cf2d649833b7297b33f43a6f6e
2018-04-03 17:05:47 -07:00
|
|
|
command: []string{"openssl", "s_client", "-fallback_scsv"},
|
2015-03-06 14:59:12 +01:00
|
|
|
expectHandshakeErrorIncluding: "inappropriate protocol fallback",
|
2014-10-15 17:54:04 -07:00
|
|
|
}
|
|
|
|
|
runServerTestTLS11(t, test)
|
|
|
|
|
}
|
|
|
|
|
|
2018-08-21 14:50:04 -06:00
|
|
|
func TestHandshakeServerExportKeyingMaterial(t *testing.T) {
|
|
|
|
|
test := &serverTest{
|
|
|
|
|
name: "ExportKeyingMaterial",
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
command: []string{"openssl", "s_client", "-cipher", "ECDHE-RSA-AES256-SHA", "-ciphersuites", "TLS_CHACHA20_POLY1305_SHA256"},
|
2018-08-21 14:50:04 -06:00
|
|
|
config: testConfig.Clone(),
|
|
|
|
|
validate: func(state ConnectionState) error {
|
|
|
|
|
if km, err := state.ExportKeyingMaterial("test", nil, 42); err != nil {
|
|
|
|
|
return fmt.Errorf("ExportKeyingMaterial failed: %v", err)
|
|
|
|
|
} else if len(km) != 42 {
|
|
|
|
|
return fmt.Errorf("Got %d bytes from ExportKeyingMaterial, wanted %d", len(km), 42)
|
|
|
|
|
}
|
|
|
|
|
return nil
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS10(t, test)
|
|
|
|
|
runServerTestTLS12(t, test)
|
2018-11-02 00:57:30 -04:00
|
|
|
runServerTestTLS13(t, test)
|
2018-08-21 14:50:04 -06:00
|
|
|
}
|
|
|
|
|
|
2018-10-31 12:14:51 -04:00
|
|
|
func TestHandshakeServerRSAPKCS1v15(t *testing.T) {
|
|
|
|
|
test := &serverTest{
|
|
|
|
|
name: "RSA-RSAPKCS1v15",
|
2020-10-15 18:32:20 -07:00
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-cipher", "ECDHE-RSA-CHACHA20-POLY1305", "-sigalgs", "rsa_pkcs1_sha256"},
|
2018-10-31 12:14:51 -04:00
|
|
|
}
|
|
|
|
|
runServerTestTLS12(t, test)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestHandshakeServerRSAPSS(t *testing.T) {
|
2019-11-04 02:14:18 -05:00
|
|
|
// We send rsa_pss_rsae_sha512 first, as the test key won't fit, and we
|
|
|
|
|
// verify the server implementation will disregard the client preference in
|
|
|
|
|
// that case. See Issue 29793.
|
2018-10-31 12:14:51 -04:00
|
|
|
test := &serverTest{
|
|
|
|
|
name: "RSA-RSAPSS",
|
2020-10-15 18:32:20 -07:00
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-cipher", "ECDHE-RSA-CHACHA20-POLY1305", "-ciphersuites", "TLS_CHACHA20_POLY1305_SHA256", "-sigalgs", "rsa_pss_rsae_sha512:rsa_pss_rsae_sha256"},
|
2018-10-31 12:14:51 -04:00
|
|
|
}
|
2019-11-03 21:28:47 -05:00
|
|
|
runServerTestTLS12(t, test)
|
2018-11-02 00:57:30 -04:00
|
|
|
runServerTestTLS13(t, test)
|
2019-11-04 02:14:18 -05:00
|
|
|
|
|
|
|
|
test = &serverTest{
|
|
|
|
|
name: "RSA-RSAPSS-TooSmall",
|
2020-10-15 18:32:20 -07:00
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-ciphersuites", "TLS_CHACHA20_POLY1305_SHA256", "-sigalgs", "rsa_pss_rsae_sha512"},
|
2019-11-04 02:14:18 -05:00
|
|
|
expectHandshakeErrorIncluding: "peer doesn't support any of the certificate's signature algorithms",
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS13(t, test)
|
2018-10-31 12:14:51 -04:00
|
|
|
}
|
|
|
|
|
|
2019-05-16 19:13:29 -04:00
|
|
|
func TestHandshakeServerEd25519(t *testing.T) {
|
|
|
|
|
config := testConfig.Clone()
|
|
|
|
|
config.Certificates = make([]Certificate, 1)
|
|
|
|
|
config.Certificates[0].Certificate = [][]byte{testEd25519Certificate}
|
|
|
|
|
config.Certificates[0].PrivateKey = testEd25519PrivateKey
|
|
|
|
|
config.BuildNameToCertificate()
|
|
|
|
|
|
|
|
|
|
test := &serverTest{
|
|
|
|
|
name: "Ed25519",
|
2020-10-15 18:32:20 -07:00
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-cipher", "ECDHE-ECDSA-CHACHA20-POLY1305", "-ciphersuites", "TLS_CHACHA20_POLY1305_SHA256"},
|
2019-05-16 19:13:29 -04:00
|
|
|
config: config,
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS12(t, test)
|
|
|
|
|
runServerTestTLS13(t, test)
|
|
|
|
|
}
|
|
|
|
|
|
crypto/tls: enable TLS 1.3 and update tests
To disable TLS 1.3, simply remove VersionTLS13 from supportedVersions,
as tested by TestEscapeRoute, and amend documentation. To make it
opt-in, revert the change to (*Config).supportedVersions from this CL.
I did not have the heart to implement the early data skipping feature
when I realized that it did not offer a choice between two
abstraction-breaking options, but demanded them both (look for handshake
type in case of HelloRetryRequest, trial decryption otherwise). It's a
lot of complexity for an apparently small gain, but if anyone has strong
opinions about it let me know.
Note that in TLS 1.3 alerts are encrypted, so the close_notify peeking
to return (n > 0, io.EOF) from Read doesn't work. If we are lucky, those
servers that unexpectedly close connections after serving a single
request will have stopped (maybe thanks to H/2) before they got updated
to TLS 1.3.
Relatedly, session tickets are now provisioned on the client first Read
instead of at Handshake time, because they are, well, post-handshake
messages. If this proves to be a problem we might try to peek at them.
Doubled the tests that cover logic that's different in TLS 1.3.
The benchmarks for TLS 1.2 compared to be0f3c286b5 (before TLS 1.3 and
its refactors, after CL 142817 changed them to use real connections)
show little movement.
name old time/op new time/op delta
HandshakeServer/RSA-8 795µs ± 1% 798µs ± 1% ~ (p=0.057 n=10+18)
HandshakeServer/ECDHE-P256-RSA-8 903µs ± 0% 909µs ± 1% +0.68% (p=0.000 n=8+17)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 198µs ± 0% 204µs ± 1% +3.24% (p=0.000 n=9+18)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 202µs ± 3% 208µs ± 1% +2.98% (p=0.000 n=9+20)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.5ms ± 1% 15.9ms ± 2% +2.49% (p=0.000 n=10+20)
Throughput/MaxPacket/1MB-8 5.81ms ±23% 6.14ms ±44% ~ (p=0.605 n=8+18)
Throughput/MaxPacket/2MB-8 8.91ms ±22% 8.74ms ±33% ~ (p=0.498 n=9+19)
Throughput/MaxPacket/4MB-8 12.8ms ± 3% 14.0ms ±10% +9.74% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 25.1ms ± 7% 24.6ms ±16% ~ (p=0.129 n=9+19)
Throughput/MaxPacket/16MB-8 46.3ms ± 4% 45.9ms ±12% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 88.5ms ± 4% 86.0ms ± 4% -2.82% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 173ms ± 2% 167ms ± 7% -3.42% (p=0.001 n=10+19)
Throughput/DynamicPacket/1MB-8 5.88ms ± 4% 6.59ms ±64% ~ (p=0.232 n=9+18)
Throughput/DynamicPacket/2MB-8 9.08ms ±12% 8.73ms ±21% ~ (p=0.408 n=10+18)
Throughput/DynamicPacket/4MB-8 14.2ms ± 5% 14.0ms ±11% ~ (p=0.188 n=9+19)
Throughput/DynamicPacket/8MB-8 25.1ms ± 6% 24.0ms ± 7% -4.39% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 45.6ms ± 3% 43.3ms ± 1% -5.22% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 88.4ms ± 3% 84.8ms ± 2% -4.06% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 175ms ± 3% 167ms ± 2% -4.63% (p=0.000 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 694ms ± 0% -0.02% (p=0.000 n=9+9)
Latency/MaxPacket/500kbps-8 279ms ± 0% 279ms ± 0% -0.09% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 140ms ± 0% -0.15% (p=0.000 n=10+9)
Latency/MaxPacket/2000kbps-8 71.1ms ± 0% 71.0ms ± 0% -0.09% (p=0.001 n=8+9)
Latency/MaxPacket/5000kbps-8 30.5ms ± 6% 30.1ms ± 6% ~ (p=0.905 n=10+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 134ms ± 0% ~ (p=0.796 n=9+9)
Latency/DynamicPacket/500kbps-8 54.8ms ± 0% 54.7ms ± 0% -0.18% (p=0.000 n=8+10)
Latency/DynamicPacket/1000kbps-8 28.5ms ± 0% 29.1ms ± 8% ~ (p=0.173 n=8+10)
Latency/DynamicPacket/2000kbps-8 15.3ms ± 6% 15.9ms ±10% ~ (p=0.905 n=9+10)
Latency/DynamicPacket/5000kbps-8 9.14ms ±21% 9.65ms ±82% ~ (p=0.529 n=10+10)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 175MB/s ±13% 167MB/s ±64% ~ (p=0.646 n=7+20)
Throughput/MaxPacket/2MB-8 241MB/s ±25% 241MB/s ±40% ~ (p=0.660 n=9+20)
Throughput/MaxPacket/4MB-8 328MB/s ± 3% 300MB/s ± 9% -8.70% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 335MB/s ± 7% 340MB/s ±17% ~ (p=0.212 n=9+20)
Throughput/MaxPacket/16MB-8 363MB/s ± 4% 367MB/s ±11% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 379MB/s ± 4% 390MB/s ± 4% +2.93% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 388MB/s ± 2% 401MB/s ± 7% +3.25% (p=0.004 n=10+20)
Throughput/DynamicPacket/1MB-8 178MB/s ± 4% 157MB/s ±73% ~ (p=0.127 n=9+20)
Throughput/DynamicPacket/2MB-8 232MB/s ±11% 243MB/s ±18% ~ (p=0.415 n=10+18)
Throughput/DynamicPacket/4MB-8 296MB/s ± 5% 299MB/s ±15% ~ (p=0.295 n=9+20)
Throughput/DynamicPacket/8MB-8 334MB/s ± 6% 350MB/s ± 7% +4.58% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 368MB/s ± 3% 388MB/s ± 1% +5.48% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 380MB/s ± 3% 396MB/s ± 2% +4.20% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 384MB/s ± 3% 403MB/s ± 2% +4.83% (p=0.000 n=10+10)
Comparing TLS 1.2 and TLS 1.3 at tip shows a slight (~5-10%) slowdown of
handshakes, which might be worth looking at next cycle, but the latency
improvements are expected to overshadow that.
name old time/op new time/op delta
HandshakeServer/ECDHE-P256-RSA-8 909µs ± 1% 963µs ± 0% +5.87% (p=0.000 n=17+18)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 204µs ± 1% 225µs ± 2% +10.20% (p=0.000 n=18+20)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 208µs ± 1% 230µs ± 2% +10.35% (p=0.000 n=20+18)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.9ms ± 2% 15.9ms ± 1% ~ (p=0.444 n=20+19)
Throughput/MaxPacket/1MB-8 6.14ms ±44% 7.07ms ±46% ~ (p=0.057 n=18+19)
Throughput/MaxPacket/2MB-8 8.74ms ±33% 8.61ms ± 9% ~ (p=0.552 n=19+17)
Throughput/MaxPacket/4MB-8 14.0ms ±10% 14.1ms ±12% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 24.6ms ±16% 25.6ms ±14% ~ (p=0.107 n=19+20)
Throughput/MaxPacket/16MB-8 45.9ms ±12% 44.7ms ± 6% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 86.0ms ± 4% 87.9ms ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 167ms ± 7% 169ms ± 2% +1.26% (p=0.011 n=19+19)
Throughput/DynamicPacket/1MB-8 6.59ms ±64% 6.79ms ±43% ~ (p=0.480 n=18+19)
Throughput/DynamicPacket/2MB-8 8.73ms ±21% 9.58ms ±13% +9.71% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 14.0ms ±11% 13.9ms ±10% ~ (p=0.687 n=19+20)
Throughput/DynamicPacket/8MB-8 24.0ms ± 7% 24.6ms ± 8% +2.36% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 43.3ms ± 1% 44.3ms ± 2% +2.48% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 84.8ms ± 2% 86.7ms ± 2% +2.27% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 167ms ± 2% 170ms ± 3% +1.89% (p=0.005 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 699ms ± 0% +0.65% (p=0.000 n=9+10)
Latency/MaxPacket/500kbps-8 279ms ± 0% 280ms ± 0% +0.68% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 141ms ± 0% +0.59% (p=0.000 n=9+9)
Latency/MaxPacket/2000kbps-8 71.0ms ± 0% 71.3ms ± 0% +0.42% (p=0.000 n=9+9)
Latency/MaxPacket/5000kbps-8 30.1ms ± 6% 30.7ms ±10% +1.93% (p=0.019 n=9+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 138ms ± 0% +3.22% (p=0.000 n=9+10)
Latency/DynamicPacket/500kbps-8 54.7ms ± 0% 56.3ms ± 0% +3.03% (p=0.000 n=10+8)
Latency/DynamicPacket/1000kbps-8 29.1ms ± 8% 29.1ms ± 0% ~ (p=0.173 n=10+8)
Latency/DynamicPacket/2000kbps-8 15.9ms ±10% 16.4ms ±36% ~ (p=0.633 n=10+8)
Latency/DynamicPacket/5000kbps-8 9.65ms ±82% 8.32ms ± 8% ~ (p=0.573 n=10+8)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 167MB/s ±64% 155MB/s ±55% ~ (p=0.224 n=20+19)
Throughput/MaxPacket/2MB-8 241MB/s ±40% 244MB/s ± 9% ~ (p=0.407 n=20+17)
Throughput/MaxPacket/4MB-8 300MB/s ± 9% 298MB/s ±11% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 340MB/s ±17% 330MB/s ±13% ~ (p=0.201 n=20+20)
Throughput/MaxPacket/16MB-8 367MB/s ±11% 375MB/s ± 5% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 390MB/s ± 4% 382MB/s ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 401MB/s ± 7% 397MB/s ± 2% -0.96% (p=0.030 n=20+19)
Throughput/DynamicPacket/1MB-8 157MB/s ±73% 156MB/s ±39% ~ (p=0.738 n=20+20)
Throughput/DynamicPacket/2MB-8 243MB/s ±18% 220MB/s ±14% -9.65% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 299MB/s ±15% 303MB/s ± 9% ~ (p=0.512 n=20+20)
Throughput/DynamicPacket/8MB-8 350MB/s ± 7% 342MB/s ± 8% -2.27% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 388MB/s ± 1% 378MB/s ± 2% -2.41% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 396MB/s ± 2% 387MB/s ± 2% -2.21% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 403MB/s ± 2% 396MB/s ± 3% -1.84% (p=0.005 n=10+10)
Fixes #9671
Change-Id: Ieb57c5140eb2c083b8be0d42b240cd2eeec0dcf6
Reviewed-on: https://go-review.googlesource.com/c/147638
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2018-11-05 22:52:51 -05:00
|
|
|
func benchmarkHandshakeServer(b *testing.B, version uint16, cipherSuite uint16, curve CurveID, cert []byte, key crypto.PrivateKey) {
|
2017-06-02 12:33:50 -07:00
|
|
|
config := testConfig.Clone()
|
|
|
|
|
config.CipherSuites = []uint16{cipherSuite}
|
|
|
|
|
config.CurvePreferences = []CurveID{curve}
|
|
|
|
|
config.Certificates = make([]Certificate, 1)
|
|
|
|
|
config.Certificates[0].Certificate = [][]byte{cert}
|
|
|
|
|
config.Certificates[0].PrivateKey = key
|
|
|
|
|
config.BuildNameToCertificate()
|
|
|
|
|
|
2018-10-16 23:47:55 -04:00
|
|
|
clientConn, serverConn := localPipe(b)
|
2017-06-02 12:33:50 -07:00
|
|
|
serverConn = &recordingConn{Conn: serverConn}
|
|
|
|
|
go func() {
|
crypto/tls: enable TLS 1.3 and update tests
To disable TLS 1.3, simply remove VersionTLS13 from supportedVersions,
as tested by TestEscapeRoute, and amend documentation. To make it
opt-in, revert the change to (*Config).supportedVersions from this CL.
I did not have the heart to implement the early data skipping feature
when I realized that it did not offer a choice between two
abstraction-breaking options, but demanded them both (look for handshake
type in case of HelloRetryRequest, trial decryption otherwise). It's a
lot of complexity for an apparently small gain, but if anyone has strong
opinions about it let me know.
Note that in TLS 1.3 alerts are encrypted, so the close_notify peeking
to return (n > 0, io.EOF) from Read doesn't work. If we are lucky, those
servers that unexpectedly close connections after serving a single
request will have stopped (maybe thanks to H/2) before they got updated
to TLS 1.3.
Relatedly, session tickets are now provisioned on the client first Read
instead of at Handshake time, because they are, well, post-handshake
messages. If this proves to be a problem we might try to peek at them.
Doubled the tests that cover logic that's different in TLS 1.3.
The benchmarks for TLS 1.2 compared to be0f3c286b5 (before TLS 1.3 and
its refactors, after CL 142817 changed them to use real connections)
show little movement.
name old time/op new time/op delta
HandshakeServer/RSA-8 795µs ± 1% 798µs ± 1% ~ (p=0.057 n=10+18)
HandshakeServer/ECDHE-P256-RSA-8 903µs ± 0% 909µs ± 1% +0.68% (p=0.000 n=8+17)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 198µs ± 0% 204µs ± 1% +3.24% (p=0.000 n=9+18)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 202µs ± 3% 208µs ± 1% +2.98% (p=0.000 n=9+20)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.5ms ± 1% 15.9ms ± 2% +2.49% (p=0.000 n=10+20)
Throughput/MaxPacket/1MB-8 5.81ms ±23% 6.14ms ±44% ~ (p=0.605 n=8+18)
Throughput/MaxPacket/2MB-8 8.91ms ±22% 8.74ms ±33% ~ (p=0.498 n=9+19)
Throughput/MaxPacket/4MB-8 12.8ms ± 3% 14.0ms ±10% +9.74% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 25.1ms ± 7% 24.6ms ±16% ~ (p=0.129 n=9+19)
Throughput/MaxPacket/16MB-8 46.3ms ± 4% 45.9ms ±12% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 88.5ms ± 4% 86.0ms ± 4% -2.82% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 173ms ± 2% 167ms ± 7% -3.42% (p=0.001 n=10+19)
Throughput/DynamicPacket/1MB-8 5.88ms ± 4% 6.59ms ±64% ~ (p=0.232 n=9+18)
Throughput/DynamicPacket/2MB-8 9.08ms ±12% 8.73ms ±21% ~ (p=0.408 n=10+18)
Throughput/DynamicPacket/4MB-8 14.2ms ± 5% 14.0ms ±11% ~ (p=0.188 n=9+19)
Throughput/DynamicPacket/8MB-8 25.1ms ± 6% 24.0ms ± 7% -4.39% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 45.6ms ± 3% 43.3ms ± 1% -5.22% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 88.4ms ± 3% 84.8ms ± 2% -4.06% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 175ms ± 3% 167ms ± 2% -4.63% (p=0.000 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 694ms ± 0% -0.02% (p=0.000 n=9+9)
Latency/MaxPacket/500kbps-8 279ms ± 0% 279ms ± 0% -0.09% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 140ms ± 0% -0.15% (p=0.000 n=10+9)
Latency/MaxPacket/2000kbps-8 71.1ms ± 0% 71.0ms ± 0% -0.09% (p=0.001 n=8+9)
Latency/MaxPacket/5000kbps-8 30.5ms ± 6% 30.1ms ± 6% ~ (p=0.905 n=10+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 134ms ± 0% ~ (p=0.796 n=9+9)
Latency/DynamicPacket/500kbps-8 54.8ms ± 0% 54.7ms ± 0% -0.18% (p=0.000 n=8+10)
Latency/DynamicPacket/1000kbps-8 28.5ms ± 0% 29.1ms ± 8% ~ (p=0.173 n=8+10)
Latency/DynamicPacket/2000kbps-8 15.3ms ± 6% 15.9ms ±10% ~ (p=0.905 n=9+10)
Latency/DynamicPacket/5000kbps-8 9.14ms ±21% 9.65ms ±82% ~ (p=0.529 n=10+10)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 175MB/s ±13% 167MB/s ±64% ~ (p=0.646 n=7+20)
Throughput/MaxPacket/2MB-8 241MB/s ±25% 241MB/s ±40% ~ (p=0.660 n=9+20)
Throughput/MaxPacket/4MB-8 328MB/s ± 3% 300MB/s ± 9% -8.70% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 335MB/s ± 7% 340MB/s ±17% ~ (p=0.212 n=9+20)
Throughput/MaxPacket/16MB-8 363MB/s ± 4% 367MB/s ±11% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 379MB/s ± 4% 390MB/s ± 4% +2.93% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 388MB/s ± 2% 401MB/s ± 7% +3.25% (p=0.004 n=10+20)
Throughput/DynamicPacket/1MB-8 178MB/s ± 4% 157MB/s ±73% ~ (p=0.127 n=9+20)
Throughput/DynamicPacket/2MB-8 232MB/s ±11% 243MB/s ±18% ~ (p=0.415 n=10+18)
Throughput/DynamicPacket/4MB-8 296MB/s ± 5% 299MB/s ±15% ~ (p=0.295 n=9+20)
Throughput/DynamicPacket/8MB-8 334MB/s ± 6% 350MB/s ± 7% +4.58% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 368MB/s ± 3% 388MB/s ± 1% +5.48% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 380MB/s ± 3% 396MB/s ± 2% +4.20% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 384MB/s ± 3% 403MB/s ± 2% +4.83% (p=0.000 n=10+10)
Comparing TLS 1.2 and TLS 1.3 at tip shows a slight (~5-10%) slowdown of
handshakes, which might be worth looking at next cycle, but the latency
improvements are expected to overshadow that.
name old time/op new time/op delta
HandshakeServer/ECDHE-P256-RSA-8 909µs ± 1% 963µs ± 0% +5.87% (p=0.000 n=17+18)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 204µs ± 1% 225µs ± 2% +10.20% (p=0.000 n=18+20)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 208µs ± 1% 230µs ± 2% +10.35% (p=0.000 n=20+18)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.9ms ± 2% 15.9ms ± 1% ~ (p=0.444 n=20+19)
Throughput/MaxPacket/1MB-8 6.14ms ±44% 7.07ms ±46% ~ (p=0.057 n=18+19)
Throughput/MaxPacket/2MB-8 8.74ms ±33% 8.61ms ± 9% ~ (p=0.552 n=19+17)
Throughput/MaxPacket/4MB-8 14.0ms ±10% 14.1ms ±12% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 24.6ms ±16% 25.6ms ±14% ~ (p=0.107 n=19+20)
Throughput/MaxPacket/16MB-8 45.9ms ±12% 44.7ms ± 6% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 86.0ms ± 4% 87.9ms ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 167ms ± 7% 169ms ± 2% +1.26% (p=0.011 n=19+19)
Throughput/DynamicPacket/1MB-8 6.59ms ±64% 6.79ms ±43% ~ (p=0.480 n=18+19)
Throughput/DynamicPacket/2MB-8 8.73ms ±21% 9.58ms ±13% +9.71% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 14.0ms ±11% 13.9ms ±10% ~ (p=0.687 n=19+20)
Throughput/DynamicPacket/8MB-8 24.0ms ± 7% 24.6ms ± 8% +2.36% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 43.3ms ± 1% 44.3ms ± 2% +2.48% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 84.8ms ± 2% 86.7ms ± 2% +2.27% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 167ms ± 2% 170ms ± 3% +1.89% (p=0.005 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 699ms ± 0% +0.65% (p=0.000 n=9+10)
Latency/MaxPacket/500kbps-8 279ms ± 0% 280ms ± 0% +0.68% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 141ms ± 0% +0.59% (p=0.000 n=9+9)
Latency/MaxPacket/2000kbps-8 71.0ms ± 0% 71.3ms ± 0% +0.42% (p=0.000 n=9+9)
Latency/MaxPacket/5000kbps-8 30.1ms ± 6% 30.7ms ±10% +1.93% (p=0.019 n=9+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 138ms ± 0% +3.22% (p=0.000 n=9+10)
Latency/DynamicPacket/500kbps-8 54.7ms ± 0% 56.3ms ± 0% +3.03% (p=0.000 n=10+8)
Latency/DynamicPacket/1000kbps-8 29.1ms ± 8% 29.1ms ± 0% ~ (p=0.173 n=10+8)
Latency/DynamicPacket/2000kbps-8 15.9ms ±10% 16.4ms ±36% ~ (p=0.633 n=10+8)
Latency/DynamicPacket/5000kbps-8 9.65ms ±82% 8.32ms ± 8% ~ (p=0.573 n=10+8)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 167MB/s ±64% 155MB/s ±55% ~ (p=0.224 n=20+19)
Throughput/MaxPacket/2MB-8 241MB/s ±40% 244MB/s ± 9% ~ (p=0.407 n=20+17)
Throughput/MaxPacket/4MB-8 300MB/s ± 9% 298MB/s ±11% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 340MB/s ±17% 330MB/s ±13% ~ (p=0.201 n=20+20)
Throughput/MaxPacket/16MB-8 367MB/s ±11% 375MB/s ± 5% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 390MB/s ± 4% 382MB/s ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 401MB/s ± 7% 397MB/s ± 2% -0.96% (p=0.030 n=20+19)
Throughput/DynamicPacket/1MB-8 157MB/s ±73% 156MB/s ±39% ~ (p=0.738 n=20+20)
Throughput/DynamicPacket/2MB-8 243MB/s ±18% 220MB/s ±14% -9.65% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 299MB/s ±15% 303MB/s ± 9% ~ (p=0.512 n=20+20)
Throughput/DynamicPacket/8MB-8 350MB/s ± 7% 342MB/s ± 8% -2.27% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 388MB/s ± 1% 378MB/s ± 2% -2.41% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 396MB/s ± 2% 387MB/s ± 2% -2.21% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 403MB/s ± 2% 396MB/s ± 3% -1.84% (p=0.005 n=10+10)
Fixes #9671
Change-Id: Ieb57c5140eb2c083b8be0d42b240cd2eeec0dcf6
Reviewed-on: https://go-review.googlesource.com/c/147638
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2018-11-05 22:52:51 -05:00
|
|
|
config := testConfig.Clone()
|
|
|
|
|
config.MaxVersion = version
|
|
|
|
|
config.CurvePreferences = []CurveID{curve}
|
|
|
|
|
client := Client(clientConn, config)
|
2017-06-02 12:33:50 -07:00
|
|
|
client.Handshake()
|
|
|
|
|
}()
|
|
|
|
|
server := Server(serverConn, config)
|
|
|
|
|
if err := server.Handshake(); err != nil {
|
|
|
|
|
b.Fatalf("handshake failed: %v", err)
|
|
|
|
|
}
|
|
|
|
|
serverConn.Close()
|
|
|
|
|
flows := serverConn.(*recordingConn).flows
|
|
|
|
|
|
|
|
|
|
b.ResetTimer()
|
|
|
|
|
for i := 0; i < b.N; i++ {
|
2024-06-23 14:10:14 +02:00
|
|
|
replay := &replayingConn{t: b, flows: slices.Clone(flows), reading: true}
|
|
|
|
|
server := Server(replay, config)
|
2017-06-02 12:33:50 -07:00
|
|
|
if err := server.Handshake(); err != nil {
|
|
|
|
|
b.Fatalf("handshake failed: %v", err)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func BenchmarkHandshakeServer(b *testing.B) {
|
|
|
|
|
b.Run("RSA", func(b *testing.B) {
|
crypto/tls: enable TLS 1.3 and update tests
To disable TLS 1.3, simply remove VersionTLS13 from supportedVersions,
as tested by TestEscapeRoute, and amend documentation. To make it
opt-in, revert the change to (*Config).supportedVersions from this CL.
I did not have the heart to implement the early data skipping feature
when I realized that it did not offer a choice between two
abstraction-breaking options, but demanded them both (look for handshake
type in case of HelloRetryRequest, trial decryption otherwise). It's a
lot of complexity for an apparently small gain, but if anyone has strong
opinions about it let me know.
Note that in TLS 1.3 alerts are encrypted, so the close_notify peeking
to return (n > 0, io.EOF) from Read doesn't work. If we are lucky, those
servers that unexpectedly close connections after serving a single
request will have stopped (maybe thanks to H/2) before they got updated
to TLS 1.3.
Relatedly, session tickets are now provisioned on the client first Read
instead of at Handshake time, because they are, well, post-handshake
messages. If this proves to be a problem we might try to peek at them.
Doubled the tests that cover logic that's different in TLS 1.3.
The benchmarks for TLS 1.2 compared to be0f3c286b5 (before TLS 1.3 and
its refactors, after CL 142817 changed them to use real connections)
show little movement.
name old time/op new time/op delta
HandshakeServer/RSA-8 795µs ± 1% 798µs ± 1% ~ (p=0.057 n=10+18)
HandshakeServer/ECDHE-P256-RSA-8 903µs ± 0% 909µs ± 1% +0.68% (p=0.000 n=8+17)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 198µs ± 0% 204µs ± 1% +3.24% (p=0.000 n=9+18)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 202µs ± 3% 208µs ± 1% +2.98% (p=0.000 n=9+20)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.5ms ± 1% 15.9ms ± 2% +2.49% (p=0.000 n=10+20)
Throughput/MaxPacket/1MB-8 5.81ms ±23% 6.14ms ±44% ~ (p=0.605 n=8+18)
Throughput/MaxPacket/2MB-8 8.91ms ±22% 8.74ms ±33% ~ (p=0.498 n=9+19)
Throughput/MaxPacket/4MB-8 12.8ms ± 3% 14.0ms ±10% +9.74% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 25.1ms ± 7% 24.6ms ±16% ~ (p=0.129 n=9+19)
Throughput/MaxPacket/16MB-8 46.3ms ± 4% 45.9ms ±12% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 88.5ms ± 4% 86.0ms ± 4% -2.82% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 173ms ± 2% 167ms ± 7% -3.42% (p=0.001 n=10+19)
Throughput/DynamicPacket/1MB-8 5.88ms ± 4% 6.59ms ±64% ~ (p=0.232 n=9+18)
Throughput/DynamicPacket/2MB-8 9.08ms ±12% 8.73ms ±21% ~ (p=0.408 n=10+18)
Throughput/DynamicPacket/4MB-8 14.2ms ± 5% 14.0ms ±11% ~ (p=0.188 n=9+19)
Throughput/DynamicPacket/8MB-8 25.1ms ± 6% 24.0ms ± 7% -4.39% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 45.6ms ± 3% 43.3ms ± 1% -5.22% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 88.4ms ± 3% 84.8ms ± 2% -4.06% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 175ms ± 3% 167ms ± 2% -4.63% (p=0.000 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 694ms ± 0% -0.02% (p=0.000 n=9+9)
Latency/MaxPacket/500kbps-8 279ms ± 0% 279ms ± 0% -0.09% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 140ms ± 0% -0.15% (p=0.000 n=10+9)
Latency/MaxPacket/2000kbps-8 71.1ms ± 0% 71.0ms ± 0% -0.09% (p=0.001 n=8+9)
Latency/MaxPacket/5000kbps-8 30.5ms ± 6% 30.1ms ± 6% ~ (p=0.905 n=10+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 134ms ± 0% ~ (p=0.796 n=9+9)
Latency/DynamicPacket/500kbps-8 54.8ms ± 0% 54.7ms ± 0% -0.18% (p=0.000 n=8+10)
Latency/DynamicPacket/1000kbps-8 28.5ms ± 0% 29.1ms ± 8% ~ (p=0.173 n=8+10)
Latency/DynamicPacket/2000kbps-8 15.3ms ± 6% 15.9ms ±10% ~ (p=0.905 n=9+10)
Latency/DynamicPacket/5000kbps-8 9.14ms ±21% 9.65ms ±82% ~ (p=0.529 n=10+10)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 175MB/s ±13% 167MB/s ±64% ~ (p=0.646 n=7+20)
Throughput/MaxPacket/2MB-8 241MB/s ±25% 241MB/s ±40% ~ (p=0.660 n=9+20)
Throughput/MaxPacket/4MB-8 328MB/s ± 3% 300MB/s ± 9% -8.70% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 335MB/s ± 7% 340MB/s ±17% ~ (p=0.212 n=9+20)
Throughput/MaxPacket/16MB-8 363MB/s ± 4% 367MB/s ±11% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 379MB/s ± 4% 390MB/s ± 4% +2.93% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 388MB/s ± 2% 401MB/s ± 7% +3.25% (p=0.004 n=10+20)
Throughput/DynamicPacket/1MB-8 178MB/s ± 4% 157MB/s ±73% ~ (p=0.127 n=9+20)
Throughput/DynamicPacket/2MB-8 232MB/s ±11% 243MB/s ±18% ~ (p=0.415 n=10+18)
Throughput/DynamicPacket/4MB-8 296MB/s ± 5% 299MB/s ±15% ~ (p=0.295 n=9+20)
Throughput/DynamicPacket/8MB-8 334MB/s ± 6% 350MB/s ± 7% +4.58% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 368MB/s ± 3% 388MB/s ± 1% +5.48% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 380MB/s ± 3% 396MB/s ± 2% +4.20% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 384MB/s ± 3% 403MB/s ± 2% +4.83% (p=0.000 n=10+10)
Comparing TLS 1.2 and TLS 1.3 at tip shows a slight (~5-10%) slowdown of
handshakes, which might be worth looking at next cycle, but the latency
improvements are expected to overshadow that.
name old time/op new time/op delta
HandshakeServer/ECDHE-P256-RSA-8 909µs ± 1% 963µs ± 0% +5.87% (p=0.000 n=17+18)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 204µs ± 1% 225µs ± 2% +10.20% (p=0.000 n=18+20)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 208µs ± 1% 230µs ± 2% +10.35% (p=0.000 n=20+18)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.9ms ± 2% 15.9ms ± 1% ~ (p=0.444 n=20+19)
Throughput/MaxPacket/1MB-8 6.14ms ±44% 7.07ms ±46% ~ (p=0.057 n=18+19)
Throughput/MaxPacket/2MB-8 8.74ms ±33% 8.61ms ± 9% ~ (p=0.552 n=19+17)
Throughput/MaxPacket/4MB-8 14.0ms ±10% 14.1ms ±12% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 24.6ms ±16% 25.6ms ±14% ~ (p=0.107 n=19+20)
Throughput/MaxPacket/16MB-8 45.9ms ±12% 44.7ms ± 6% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 86.0ms ± 4% 87.9ms ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 167ms ± 7% 169ms ± 2% +1.26% (p=0.011 n=19+19)
Throughput/DynamicPacket/1MB-8 6.59ms ±64% 6.79ms ±43% ~ (p=0.480 n=18+19)
Throughput/DynamicPacket/2MB-8 8.73ms ±21% 9.58ms ±13% +9.71% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 14.0ms ±11% 13.9ms ±10% ~ (p=0.687 n=19+20)
Throughput/DynamicPacket/8MB-8 24.0ms ± 7% 24.6ms ± 8% +2.36% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 43.3ms ± 1% 44.3ms ± 2% +2.48% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 84.8ms ± 2% 86.7ms ± 2% +2.27% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 167ms ± 2% 170ms ± 3% +1.89% (p=0.005 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 699ms ± 0% +0.65% (p=0.000 n=9+10)
Latency/MaxPacket/500kbps-8 279ms ± 0% 280ms ± 0% +0.68% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 141ms ± 0% +0.59% (p=0.000 n=9+9)
Latency/MaxPacket/2000kbps-8 71.0ms ± 0% 71.3ms ± 0% +0.42% (p=0.000 n=9+9)
Latency/MaxPacket/5000kbps-8 30.1ms ± 6% 30.7ms ±10% +1.93% (p=0.019 n=9+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 138ms ± 0% +3.22% (p=0.000 n=9+10)
Latency/DynamicPacket/500kbps-8 54.7ms ± 0% 56.3ms ± 0% +3.03% (p=0.000 n=10+8)
Latency/DynamicPacket/1000kbps-8 29.1ms ± 8% 29.1ms ± 0% ~ (p=0.173 n=10+8)
Latency/DynamicPacket/2000kbps-8 15.9ms ±10% 16.4ms ±36% ~ (p=0.633 n=10+8)
Latency/DynamicPacket/5000kbps-8 9.65ms ±82% 8.32ms ± 8% ~ (p=0.573 n=10+8)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 167MB/s ±64% 155MB/s ±55% ~ (p=0.224 n=20+19)
Throughput/MaxPacket/2MB-8 241MB/s ±40% 244MB/s ± 9% ~ (p=0.407 n=20+17)
Throughput/MaxPacket/4MB-8 300MB/s ± 9% 298MB/s ±11% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 340MB/s ±17% 330MB/s ±13% ~ (p=0.201 n=20+20)
Throughput/MaxPacket/16MB-8 367MB/s ±11% 375MB/s ± 5% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 390MB/s ± 4% 382MB/s ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 401MB/s ± 7% 397MB/s ± 2% -0.96% (p=0.030 n=20+19)
Throughput/DynamicPacket/1MB-8 157MB/s ±73% 156MB/s ±39% ~ (p=0.738 n=20+20)
Throughput/DynamicPacket/2MB-8 243MB/s ±18% 220MB/s ±14% -9.65% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 299MB/s ±15% 303MB/s ± 9% ~ (p=0.512 n=20+20)
Throughput/DynamicPacket/8MB-8 350MB/s ± 7% 342MB/s ± 8% -2.27% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 388MB/s ± 1% 378MB/s ± 2% -2.41% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 396MB/s ± 2% 387MB/s ± 2% -2.21% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 403MB/s ± 2% 396MB/s ± 3% -1.84% (p=0.005 n=10+10)
Fixes #9671
Change-Id: Ieb57c5140eb2c083b8be0d42b240cd2eeec0dcf6
Reviewed-on: https://go-review.googlesource.com/c/147638
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2018-11-05 22:52:51 -05:00
|
|
|
benchmarkHandshakeServer(b, VersionTLS12, TLS_RSA_WITH_AES_128_GCM_SHA256,
|
2017-06-02 12:33:50 -07:00
|
|
|
0, testRSACertificate, testRSAPrivateKey)
|
|
|
|
|
})
|
|
|
|
|
b.Run("ECDHE-P256-RSA", func(b *testing.B) {
|
crypto/tls: enable TLS 1.3 and update tests
To disable TLS 1.3, simply remove VersionTLS13 from supportedVersions,
as tested by TestEscapeRoute, and amend documentation. To make it
opt-in, revert the change to (*Config).supportedVersions from this CL.
I did not have the heart to implement the early data skipping feature
when I realized that it did not offer a choice between two
abstraction-breaking options, but demanded them both (look for handshake
type in case of HelloRetryRequest, trial decryption otherwise). It's a
lot of complexity for an apparently small gain, but if anyone has strong
opinions about it let me know.
Note that in TLS 1.3 alerts are encrypted, so the close_notify peeking
to return (n > 0, io.EOF) from Read doesn't work. If we are lucky, those
servers that unexpectedly close connections after serving a single
request will have stopped (maybe thanks to H/2) before they got updated
to TLS 1.3.
Relatedly, session tickets are now provisioned on the client first Read
instead of at Handshake time, because they are, well, post-handshake
messages. If this proves to be a problem we might try to peek at them.
Doubled the tests that cover logic that's different in TLS 1.3.
The benchmarks for TLS 1.2 compared to be0f3c286b5 (before TLS 1.3 and
its refactors, after CL 142817 changed them to use real connections)
show little movement.
name old time/op new time/op delta
HandshakeServer/RSA-8 795µs ± 1% 798µs ± 1% ~ (p=0.057 n=10+18)
HandshakeServer/ECDHE-P256-RSA-8 903µs ± 0% 909µs ± 1% +0.68% (p=0.000 n=8+17)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 198µs ± 0% 204µs ± 1% +3.24% (p=0.000 n=9+18)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 202µs ± 3% 208µs ± 1% +2.98% (p=0.000 n=9+20)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.5ms ± 1% 15.9ms ± 2% +2.49% (p=0.000 n=10+20)
Throughput/MaxPacket/1MB-8 5.81ms ±23% 6.14ms ±44% ~ (p=0.605 n=8+18)
Throughput/MaxPacket/2MB-8 8.91ms ±22% 8.74ms ±33% ~ (p=0.498 n=9+19)
Throughput/MaxPacket/4MB-8 12.8ms ± 3% 14.0ms ±10% +9.74% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 25.1ms ± 7% 24.6ms ±16% ~ (p=0.129 n=9+19)
Throughput/MaxPacket/16MB-8 46.3ms ± 4% 45.9ms ±12% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 88.5ms ± 4% 86.0ms ± 4% -2.82% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 173ms ± 2% 167ms ± 7% -3.42% (p=0.001 n=10+19)
Throughput/DynamicPacket/1MB-8 5.88ms ± 4% 6.59ms ±64% ~ (p=0.232 n=9+18)
Throughput/DynamicPacket/2MB-8 9.08ms ±12% 8.73ms ±21% ~ (p=0.408 n=10+18)
Throughput/DynamicPacket/4MB-8 14.2ms ± 5% 14.0ms ±11% ~ (p=0.188 n=9+19)
Throughput/DynamicPacket/8MB-8 25.1ms ± 6% 24.0ms ± 7% -4.39% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 45.6ms ± 3% 43.3ms ± 1% -5.22% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 88.4ms ± 3% 84.8ms ± 2% -4.06% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 175ms ± 3% 167ms ± 2% -4.63% (p=0.000 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 694ms ± 0% -0.02% (p=0.000 n=9+9)
Latency/MaxPacket/500kbps-8 279ms ± 0% 279ms ± 0% -0.09% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 140ms ± 0% -0.15% (p=0.000 n=10+9)
Latency/MaxPacket/2000kbps-8 71.1ms ± 0% 71.0ms ± 0% -0.09% (p=0.001 n=8+9)
Latency/MaxPacket/5000kbps-8 30.5ms ± 6% 30.1ms ± 6% ~ (p=0.905 n=10+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 134ms ± 0% ~ (p=0.796 n=9+9)
Latency/DynamicPacket/500kbps-8 54.8ms ± 0% 54.7ms ± 0% -0.18% (p=0.000 n=8+10)
Latency/DynamicPacket/1000kbps-8 28.5ms ± 0% 29.1ms ± 8% ~ (p=0.173 n=8+10)
Latency/DynamicPacket/2000kbps-8 15.3ms ± 6% 15.9ms ±10% ~ (p=0.905 n=9+10)
Latency/DynamicPacket/5000kbps-8 9.14ms ±21% 9.65ms ±82% ~ (p=0.529 n=10+10)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 175MB/s ±13% 167MB/s ±64% ~ (p=0.646 n=7+20)
Throughput/MaxPacket/2MB-8 241MB/s ±25% 241MB/s ±40% ~ (p=0.660 n=9+20)
Throughput/MaxPacket/4MB-8 328MB/s ± 3% 300MB/s ± 9% -8.70% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 335MB/s ± 7% 340MB/s ±17% ~ (p=0.212 n=9+20)
Throughput/MaxPacket/16MB-8 363MB/s ± 4% 367MB/s ±11% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 379MB/s ± 4% 390MB/s ± 4% +2.93% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 388MB/s ± 2% 401MB/s ± 7% +3.25% (p=0.004 n=10+20)
Throughput/DynamicPacket/1MB-8 178MB/s ± 4% 157MB/s ±73% ~ (p=0.127 n=9+20)
Throughput/DynamicPacket/2MB-8 232MB/s ±11% 243MB/s ±18% ~ (p=0.415 n=10+18)
Throughput/DynamicPacket/4MB-8 296MB/s ± 5% 299MB/s ±15% ~ (p=0.295 n=9+20)
Throughput/DynamicPacket/8MB-8 334MB/s ± 6% 350MB/s ± 7% +4.58% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 368MB/s ± 3% 388MB/s ± 1% +5.48% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 380MB/s ± 3% 396MB/s ± 2% +4.20% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 384MB/s ± 3% 403MB/s ± 2% +4.83% (p=0.000 n=10+10)
Comparing TLS 1.2 and TLS 1.3 at tip shows a slight (~5-10%) slowdown of
handshakes, which might be worth looking at next cycle, but the latency
improvements are expected to overshadow that.
name old time/op new time/op delta
HandshakeServer/ECDHE-P256-RSA-8 909µs ± 1% 963µs ± 0% +5.87% (p=0.000 n=17+18)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 204µs ± 1% 225µs ± 2% +10.20% (p=0.000 n=18+20)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 208µs ± 1% 230µs ± 2% +10.35% (p=0.000 n=20+18)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.9ms ± 2% 15.9ms ± 1% ~ (p=0.444 n=20+19)
Throughput/MaxPacket/1MB-8 6.14ms ±44% 7.07ms ±46% ~ (p=0.057 n=18+19)
Throughput/MaxPacket/2MB-8 8.74ms ±33% 8.61ms ± 9% ~ (p=0.552 n=19+17)
Throughput/MaxPacket/4MB-8 14.0ms ±10% 14.1ms ±12% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 24.6ms ±16% 25.6ms ±14% ~ (p=0.107 n=19+20)
Throughput/MaxPacket/16MB-8 45.9ms ±12% 44.7ms ± 6% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 86.0ms ± 4% 87.9ms ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 167ms ± 7% 169ms ± 2% +1.26% (p=0.011 n=19+19)
Throughput/DynamicPacket/1MB-8 6.59ms ±64% 6.79ms ±43% ~ (p=0.480 n=18+19)
Throughput/DynamicPacket/2MB-8 8.73ms ±21% 9.58ms ±13% +9.71% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 14.0ms ±11% 13.9ms ±10% ~ (p=0.687 n=19+20)
Throughput/DynamicPacket/8MB-8 24.0ms ± 7% 24.6ms ± 8% +2.36% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 43.3ms ± 1% 44.3ms ± 2% +2.48% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 84.8ms ± 2% 86.7ms ± 2% +2.27% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 167ms ± 2% 170ms ± 3% +1.89% (p=0.005 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 699ms ± 0% +0.65% (p=0.000 n=9+10)
Latency/MaxPacket/500kbps-8 279ms ± 0% 280ms ± 0% +0.68% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 141ms ± 0% +0.59% (p=0.000 n=9+9)
Latency/MaxPacket/2000kbps-8 71.0ms ± 0% 71.3ms ± 0% +0.42% (p=0.000 n=9+9)
Latency/MaxPacket/5000kbps-8 30.1ms ± 6% 30.7ms ±10% +1.93% (p=0.019 n=9+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 138ms ± 0% +3.22% (p=0.000 n=9+10)
Latency/DynamicPacket/500kbps-8 54.7ms ± 0% 56.3ms ± 0% +3.03% (p=0.000 n=10+8)
Latency/DynamicPacket/1000kbps-8 29.1ms ± 8% 29.1ms ± 0% ~ (p=0.173 n=10+8)
Latency/DynamicPacket/2000kbps-8 15.9ms ±10% 16.4ms ±36% ~ (p=0.633 n=10+8)
Latency/DynamicPacket/5000kbps-8 9.65ms ±82% 8.32ms ± 8% ~ (p=0.573 n=10+8)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 167MB/s ±64% 155MB/s ±55% ~ (p=0.224 n=20+19)
Throughput/MaxPacket/2MB-8 241MB/s ±40% 244MB/s ± 9% ~ (p=0.407 n=20+17)
Throughput/MaxPacket/4MB-8 300MB/s ± 9% 298MB/s ±11% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 340MB/s ±17% 330MB/s ±13% ~ (p=0.201 n=20+20)
Throughput/MaxPacket/16MB-8 367MB/s ±11% 375MB/s ± 5% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 390MB/s ± 4% 382MB/s ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 401MB/s ± 7% 397MB/s ± 2% -0.96% (p=0.030 n=20+19)
Throughput/DynamicPacket/1MB-8 157MB/s ±73% 156MB/s ±39% ~ (p=0.738 n=20+20)
Throughput/DynamicPacket/2MB-8 243MB/s ±18% 220MB/s ±14% -9.65% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 299MB/s ±15% 303MB/s ± 9% ~ (p=0.512 n=20+20)
Throughput/DynamicPacket/8MB-8 350MB/s ± 7% 342MB/s ± 8% -2.27% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 388MB/s ± 1% 378MB/s ± 2% -2.41% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 396MB/s ± 2% 387MB/s ± 2% -2.21% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 403MB/s ± 2% 396MB/s ± 3% -1.84% (p=0.005 n=10+10)
Fixes #9671
Change-Id: Ieb57c5140eb2c083b8be0d42b240cd2eeec0dcf6
Reviewed-on: https://go-review.googlesource.com/c/147638
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2018-11-05 22:52:51 -05:00
|
|
|
b.Run("TLSv13", func(b *testing.B) {
|
|
|
|
|
benchmarkHandshakeServer(b, VersionTLS13, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
|
|
|
|
|
CurveP256, testRSACertificate, testRSAPrivateKey)
|
|
|
|
|
})
|
|
|
|
|
b.Run("TLSv12", func(b *testing.B) {
|
|
|
|
|
benchmarkHandshakeServer(b, VersionTLS12, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
|
|
|
|
|
CurveP256, testRSACertificate, testRSAPrivateKey)
|
|
|
|
|
})
|
2017-06-02 12:33:50 -07:00
|
|
|
})
|
|
|
|
|
b.Run("ECDHE-P256-ECDSA-P256", func(b *testing.B) {
|
crypto/tls: enable TLS 1.3 and update tests
To disable TLS 1.3, simply remove VersionTLS13 from supportedVersions,
as tested by TestEscapeRoute, and amend documentation. To make it
opt-in, revert the change to (*Config).supportedVersions from this CL.
I did not have the heart to implement the early data skipping feature
when I realized that it did not offer a choice between two
abstraction-breaking options, but demanded them both (look for handshake
type in case of HelloRetryRequest, trial decryption otherwise). It's a
lot of complexity for an apparently small gain, but if anyone has strong
opinions about it let me know.
Note that in TLS 1.3 alerts are encrypted, so the close_notify peeking
to return (n > 0, io.EOF) from Read doesn't work. If we are lucky, those
servers that unexpectedly close connections after serving a single
request will have stopped (maybe thanks to H/2) before they got updated
to TLS 1.3.
Relatedly, session tickets are now provisioned on the client first Read
instead of at Handshake time, because they are, well, post-handshake
messages. If this proves to be a problem we might try to peek at them.
Doubled the tests that cover logic that's different in TLS 1.3.
The benchmarks for TLS 1.2 compared to be0f3c286b5 (before TLS 1.3 and
its refactors, after CL 142817 changed them to use real connections)
show little movement.
name old time/op new time/op delta
HandshakeServer/RSA-8 795µs ± 1% 798µs ± 1% ~ (p=0.057 n=10+18)
HandshakeServer/ECDHE-P256-RSA-8 903µs ± 0% 909µs ± 1% +0.68% (p=0.000 n=8+17)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 198µs ± 0% 204µs ± 1% +3.24% (p=0.000 n=9+18)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 202µs ± 3% 208µs ± 1% +2.98% (p=0.000 n=9+20)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.5ms ± 1% 15.9ms ± 2% +2.49% (p=0.000 n=10+20)
Throughput/MaxPacket/1MB-8 5.81ms ±23% 6.14ms ±44% ~ (p=0.605 n=8+18)
Throughput/MaxPacket/2MB-8 8.91ms ±22% 8.74ms ±33% ~ (p=0.498 n=9+19)
Throughput/MaxPacket/4MB-8 12.8ms ± 3% 14.0ms ±10% +9.74% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 25.1ms ± 7% 24.6ms ±16% ~ (p=0.129 n=9+19)
Throughput/MaxPacket/16MB-8 46.3ms ± 4% 45.9ms ±12% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 88.5ms ± 4% 86.0ms ± 4% -2.82% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 173ms ± 2% 167ms ± 7% -3.42% (p=0.001 n=10+19)
Throughput/DynamicPacket/1MB-8 5.88ms ± 4% 6.59ms ±64% ~ (p=0.232 n=9+18)
Throughput/DynamicPacket/2MB-8 9.08ms ±12% 8.73ms ±21% ~ (p=0.408 n=10+18)
Throughput/DynamicPacket/4MB-8 14.2ms ± 5% 14.0ms ±11% ~ (p=0.188 n=9+19)
Throughput/DynamicPacket/8MB-8 25.1ms ± 6% 24.0ms ± 7% -4.39% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 45.6ms ± 3% 43.3ms ± 1% -5.22% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 88.4ms ± 3% 84.8ms ± 2% -4.06% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 175ms ± 3% 167ms ± 2% -4.63% (p=0.000 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 694ms ± 0% -0.02% (p=0.000 n=9+9)
Latency/MaxPacket/500kbps-8 279ms ± 0% 279ms ± 0% -0.09% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 140ms ± 0% -0.15% (p=0.000 n=10+9)
Latency/MaxPacket/2000kbps-8 71.1ms ± 0% 71.0ms ± 0% -0.09% (p=0.001 n=8+9)
Latency/MaxPacket/5000kbps-8 30.5ms ± 6% 30.1ms ± 6% ~ (p=0.905 n=10+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 134ms ± 0% ~ (p=0.796 n=9+9)
Latency/DynamicPacket/500kbps-8 54.8ms ± 0% 54.7ms ± 0% -0.18% (p=0.000 n=8+10)
Latency/DynamicPacket/1000kbps-8 28.5ms ± 0% 29.1ms ± 8% ~ (p=0.173 n=8+10)
Latency/DynamicPacket/2000kbps-8 15.3ms ± 6% 15.9ms ±10% ~ (p=0.905 n=9+10)
Latency/DynamicPacket/5000kbps-8 9.14ms ±21% 9.65ms ±82% ~ (p=0.529 n=10+10)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 175MB/s ±13% 167MB/s ±64% ~ (p=0.646 n=7+20)
Throughput/MaxPacket/2MB-8 241MB/s ±25% 241MB/s ±40% ~ (p=0.660 n=9+20)
Throughput/MaxPacket/4MB-8 328MB/s ± 3% 300MB/s ± 9% -8.70% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 335MB/s ± 7% 340MB/s ±17% ~ (p=0.212 n=9+20)
Throughput/MaxPacket/16MB-8 363MB/s ± 4% 367MB/s ±11% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 379MB/s ± 4% 390MB/s ± 4% +2.93% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 388MB/s ± 2% 401MB/s ± 7% +3.25% (p=0.004 n=10+20)
Throughput/DynamicPacket/1MB-8 178MB/s ± 4% 157MB/s ±73% ~ (p=0.127 n=9+20)
Throughput/DynamicPacket/2MB-8 232MB/s ±11% 243MB/s ±18% ~ (p=0.415 n=10+18)
Throughput/DynamicPacket/4MB-8 296MB/s ± 5% 299MB/s ±15% ~ (p=0.295 n=9+20)
Throughput/DynamicPacket/8MB-8 334MB/s ± 6% 350MB/s ± 7% +4.58% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 368MB/s ± 3% 388MB/s ± 1% +5.48% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 380MB/s ± 3% 396MB/s ± 2% +4.20% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 384MB/s ± 3% 403MB/s ± 2% +4.83% (p=0.000 n=10+10)
Comparing TLS 1.2 and TLS 1.3 at tip shows a slight (~5-10%) slowdown of
handshakes, which might be worth looking at next cycle, but the latency
improvements are expected to overshadow that.
name old time/op new time/op delta
HandshakeServer/ECDHE-P256-RSA-8 909µs ± 1% 963µs ± 0% +5.87% (p=0.000 n=17+18)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 204µs ± 1% 225µs ± 2% +10.20% (p=0.000 n=18+20)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 208µs ± 1% 230µs ± 2% +10.35% (p=0.000 n=20+18)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.9ms ± 2% 15.9ms ± 1% ~ (p=0.444 n=20+19)
Throughput/MaxPacket/1MB-8 6.14ms ±44% 7.07ms ±46% ~ (p=0.057 n=18+19)
Throughput/MaxPacket/2MB-8 8.74ms ±33% 8.61ms ± 9% ~ (p=0.552 n=19+17)
Throughput/MaxPacket/4MB-8 14.0ms ±10% 14.1ms ±12% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 24.6ms ±16% 25.6ms ±14% ~ (p=0.107 n=19+20)
Throughput/MaxPacket/16MB-8 45.9ms ±12% 44.7ms ± 6% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 86.0ms ± 4% 87.9ms ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 167ms ± 7% 169ms ± 2% +1.26% (p=0.011 n=19+19)
Throughput/DynamicPacket/1MB-8 6.59ms ±64% 6.79ms ±43% ~ (p=0.480 n=18+19)
Throughput/DynamicPacket/2MB-8 8.73ms ±21% 9.58ms ±13% +9.71% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 14.0ms ±11% 13.9ms ±10% ~ (p=0.687 n=19+20)
Throughput/DynamicPacket/8MB-8 24.0ms ± 7% 24.6ms ± 8% +2.36% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 43.3ms ± 1% 44.3ms ± 2% +2.48% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 84.8ms ± 2% 86.7ms ± 2% +2.27% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 167ms ± 2% 170ms ± 3% +1.89% (p=0.005 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 699ms ± 0% +0.65% (p=0.000 n=9+10)
Latency/MaxPacket/500kbps-8 279ms ± 0% 280ms ± 0% +0.68% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 141ms ± 0% +0.59% (p=0.000 n=9+9)
Latency/MaxPacket/2000kbps-8 71.0ms ± 0% 71.3ms ± 0% +0.42% (p=0.000 n=9+9)
Latency/MaxPacket/5000kbps-8 30.1ms ± 6% 30.7ms ±10% +1.93% (p=0.019 n=9+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 138ms ± 0% +3.22% (p=0.000 n=9+10)
Latency/DynamicPacket/500kbps-8 54.7ms ± 0% 56.3ms ± 0% +3.03% (p=0.000 n=10+8)
Latency/DynamicPacket/1000kbps-8 29.1ms ± 8% 29.1ms ± 0% ~ (p=0.173 n=10+8)
Latency/DynamicPacket/2000kbps-8 15.9ms ±10% 16.4ms ±36% ~ (p=0.633 n=10+8)
Latency/DynamicPacket/5000kbps-8 9.65ms ±82% 8.32ms ± 8% ~ (p=0.573 n=10+8)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 167MB/s ±64% 155MB/s ±55% ~ (p=0.224 n=20+19)
Throughput/MaxPacket/2MB-8 241MB/s ±40% 244MB/s ± 9% ~ (p=0.407 n=20+17)
Throughput/MaxPacket/4MB-8 300MB/s ± 9% 298MB/s ±11% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 340MB/s ±17% 330MB/s ±13% ~ (p=0.201 n=20+20)
Throughput/MaxPacket/16MB-8 367MB/s ±11% 375MB/s ± 5% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 390MB/s ± 4% 382MB/s ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 401MB/s ± 7% 397MB/s ± 2% -0.96% (p=0.030 n=20+19)
Throughput/DynamicPacket/1MB-8 157MB/s ±73% 156MB/s ±39% ~ (p=0.738 n=20+20)
Throughput/DynamicPacket/2MB-8 243MB/s ±18% 220MB/s ±14% -9.65% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 299MB/s ±15% 303MB/s ± 9% ~ (p=0.512 n=20+20)
Throughput/DynamicPacket/8MB-8 350MB/s ± 7% 342MB/s ± 8% -2.27% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 388MB/s ± 1% 378MB/s ± 2% -2.41% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 396MB/s ± 2% 387MB/s ± 2% -2.21% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 403MB/s ± 2% 396MB/s ± 3% -1.84% (p=0.005 n=10+10)
Fixes #9671
Change-Id: Ieb57c5140eb2c083b8be0d42b240cd2eeec0dcf6
Reviewed-on: https://go-review.googlesource.com/c/147638
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2018-11-05 22:52:51 -05:00
|
|
|
b.Run("TLSv13", func(b *testing.B) {
|
|
|
|
|
benchmarkHandshakeServer(b, VersionTLS13, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,
|
|
|
|
|
CurveP256, testP256Certificate, testP256PrivateKey)
|
|
|
|
|
})
|
|
|
|
|
b.Run("TLSv12", func(b *testing.B) {
|
|
|
|
|
benchmarkHandshakeServer(b, VersionTLS12, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,
|
|
|
|
|
CurveP256, testP256Certificate, testP256PrivateKey)
|
|
|
|
|
})
|
2017-06-02 12:33:50 -07:00
|
|
|
})
|
|
|
|
|
b.Run("ECDHE-X25519-ECDSA-P256", func(b *testing.B) {
|
crypto/tls: enable TLS 1.3 and update tests
To disable TLS 1.3, simply remove VersionTLS13 from supportedVersions,
as tested by TestEscapeRoute, and amend documentation. To make it
opt-in, revert the change to (*Config).supportedVersions from this CL.
I did not have the heart to implement the early data skipping feature
when I realized that it did not offer a choice between two
abstraction-breaking options, but demanded them both (look for handshake
type in case of HelloRetryRequest, trial decryption otherwise). It's a
lot of complexity for an apparently small gain, but if anyone has strong
opinions about it let me know.
Note that in TLS 1.3 alerts are encrypted, so the close_notify peeking
to return (n > 0, io.EOF) from Read doesn't work. If we are lucky, those
servers that unexpectedly close connections after serving a single
request will have stopped (maybe thanks to H/2) before they got updated
to TLS 1.3.
Relatedly, session tickets are now provisioned on the client first Read
instead of at Handshake time, because they are, well, post-handshake
messages. If this proves to be a problem we might try to peek at them.
Doubled the tests that cover logic that's different in TLS 1.3.
The benchmarks for TLS 1.2 compared to be0f3c286b5 (before TLS 1.3 and
its refactors, after CL 142817 changed them to use real connections)
show little movement.
name old time/op new time/op delta
HandshakeServer/RSA-8 795µs ± 1% 798µs ± 1% ~ (p=0.057 n=10+18)
HandshakeServer/ECDHE-P256-RSA-8 903µs ± 0% 909µs ± 1% +0.68% (p=0.000 n=8+17)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 198µs ± 0% 204µs ± 1% +3.24% (p=0.000 n=9+18)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 202µs ± 3% 208µs ± 1% +2.98% (p=0.000 n=9+20)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.5ms ± 1% 15.9ms ± 2% +2.49% (p=0.000 n=10+20)
Throughput/MaxPacket/1MB-8 5.81ms ±23% 6.14ms ±44% ~ (p=0.605 n=8+18)
Throughput/MaxPacket/2MB-8 8.91ms ±22% 8.74ms ±33% ~ (p=0.498 n=9+19)
Throughput/MaxPacket/4MB-8 12.8ms ± 3% 14.0ms ±10% +9.74% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 25.1ms ± 7% 24.6ms ±16% ~ (p=0.129 n=9+19)
Throughput/MaxPacket/16MB-8 46.3ms ± 4% 45.9ms ±12% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 88.5ms ± 4% 86.0ms ± 4% -2.82% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 173ms ± 2% 167ms ± 7% -3.42% (p=0.001 n=10+19)
Throughput/DynamicPacket/1MB-8 5.88ms ± 4% 6.59ms ±64% ~ (p=0.232 n=9+18)
Throughput/DynamicPacket/2MB-8 9.08ms ±12% 8.73ms ±21% ~ (p=0.408 n=10+18)
Throughput/DynamicPacket/4MB-8 14.2ms ± 5% 14.0ms ±11% ~ (p=0.188 n=9+19)
Throughput/DynamicPacket/8MB-8 25.1ms ± 6% 24.0ms ± 7% -4.39% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 45.6ms ± 3% 43.3ms ± 1% -5.22% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 88.4ms ± 3% 84.8ms ± 2% -4.06% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 175ms ± 3% 167ms ± 2% -4.63% (p=0.000 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 694ms ± 0% -0.02% (p=0.000 n=9+9)
Latency/MaxPacket/500kbps-8 279ms ± 0% 279ms ± 0% -0.09% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 140ms ± 0% -0.15% (p=0.000 n=10+9)
Latency/MaxPacket/2000kbps-8 71.1ms ± 0% 71.0ms ± 0% -0.09% (p=0.001 n=8+9)
Latency/MaxPacket/5000kbps-8 30.5ms ± 6% 30.1ms ± 6% ~ (p=0.905 n=10+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 134ms ± 0% ~ (p=0.796 n=9+9)
Latency/DynamicPacket/500kbps-8 54.8ms ± 0% 54.7ms ± 0% -0.18% (p=0.000 n=8+10)
Latency/DynamicPacket/1000kbps-8 28.5ms ± 0% 29.1ms ± 8% ~ (p=0.173 n=8+10)
Latency/DynamicPacket/2000kbps-8 15.3ms ± 6% 15.9ms ±10% ~ (p=0.905 n=9+10)
Latency/DynamicPacket/5000kbps-8 9.14ms ±21% 9.65ms ±82% ~ (p=0.529 n=10+10)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 175MB/s ±13% 167MB/s ±64% ~ (p=0.646 n=7+20)
Throughput/MaxPacket/2MB-8 241MB/s ±25% 241MB/s ±40% ~ (p=0.660 n=9+20)
Throughput/MaxPacket/4MB-8 328MB/s ± 3% 300MB/s ± 9% -8.70% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 335MB/s ± 7% 340MB/s ±17% ~ (p=0.212 n=9+20)
Throughput/MaxPacket/16MB-8 363MB/s ± 4% 367MB/s ±11% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 379MB/s ± 4% 390MB/s ± 4% +2.93% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 388MB/s ± 2% 401MB/s ± 7% +3.25% (p=0.004 n=10+20)
Throughput/DynamicPacket/1MB-8 178MB/s ± 4% 157MB/s ±73% ~ (p=0.127 n=9+20)
Throughput/DynamicPacket/2MB-8 232MB/s ±11% 243MB/s ±18% ~ (p=0.415 n=10+18)
Throughput/DynamicPacket/4MB-8 296MB/s ± 5% 299MB/s ±15% ~ (p=0.295 n=9+20)
Throughput/DynamicPacket/8MB-8 334MB/s ± 6% 350MB/s ± 7% +4.58% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 368MB/s ± 3% 388MB/s ± 1% +5.48% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 380MB/s ± 3% 396MB/s ± 2% +4.20% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 384MB/s ± 3% 403MB/s ± 2% +4.83% (p=0.000 n=10+10)
Comparing TLS 1.2 and TLS 1.3 at tip shows a slight (~5-10%) slowdown of
handshakes, which might be worth looking at next cycle, but the latency
improvements are expected to overshadow that.
name old time/op new time/op delta
HandshakeServer/ECDHE-P256-RSA-8 909µs ± 1% 963µs ± 0% +5.87% (p=0.000 n=17+18)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 204µs ± 1% 225µs ± 2% +10.20% (p=0.000 n=18+20)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 208µs ± 1% 230µs ± 2% +10.35% (p=0.000 n=20+18)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.9ms ± 2% 15.9ms ± 1% ~ (p=0.444 n=20+19)
Throughput/MaxPacket/1MB-8 6.14ms ±44% 7.07ms ±46% ~ (p=0.057 n=18+19)
Throughput/MaxPacket/2MB-8 8.74ms ±33% 8.61ms ± 9% ~ (p=0.552 n=19+17)
Throughput/MaxPacket/4MB-8 14.0ms ±10% 14.1ms ±12% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 24.6ms ±16% 25.6ms ±14% ~ (p=0.107 n=19+20)
Throughput/MaxPacket/16MB-8 45.9ms ±12% 44.7ms ± 6% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 86.0ms ± 4% 87.9ms ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 167ms ± 7% 169ms ± 2% +1.26% (p=0.011 n=19+19)
Throughput/DynamicPacket/1MB-8 6.59ms ±64% 6.79ms ±43% ~ (p=0.480 n=18+19)
Throughput/DynamicPacket/2MB-8 8.73ms ±21% 9.58ms ±13% +9.71% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 14.0ms ±11% 13.9ms ±10% ~ (p=0.687 n=19+20)
Throughput/DynamicPacket/8MB-8 24.0ms ± 7% 24.6ms ± 8% +2.36% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 43.3ms ± 1% 44.3ms ± 2% +2.48% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 84.8ms ± 2% 86.7ms ± 2% +2.27% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 167ms ± 2% 170ms ± 3% +1.89% (p=0.005 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 699ms ± 0% +0.65% (p=0.000 n=9+10)
Latency/MaxPacket/500kbps-8 279ms ± 0% 280ms ± 0% +0.68% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 141ms ± 0% +0.59% (p=0.000 n=9+9)
Latency/MaxPacket/2000kbps-8 71.0ms ± 0% 71.3ms ± 0% +0.42% (p=0.000 n=9+9)
Latency/MaxPacket/5000kbps-8 30.1ms ± 6% 30.7ms ±10% +1.93% (p=0.019 n=9+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 138ms ± 0% +3.22% (p=0.000 n=9+10)
Latency/DynamicPacket/500kbps-8 54.7ms ± 0% 56.3ms ± 0% +3.03% (p=0.000 n=10+8)
Latency/DynamicPacket/1000kbps-8 29.1ms ± 8% 29.1ms ± 0% ~ (p=0.173 n=10+8)
Latency/DynamicPacket/2000kbps-8 15.9ms ±10% 16.4ms ±36% ~ (p=0.633 n=10+8)
Latency/DynamicPacket/5000kbps-8 9.65ms ±82% 8.32ms ± 8% ~ (p=0.573 n=10+8)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 167MB/s ±64% 155MB/s ±55% ~ (p=0.224 n=20+19)
Throughput/MaxPacket/2MB-8 241MB/s ±40% 244MB/s ± 9% ~ (p=0.407 n=20+17)
Throughput/MaxPacket/4MB-8 300MB/s ± 9% 298MB/s ±11% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 340MB/s ±17% 330MB/s ±13% ~ (p=0.201 n=20+20)
Throughput/MaxPacket/16MB-8 367MB/s ±11% 375MB/s ± 5% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 390MB/s ± 4% 382MB/s ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 401MB/s ± 7% 397MB/s ± 2% -0.96% (p=0.030 n=20+19)
Throughput/DynamicPacket/1MB-8 157MB/s ±73% 156MB/s ±39% ~ (p=0.738 n=20+20)
Throughput/DynamicPacket/2MB-8 243MB/s ±18% 220MB/s ±14% -9.65% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 299MB/s ±15% 303MB/s ± 9% ~ (p=0.512 n=20+20)
Throughput/DynamicPacket/8MB-8 350MB/s ± 7% 342MB/s ± 8% -2.27% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 388MB/s ± 1% 378MB/s ± 2% -2.41% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 396MB/s ± 2% 387MB/s ± 2% -2.21% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 403MB/s ± 2% 396MB/s ± 3% -1.84% (p=0.005 n=10+10)
Fixes #9671
Change-Id: Ieb57c5140eb2c083b8be0d42b240cd2eeec0dcf6
Reviewed-on: https://go-review.googlesource.com/c/147638
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2018-11-05 22:52:51 -05:00
|
|
|
b.Run("TLSv13", func(b *testing.B) {
|
|
|
|
|
benchmarkHandshakeServer(b, VersionTLS13, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,
|
|
|
|
|
X25519, testP256Certificate, testP256PrivateKey)
|
|
|
|
|
})
|
|
|
|
|
b.Run("TLSv12", func(b *testing.B) {
|
|
|
|
|
benchmarkHandshakeServer(b, VersionTLS12, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,
|
|
|
|
|
X25519, testP256Certificate, testP256PrivateKey)
|
|
|
|
|
})
|
2017-06-02 12:33:50 -07:00
|
|
|
})
|
|
|
|
|
b.Run("ECDHE-P521-ECDSA-P521", func(b *testing.B) {
|
|
|
|
|
if testECDSAPrivateKey.PublicKey.Curve != elliptic.P521() {
|
|
|
|
|
b.Fatal("test ECDSA key doesn't use curve P-521")
|
|
|
|
|
}
|
crypto/tls: enable TLS 1.3 and update tests
To disable TLS 1.3, simply remove VersionTLS13 from supportedVersions,
as tested by TestEscapeRoute, and amend documentation. To make it
opt-in, revert the change to (*Config).supportedVersions from this CL.
I did not have the heart to implement the early data skipping feature
when I realized that it did not offer a choice between two
abstraction-breaking options, but demanded them both (look for handshake
type in case of HelloRetryRequest, trial decryption otherwise). It's a
lot of complexity for an apparently small gain, but if anyone has strong
opinions about it let me know.
Note that in TLS 1.3 alerts are encrypted, so the close_notify peeking
to return (n > 0, io.EOF) from Read doesn't work. If we are lucky, those
servers that unexpectedly close connections after serving a single
request will have stopped (maybe thanks to H/2) before they got updated
to TLS 1.3.
Relatedly, session tickets are now provisioned on the client first Read
instead of at Handshake time, because they are, well, post-handshake
messages. If this proves to be a problem we might try to peek at them.
Doubled the tests that cover logic that's different in TLS 1.3.
The benchmarks for TLS 1.2 compared to be0f3c286b5 (before TLS 1.3 and
its refactors, after CL 142817 changed them to use real connections)
show little movement.
name old time/op new time/op delta
HandshakeServer/RSA-8 795µs ± 1% 798µs ± 1% ~ (p=0.057 n=10+18)
HandshakeServer/ECDHE-P256-RSA-8 903µs ± 0% 909µs ± 1% +0.68% (p=0.000 n=8+17)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 198µs ± 0% 204µs ± 1% +3.24% (p=0.000 n=9+18)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 202µs ± 3% 208µs ± 1% +2.98% (p=0.000 n=9+20)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.5ms ± 1% 15.9ms ± 2% +2.49% (p=0.000 n=10+20)
Throughput/MaxPacket/1MB-8 5.81ms ±23% 6.14ms ±44% ~ (p=0.605 n=8+18)
Throughput/MaxPacket/2MB-8 8.91ms ±22% 8.74ms ±33% ~ (p=0.498 n=9+19)
Throughput/MaxPacket/4MB-8 12.8ms ± 3% 14.0ms ±10% +9.74% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 25.1ms ± 7% 24.6ms ±16% ~ (p=0.129 n=9+19)
Throughput/MaxPacket/16MB-8 46.3ms ± 4% 45.9ms ±12% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 88.5ms ± 4% 86.0ms ± 4% -2.82% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 173ms ± 2% 167ms ± 7% -3.42% (p=0.001 n=10+19)
Throughput/DynamicPacket/1MB-8 5.88ms ± 4% 6.59ms ±64% ~ (p=0.232 n=9+18)
Throughput/DynamicPacket/2MB-8 9.08ms ±12% 8.73ms ±21% ~ (p=0.408 n=10+18)
Throughput/DynamicPacket/4MB-8 14.2ms ± 5% 14.0ms ±11% ~ (p=0.188 n=9+19)
Throughput/DynamicPacket/8MB-8 25.1ms ± 6% 24.0ms ± 7% -4.39% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 45.6ms ± 3% 43.3ms ± 1% -5.22% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 88.4ms ± 3% 84.8ms ± 2% -4.06% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 175ms ± 3% 167ms ± 2% -4.63% (p=0.000 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 694ms ± 0% -0.02% (p=0.000 n=9+9)
Latency/MaxPacket/500kbps-8 279ms ± 0% 279ms ± 0% -0.09% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 140ms ± 0% -0.15% (p=0.000 n=10+9)
Latency/MaxPacket/2000kbps-8 71.1ms ± 0% 71.0ms ± 0% -0.09% (p=0.001 n=8+9)
Latency/MaxPacket/5000kbps-8 30.5ms ± 6% 30.1ms ± 6% ~ (p=0.905 n=10+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 134ms ± 0% ~ (p=0.796 n=9+9)
Latency/DynamicPacket/500kbps-8 54.8ms ± 0% 54.7ms ± 0% -0.18% (p=0.000 n=8+10)
Latency/DynamicPacket/1000kbps-8 28.5ms ± 0% 29.1ms ± 8% ~ (p=0.173 n=8+10)
Latency/DynamicPacket/2000kbps-8 15.3ms ± 6% 15.9ms ±10% ~ (p=0.905 n=9+10)
Latency/DynamicPacket/5000kbps-8 9.14ms ±21% 9.65ms ±82% ~ (p=0.529 n=10+10)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 175MB/s ±13% 167MB/s ±64% ~ (p=0.646 n=7+20)
Throughput/MaxPacket/2MB-8 241MB/s ±25% 241MB/s ±40% ~ (p=0.660 n=9+20)
Throughput/MaxPacket/4MB-8 328MB/s ± 3% 300MB/s ± 9% -8.70% (p=0.000 n=10+17)
Throughput/MaxPacket/8MB-8 335MB/s ± 7% 340MB/s ±17% ~ (p=0.212 n=9+20)
Throughput/MaxPacket/16MB-8 363MB/s ± 4% 367MB/s ±11% ~ (p=0.340 n=9+20)
Throughput/MaxPacket/32MB-8 379MB/s ± 4% 390MB/s ± 4% +2.93% (p=0.004 n=10+20)
Throughput/MaxPacket/64MB-8 388MB/s ± 2% 401MB/s ± 7% +3.25% (p=0.004 n=10+20)
Throughput/DynamicPacket/1MB-8 178MB/s ± 4% 157MB/s ±73% ~ (p=0.127 n=9+20)
Throughput/DynamicPacket/2MB-8 232MB/s ±11% 243MB/s ±18% ~ (p=0.415 n=10+18)
Throughput/DynamicPacket/4MB-8 296MB/s ± 5% 299MB/s ±15% ~ (p=0.295 n=9+20)
Throughput/DynamicPacket/8MB-8 334MB/s ± 6% 350MB/s ± 7% +4.58% (p=0.000 n=10+18)
Throughput/DynamicPacket/16MB-8 368MB/s ± 3% 388MB/s ± 1% +5.48% (p=0.000 n=10+8)
Throughput/DynamicPacket/32MB-8 380MB/s ± 3% 396MB/s ± 2% +4.20% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 384MB/s ± 3% 403MB/s ± 2% +4.83% (p=0.000 n=10+10)
Comparing TLS 1.2 and TLS 1.3 at tip shows a slight (~5-10%) slowdown of
handshakes, which might be worth looking at next cycle, but the latency
improvements are expected to overshadow that.
name old time/op new time/op delta
HandshakeServer/ECDHE-P256-RSA-8 909µs ± 1% 963µs ± 0% +5.87% (p=0.000 n=17+18)
HandshakeServer/ECDHE-P256-ECDSA-P256-8 204µs ± 1% 225µs ± 2% +10.20% (p=0.000 n=18+20)
HandshakeServer/ECDHE-X25519-ECDSA-P256-8 208µs ± 1% 230µs ± 2% +10.35% (p=0.000 n=20+18)
HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.9ms ± 2% 15.9ms ± 1% ~ (p=0.444 n=20+19)
Throughput/MaxPacket/1MB-8 6.14ms ±44% 7.07ms ±46% ~ (p=0.057 n=18+19)
Throughput/MaxPacket/2MB-8 8.74ms ±33% 8.61ms ± 9% ~ (p=0.552 n=19+17)
Throughput/MaxPacket/4MB-8 14.0ms ±10% 14.1ms ±12% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 24.6ms ±16% 25.6ms ±14% ~ (p=0.107 n=19+20)
Throughput/MaxPacket/16MB-8 45.9ms ±12% 44.7ms ± 6% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 86.0ms ± 4% 87.9ms ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 167ms ± 7% 169ms ± 2% +1.26% (p=0.011 n=19+19)
Throughput/DynamicPacket/1MB-8 6.59ms ±64% 6.79ms ±43% ~ (p=0.480 n=18+19)
Throughput/DynamicPacket/2MB-8 8.73ms ±21% 9.58ms ±13% +9.71% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 14.0ms ±11% 13.9ms ±10% ~ (p=0.687 n=19+20)
Throughput/DynamicPacket/8MB-8 24.0ms ± 7% 24.6ms ± 8% +2.36% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 43.3ms ± 1% 44.3ms ± 2% +2.48% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 84.8ms ± 2% 86.7ms ± 2% +2.27% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 167ms ± 2% 170ms ± 3% +1.89% (p=0.005 n=10+10)
Latency/MaxPacket/200kbps-8 694ms ± 0% 699ms ± 0% +0.65% (p=0.000 n=9+10)
Latency/MaxPacket/500kbps-8 279ms ± 0% 280ms ± 0% +0.68% (p=0.000 n=10+10)
Latency/MaxPacket/1000kbps-8 140ms ± 0% 141ms ± 0% +0.59% (p=0.000 n=9+9)
Latency/MaxPacket/2000kbps-8 71.0ms ± 0% 71.3ms ± 0% +0.42% (p=0.000 n=9+9)
Latency/MaxPacket/5000kbps-8 30.1ms ± 6% 30.7ms ±10% +1.93% (p=0.019 n=9+9)
Latency/DynamicPacket/200kbps-8 134ms ± 0% 138ms ± 0% +3.22% (p=0.000 n=9+10)
Latency/DynamicPacket/500kbps-8 54.7ms ± 0% 56.3ms ± 0% +3.03% (p=0.000 n=10+8)
Latency/DynamicPacket/1000kbps-8 29.1ms ± 8% 29.1ms ± 0% ~ (p=0.173 n=10+8)
Latency/DynamicPacket/2000kbps-8 15.9ms ±10% 16.4ms ±36% ~ (p=0.633 n=10+8)
Latency/DynamicPacket/5000kbps-8 9.65ms ±82% 8.32ms ± 8% ~ (p=0.573 n=10+8)
name old speed new speed delta
Throughput/MaxPacket/1MB-8 167MB/s ±64% 155MB/s ±55% ~ (p=0.224 n=20+19)
Throughput/MaxPacket/2MB-8 241MB/s ±40% 244MB/s ± 9% ~ (p=0.407 n=20+17)
Throughput/MaxPacket/4MB-8 300MB/s ± 9% 298MB/s ±11% ~ (p=0.707 n=17+20)
Throughput/MaxPacket/8MB-8 340MB/s ±17% 330MB/s ±13% ~ (p=0.201 n=20+20)
Throughput/MaxPacket/16MB-8 367MB/s ±11% 375MB/s ± 5% ~ (p=0.607 n=20+19)
Throughput/MaxPacket/32MB-8 390MB/s ± 4% 382MB/s ± 8% ~ (p=0.113 n=20+19)
Throughput/MaxPacket/64MB-8 401MB/s ± 7% 397MB/s ± 2% -0.96% (p=0.030 n=20+19)
Throughput/DynamicPacket/1MB-8 157MB/s ±73% 156MB/s ±39% ~ (p=0.738 n=20+20)
Throughput/DynamicPacket/2MB-8 243MB/s ±18% 220MB/s ±14% -9.65% (p=0.006 n=18+20)
Throughput/DynamicPacket/4MB-8 299MB/s ±15% 303MB/s ± 9% ~ (p=0.512 n=20+20)
Throughput/DynamicPacket/8MB-8 350MB/s ± 7% 342MB/s ± 8% -2.27% (p=0.045 n=18+17)
Throughput/DynamicPacket/16MB-8 388MB/s ± 1% 378MB/s ± 2% -2.41% (p=0.001 n=8+9)
Throughput/DynamicPacket/32MB-8 396MB/s ± 2% 387MB/s ± 2% -2.21% (p=0.000 n=10+10)
Throughput/DynamicPacket/64MB-8 403MB/s ± 2% 396MB/s ± 3% -1.84% (p=0.005 n=10+10)
Fixes #9671
Change-Id: Ieb57c5140eb2c083b8be0d42b240cd2eeec0dcf6
Reviewed-on: https://go-review.googlesource.com/c/147638
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
2018-11-05 22:52:51 -05:00
|
|
|
b.Run("TLSv13", func(b *testing.B) {
|
|
|
|
|
benchmarkHandshakeServer(b, VersionTLS13, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,
|
|
|
|
|
CurveP521, testECDSACertificate, testECDSAPrivateKey)
|
|
|
|
|
})
|
|
|
|
|
b.Run("TLSv12", func(b *testing.B) {
|
|
|
|
|
benchmarkHandshakeServer(b, VersionTLS12, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,
|
|
|
|
|
CurveP521, testECDSACertificate, testECDSAPrivateKey)
|
|
|
|
|
})
|
2017-06-02 12:33:50 -07:00
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
2013-12-20 11:37:05 -05:00
|
|
|
func TestClientAuth(t *testing.T) {
|
2019-05-16 19:13:29 -04:00
|
|
|
var certPath, keyPath, ecdsaCertPath, ecdsaKeyPath, ed25519CertPath, ed25519KeyPath string
|
2013-12-20 11:37:05 -05:00
|
|
|
|
|
|
|
|
if *update {
|
|
|
|
|
certPath = tempFile(clientCertificatePEM)
|
|
|
|
|
defer os.Remove(certPath)
|
|
|
|
|
keyPath = tempFile(clientKeyPEM)
|
|
|
|
|
defer os.Remove(keyPath)
|
|
|
|
|
ecdsaCertPath = tempFile(clientECDSACertificatePEM)
|
|
|
|
|
defer os.Remove(ecdsaCertPath)
|
|
|
|
|
ecdsaKeyPath = tempFile(clientECDSAKeyPEM)
|
|
|
|
|
defer os.Remove(ecdsaKeyPath)
|
2019-05-16 19:13:29 -04:00
|
|
|
ed25519CertPath = tempFile(clientEd25519CertificatePEM)
|
|
|
|
|
defer os.Remove(ed25519CertPath)
|
|
|
|
|
ed25519KeyPath = tempFile(clientEd25519KeyPEM)
|
|
|
|
|
defer os.Remove(ed25519KeyPath)
|
2019-02-20 13:40:31 -05:00
|
|
|
} else {
|
|
|
|
|
t.Parallel()
|
2013-12-20 11:37:05 -05:00
|
|
|
}
|
|
|
|
|
|
2019-02-20 13:40:31 -05:00
|
|
|
config := testConfig.Clone()
|
|
|
|
|
config.ClientAuth = RequestClientCert
|
2018-10-31 12:14:51 -04:00
|
|
|
|
2019-02-20 13:40:31 -05:00
|
|
|
test := &serverTest{
|
|
|
|
|
name: "ClientAuthRequestedNotGiven",
|
2020-10-15 18:32:20 -07:00
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-cipher", "AES128-SHA", "-ciphersuites", "TLS_AES_128_GCM_SHA256"},
|
2019-02-20 13:40:31 -05:00
|
|
|
config: config,
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS12(t, test)
|
|
|
|
|
runServerTestTLS13(t, test)
|
2019-02-05 15:27:56 -05:00
|
|
|
|
crypto/tls: disable RSA-PSS in TLS 1.2 again
Signing with RSA-PSS can uncover faulty crypto.Signer implementations,
and it can fail for (broken) small keys. We'll have to take that
breakage eventually, but it would be nice for it to be opt-out at first.
TLS 1.3 requires RSA-PSS and is opt-out in Go 1.13. Instead of making a
TLS 1.3 opt-out influence a TLS 1.2 behavior, let's wait to add RSA-PSS
to TLS 1.2 until TLS 1.3 is on without opt-out.
Note that since the Client Hello is sent before a protocol version is
selected, we have to advertise RSA-PSS there to support TLS 1.3.
That means that we still support RSA-PSS on the client in TLS 1.2 for
verifying server certificates, which is fine, as all issues arise on the
signing side. We have to be careful not to pick (or consider available)
RSA-PSS on the client for client certificates, though.
We'd expect tests to change only in TLS 1.2:
* the server won't pick PSS to sign the key exchange
(Server-TLSv12-* w/ RSA, TestHandshakeServerRSAPSS);
* the server won't advertise PSS in CertificateRequest
(Server-TLSv12-ClientAuthRequested*, TestClientAuth);
* and the client won't pick PSS for its CertificateVerify
(Client-TLSv12-ClientCert-RSA-*, TestHandshakeClientCertRSAPSS,
Client-TLSv12-Renegotiate* because "R" requests a client cert).
Client-TLSv13-ClientCert-RSA-RSAPSS was updated because of a fix in the test.
This effectively reverts 88343530720a52c96b21f2bd5488c8fb607605d7.
Testing was made more complex by the undocumented semantics of OpenSSL's
-[client_]sigalgs (see openssl/openssl#9172).
Updates #32425
Change-Id: Iaddeb2df1f5c75cd090cc8321df2ac8e8e7db349
Reviewed-on: https://go-review.googlesource.com/c/go/+/182339
Reviewed-by: Adam Langley <agl@golang.org>
2019-06-13 18:33:33 -04:00
|
|
|
test = &serverTest{
|
|
|
|
|
name: "ClientAuthRequestedAndGiven",
|
2020-10-15 18:32:20 -07:00
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-cipher", "AES128-SHA", "-ciphersuites", "TLS_AES_128_GCM_SHA256",
|
crypto/tls: disable RSA-PSS in TLS 1.2 again
Signing with RSA-PSS can uncover faulty crypto.Signer implementations,
and it can fail for (broken) small keys. We'll have to take that
breakage eventually, but it would be nice for it to be opt-out at first.
TLS 1.3 requires RSA-PSS and is opt-out in Go 1.13. Instead of making a
TLS 1.3 opt-out influence a TLS 1.2 behavior, let's wait to add RSA-PSS
to TLS 1.2 until TLS 1.3 is on without opt-out.
Note that since the Client Hello is sent before a protocol version is
selected, we have to advertise RSA-PSS there to support TLS 1.3.
That means that we still support RSA-PSS on the client in TLS 1.2 for
verifying server certificates, which is fine, as all issues arise on the
signing side. We have to be careful not to pick (or consider available)
RSA-PSS on the client for client certificates, though.
We'd expect tests to change only in TLS 1.2:
* the server won't pick PSS to sign the key exchange
(Server-TLSv12-* w/ RSA, TestHandshakeServerRSAPSS);
* the server won't advertise PSS in CertificateRequest
(Server-TLSv12-ClientAuthRequested*, TestClientAuth);
* and the client won't pick PSS for its CertificateVerify
(Client-TLSv12-ClientCert-RSA-*, TestHandshakeClientCertRSAPSS,
Client-TLSv12-Renegotiate* because "R" requests a client cert).
Client-TLSv13-ClientCert-RSA-RSAPSS was updated because of a fix in the test.
This effectively reverts 88343530720a52c96b21f2bd5488c8fb607605d7.
Testing was made more complex by the undocumented semantics of OpenSSL's
-[client_]sigalgs (see openssl/openssl#9172).
Updates #32425
Change-Id: Iaddeb2df1f5c75cd090cc8321df2ac8e8e7db349
Reviewed-on: https://go-review.googlesource.com/c/go/+/182339
Reviewed-by: Adam Langley <agl@golang.org>
2019-06-13 18:33:33 -04:00
|
|
|
"-cert", certPath, "-key", keyPath, "-client_sigalgs", "rsa_pss_rsae_sha256"},
|
|
|
|
|
config: config,
|
|
|
|
|
expectedPeerCerts: []string{clientCertificatePEM},
|
|
|
|
|
}
|
2019-11-03 21:28:47 -05:00
|
|
|
runServerTestTLS12(t, test)
|
2019-02-20 13:40:31 -05:00
|
|
|
runServerTestTLS13(t, test)
|
2019-02-05 15:27:56 -05:00
|
|
|
|
2019-02-20 13:40:31 -05:00
|
|
|
test = &serverTest{
|
|
|
|
|
name: "ClientAuthRequestedAndECDSAGiven",
|
2020-10-15 18:32:20 -07:00
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-cipher", "AES128-SHA", "-ciphersuites", "TLS_AES_128_GCM_SHA256",
|
2019-02-20 13:40:31 -05:00
|
|
|
"-cert", ecdsaCertPath, "-key", ecdsaKeyPath},
|
|
|
|
|
config: config,
|
|
|
|
|
expectedPeerCerts: []string{clientECDSACertificatePEM},
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS12(t, test)
|
|
|
|
|
runServerTestTLS13(t, test)
|
2019-02-05 15:27:56 -05:00
|
|
|
|
2019-05-16 19:13:29 -04:00
|
|
|
test = &serverTest{
|
|
|
|
|
name: "ClientAuthRequestedAndEd25519Given",
|
2020-10-15 18:32:20 -07:00
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-cipher", "AES128-SHA", "-ciphersuites", "TLS_AES_128_GCM_SHA256",
|
2019-05-16 19:13:29 -04:00
|
|
|
"-cert", ed25519CertPath, "-key", ed25519KeyPath},
|
|
|
|
|
config: config,
|
|
|
|
|
expectedPeerCerts: []string{clientEd25519CertificatePEM},
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS12(t, test)
|
|
|
|
|
runServerTestTLS13(t, test)
|
|
|
|
|
|
2019-02-20 13:40:31 -05:00
|
|
|
test = &serverTest{
|
|
|
|
|
name: "ClientAuthRequestedAndPKCS1v15Given",
|
|
|
|
|
command: []string{"openssl", "s_client", "-no_ticket", "-cipher", "AES128-SHA",
|
crypto/tls: disable RSA-PSS in TLS 1.2 again
Signing with RSA-PSS can uncover faulty crypto.Signer implementations,
and it can fail for (broken) small keys. We'll have to take that
breakage eventually, but it would be nice for it to be opt-out at first.
TLS 1.3 requires RSA-PSS and is opt-out in Go 1.13. Instead of making a
TLS 1.3 opt-out influence a TLS 1.2 behavior, let's wait to add RSA-PSS
to TLS 1.2 until TLS 1.3 is on without opt-out.
Note that since the Client Hello is sent before a protocol version is
selected, we have to advertise RSA-PSS there to support TLS 1.3.
That means that we still support RSA-PSS on the client in TLS 1.2 for
verifying server certificates, which is fine, as all issues arise on the
signing side. We have to be careful not to pick (or consider available)
RSA-PSS on the client for client certificates, though.
We'd expect tests to change only in TLS 1.2:
* the server won't pick PSS to sign the key exchange
(Server-TLSv12-* w/ RSA, TestHandshakeServerRSAPSS);
* the server won't advertise PSS in CertificateRequest
(Server-TLSv12-ClientAuthRequested*, TestClientAuth);
* and the client won't pick PSS for its CertificateVerify
(Client-TLSv12-ClientCert-RSA-*, TestHandshakeClientCertRSAPSS,
Client-TLSv12-Renegotiate* because "R" requests a client cert).
Client-TLSv13-ClientCert-RSA-RSAPSS was updated because of a fix in the test.
This effectively reverts 88343530720a52c96b21f2bd5488c8fb607605d7.
Testing was made more complex by the undocumented semantics of OpenSSL's
-[client_]sigalgs (see openssl/openssl#9172).
Updates #32425
Change-Id: Iaddeb2df1f5c75cd090cc8321df2ac8e8e7db349
Reviewed-on: https://go-review.googlesource.com/c/go/+/182339
Reviewed-by: Adam Langley <agl@golang.org>
2019-06-13 18:33:33 -04:00
|
|
|
"-cert", certPath, "-key", keyPath, "-client_sigalgs", "rsa_pkcs1_sha256"},
|
2019-02-20 13:40:31 -05:00
|
|
|
config: config,
|
|
|
|
|
expectedPeerCerts: []string{clientCertificatePEM},
|
|
|
|
|
}
|
|
|
|
|
runServerTestTLS12(t, test)
|
2013-07-17 12:33:16 -04:00
|
|
|
}
|
2013-08-29 17:18:59 -04:00
|
|
|
|
2016-05-06 12:20:12 -04:00
|
|
|
func TestSNIGivenOnFailure(t *testing.T) {
|
|
|
|
|
const expectedServerName = "test.testing"
|
|
|
|
|
|
|
|
|
|
clientHello := &clientHelloMsg{
|
|
|
|
|
vers: VersionTLS10,
|
2018-10-24 21:22:00 -04:00
|
|
|
random: make([]byte, 32),
|
2016-05-06 12:20:12 -04:00
|
|
|
cipherSuites: []uint16{TLS_RSA_WITH_RC4_128_SHA},
|
|
|
|
|
compressionMethods: []uint8{compressionNone},
|
|
|
|
|
serverName: expectedServerName,
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-30 03:19:01 +00:00
|
|
|
serverConfig := testConfig.Clone()
|
2016-05-06 12:20:12 -04:00
|
|
|
// Erase the server's cipher suites to ensure the handshake fails.
|
|
|
|
|
serverConfig.CipherSuites = nil
|
|
|
|
|
|
2018-10-16 23:47:55 -04:00
|
|
|
c, s := localPipe(t)
|
2016-05-06 12:20:12 -04:00
|
|
|
go func() {
|
|
|
|
|
cli := Client(c, testConfig)
|
|
|
|
|
cli.vers = clientHello.vers
|
crypto/tls: replace all usages of BytesOrPanic
Message marshalling makes use of BytesOrPanic a lot, under the
assumption that it will never panic. This assumption was incorrect, and
specifically crafted handshakes could trigger panics. Rather than just
surgically replacing the usages of BytesOrPanic in paths that could
panic, replace all usages of it with proper error returns in case there
are other ways of triggering panics which we didn't find.
In one specific case, the tree routed by expandLabel, we replace the
usage of BytesOrPanic, but retain a panic. This function already
explicitly panicked elsewhere, and returning an error from it becomes
rather painful because it requires changing a large number of APIs.
The marshalling is unlikely to ever panic, as the inputs are all either
fixed length, or already limited to the sizes required. If it were to
panic, it'd likely only be during development. A close inspection shows
no paths for a user to cause a panic currently.
This patches ends up being rather large, since it requires routing
errors back through functions which previously had no error returns.
Where possible I've tried to use helpers that reduce the verbosity
of frequently repeated stanzas, and to make the diffs as minimal as
possible.
Thanks to Marten Seemann for reporting this issue.
Fixes #58001
Fixes CVE-2022-41724
Change-Id: Ieb55867ef0a3e1e867b33f09421932510cb58851
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1679436
Reviewed-by: Julie Qiu <julieqiu@google.com>
TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/468125
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
2022-12-14 09:43:16 -08:00
|
|
|
if _, err := cli.writeHandshakeRecord(clientHello, nil); err != nil {
|
|
|
|
|
testFatal(t, err)
|
|
|
|
|
}
|
2016-05-06 12:20:12 -04:00
|
|
|
c.Close()
|
|
|
|
|
}()
|
2018-11-02 00:57:30 -04:00
|
|
|
conn := Server(s, serverConfig)
|
2020-08-01 12:18:31 +01:00
|
|
|
ctx := context.Background()
|
|
|
|
|
ch, err := conn.readClientHello(ctx)
|
2016-05-06 12:20:12 -04:00
|
|
|
hs := serverHandshakeState{
|
2018-11-02 00:57:30 -04:00
|
|
|
c: conn,
|
2020-08-01 12:18:31 +01:00
|
|
|
ctx: ctx,
|
2018-11-02 00:57:30 -04:00
|
|
|
clientHello: ch,
|
|
|
|
|
}
|
|
|
|
|
if err == nil {
|
|
|
|
|
err = hs.processClientHello()
|
|
|
|
|
}
|
|
|
|
|
if err == nil {
|
|
|
|
|
err = hs.pickCipherSuite()
|
2016-05-06 12:20:12 -04:00
|
|
|
}
|
|
|
|
|
defer s.Close()
|
|
|
|
|
|
|
|
|
|
if err == nil {
|
|
|
|
|
t.Error("No error reported from server")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
cs := hs.c.ConnectionState()
|
|
|
|
|
if cs.HandshakeComplete {
|
|
|
|
|
t.Error("Handshake registered as complete")
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if cs.ServerName != expectedServerName {
|
|
|
|
|
t.Errorf("Expected ServerName of %q, but got %q", expectedServerName, cs.ServerName)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-10 15:27:34 -07:00
|
|
|
var getConfigForClientTests = []struct {
|
|
|
|
|
setup func(config *Config)
|
|
|
|
|
callback func(clientHello *ClientHelloInfo) (*Config, error)
|
|
|
|
|
errorSubstring string
|
|
|
|
|
verify func(config *Config) error
|
|
|
|
|
}{
|
|
|
|
|
{
|
|
|
|
|
nil,
|
|
|
|
|
func(clientHello *ClientHelloInfo) (*Config, error) {
|
|
|
|
|
return nil, nil
|
|
|
|
|
},
|
|
|
|
|
"",
|
|
|
|
|
nil,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
nil,
|
|
|
|
|
func(clientHello *ClientHelloInfo) (*Config, error) {
|
|
|
|
|
return nil, errors.New("should bubble up")
|
|
|
|
|
},
|
|
|
|
|
"should bubble up",
|
|
|
|
|
nil,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
nil,
|
|
|
|
|
func(clientHello *ClientHelloInfo) (*Config, error) {
|
|
|
|
|
config := testConfig.Clone()
|
|
|
|
|
// Setting a maximum version of TLS 1.1 should cause
|
2018-10-31 09:34:10 -04:00
|
|
|
// the handshake to fail, as the client MinVersion is TLS 1.2.
|
2016-10-10 15:27:34 -07:00
|
|
|
config.MaxVersion = VersionTLS11
|
|
|
|
|
return config, nil
|
|
|
|
|
},
|
2018-10-31 09:34:10 -04:00
|
|
|
"client offered only unsupported versions",
|
2016-10-10 15:27:34 -07:00
|
|
|
nil,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
func(config *Config) {
|
|
|
|
|
for i := range config.SessionTicketKey {
|
|
|
|
|
config.SessionTicketKey[i] = byte(i)
|
|
|
|
|
}
|
|
|
|
|
config.sessionTicketKeys = nil
|
|
|
|
|
},
|
|
|
|
|
func(clientHello *ClientHelloInfo) (*Config, error) {
|
|
|
|
|
config := testConfig.Clone()
|
|
|
|
|
for i := range config.SessionTicketKey {
|
|
|
|
|
config.SessionTicketKey[i] = 0
|
|
|
|
|
}
|
|
|
|
|
config.sessionTicketKeys = nil
|
|
|
|
|
return config, nil
|
|
|
|
|
},
|
|
|
|
|
"",
|
|
|
|
|
func(config *Config) error {
|
2020-04-28 17:47:27 -04:00
|
|
|
if config.SessionTicketKey == [32]byte{} {
|
|
|
|
|
return fmt.Errorf("expected SessionTicketKey to be set")
|
2016-10-10 15:27:34 -07:00
|
|
|
}
|
|
|
|
|
return nil
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
func(config *Config) {
|
|
|
|
|
var dummyKey [32]byte
|
|
|
|
|
for i := range dummyKey {
|
|
|
|
|
dummyKey[i] = byte(i)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
config.SetSessionTicketKeys([][32]byte{dummyKey})
|
|
|
|
|
},
|
|
|
|
|
func(clientHello *ClientHelloInfo) (*Config, error) {
|
|
|
|
|
config := testConfig.Clone()
|
|
|
|
|
config.sessionTicketKeys = nil
|
|
|
|
|
return config, nil
|
|
|
|
|
},
|
|
|
|
|
"",
|
|
|
|
|
func(config *Config) error {
|
2020-04-28 17:47:27 -04:00
|
|
|
if config.SessionTicketKey == [32]byte{} {
|
|
|
|
|
return fmt.Errorf("expected SessionTicketKey to be set")
|
2016-10-10 15:27:34 -07:00
|
|
|
}
|
|
|
|
|
return nil
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestGetConfigForClient(t *testing.T) {
|
|
|
|
|
serverConfig := testConfig.Clone()
|
|
|
|
|
clientConfig := testConfig.Clone()
|
|
|
|
|
clientConfig.MinVersion = VersionTLS12
|
|
|
|
|
|
|
|
|
|
for i, test := range getConfigForClientTests {
|
|
|
|
|
if test.setup != nil {
|
|
|
|
|
test.setup(serverConfig)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
var configReturned *Config
|
|
|
|
|
serverConfig.GetConfigForClient = func(clientHello *ClientHelloInfo) (*Config, error) {
|
|
|
|
|
config, err := test.callback(clientHello)
|
|
|
|
|
configReturned = config
|
|
|
|
|
return config, err
|
|
|
|
|
}
|
2018-10-16 23:47:55 -04:00
|
|
|
c, s := localPipe(t)
|
2016-10-10 15:27:34 -07:00
|
|
|
done := make(chan error)
|
|
|
|
|
|
|
|
|
|
go func() {
|
|
|
|
|
defer s.Close()
|
|
|
|
|
done <- Server(s, serverConfig).Handshake()
|
|
|
|
|
}()
|
|
|
|
|
|
|
|
|
|
clientErr := Client(c, clientConfig).Handshake()
|
|
|
|
|
c.Close()
|
|
|
|
|
|
|
|
|
|
serverErr := <-done
|
|
|
|
|
|
|
|
|
|
if len(test.errorSubstring) == 0 {
|
|
|
|
|
if serverErr != nil || clientErr != nil {
|
2016-10-23 14:10:11 -07:00
|
|
|
t.Errorf("test[%d]: expected no error but got serverErr: %q, clientErr: %q", i, serverErr, clientErr)
|
2016-10-10 15:27:34 -07:00
|
|
|
}
|
|
|
|
|
if test.verify != nil {
|
|
|
|
|
if err := test.verify(configReturned); err != nil {
|
2016-10-23 14:10:11 -07:00
|
|
|
t.Errorf("test[%d]: verify returned error: %v", i, err)
|
2016-10-10 15:27:34 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
if serverErr == nil {
|
2016-10-23 14:10:11 -07:00
|
|
|
t.Errorf("test[%d]: expected error containing %q but got no error", i, test.errorSubstring)
|
2016-10-10 15:27:34 -07:00
|
|
|
} else if !strings.Contains(serverErr.Error(), test.errorSubstring) {
|
2016-10-23 14:10:11 -07:00
|
|
|
t.Errorf("test[%d]: expected error to contain %q but it was %q", i, test.errorSubstring, serverErr)
|
2016-10-10 15:27:34 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-01-26 09:17:46 +00:00
|
|
|
func TestCloseServerConnectionOnIdleClient(t *testing.T) {
|
2018-10-16 23:47:55 -04:00
|
|
|
clientConn, serverConn := localPipe(t)
|
2018-01-26 09:17:46 +00:00
|
|
|
server := Server(serverConn, testConfig.Clone())
|
|
|
|
|
go func() {
|
|
|
|
|
clientConn.Write([]byte{'0'})
|
|
|
|
|
server.Close()
|
|
|
|
|
}()
|
2018-10-26 11:41:02 -04:00
|
|
|
server.SetReadDeadline(time.Now().Add(time.Minute))
|
2018-01-26 09:17:46 +00:00
|
|
|
err := server.Handshake()
|
|
|
|
|
if err != nil {
|
2018-10-16 23:47:55 -04:00
|
|
|
if err, ok := err.(net.Error); ok && err.Timeout() {
|
|
|
|
|
t.Errorf("Expected a closed network connection error but got '%s'", err.Error())
|
2018-01-26 09:17:46 +00:00
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
t.Errorf("Error expected, but no error returned")
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-11-05 15:59:08 -05:00
|
|
|
|
|
|
|
|
func TestCloneHash(t *testing.T) {
|
|
|
|
|
h1 := crypto.SHA256.New()
|
|
|
|
|
h1.Write([]byte("test"))
|
|
|
|
|
s1 := h1.Sum(nil)
|
|
|
|
|
h2 := cloneHash(h1, crypto.SHA256)
|
|
|
|
|
s2 := h2.Sum(nil)
|
|
|
|
|
if !bytes.Equal(s1, s2) {
|
|
|
|
|
t.Error("cloned hash generated a different sum")
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-01-18 17:33:49 -05:00
|
|
|
|
crypto/tls: disable RSA-PSS in TLS 1.2 again
Signing with RSA-PSS can uncover faulty crypto.Signer implementations,
and it can fail for (broken) small keys. We'll have to take that
breakage eventually, but it would be nice for it to be opt-out at first.
TLS 1.3 requires RSA-PSS and is opt-out in Go 1.13. Instead of making a
TLS 1.3 opt-out influence a TLS 1.2 behavior, let's wait to add RSA-PSS
to TLS 1.2 until TLS 1.3 is on without opt-out.
Note that since the Client Hello is sent before a protocol version is
selected, we have to advertise RSA-PSS there to support TLS 1.3.
That means that we still support RSA-PSS on the client in TLS 1.2 for
verifying server certificates, which is fine, as all issues arise on the
signing side. We have to be careful not to pick (or consider available)
RSA-PSS on the client for client certificates, though.
We'd expect tests to change only in TLS 1.2:
* the server won't pick PSS to sign the key exchange
(Server-TLSv12-* w/ RSA, TestHandshakeServerRSAPSS);
* the server won't advertise PSS in CertificateRequest
(Server-TLSv12-ClientAuthRequested*, TestClientAuth);
* and the client won't pick PSS for its CertificateVerify
(Client-TLSv12-ClientCert-RSA-*, TestHandshakeClientCertRSAPSS,
Client-TLSv12-Renegotiate* because "R" requests a client cert).
Client-TLSv13-ClientCert-RSA-RSAPSS was updated because of a fix in the test.
This effectively reverts 88343530720a52c96b21f2bd5488c8fb607605d7.
Testing was made more complex by the undocumented semantics of OpenSSL's
-[client_]sigalgs (see openssl/openssl#9172).
Updates #32425
Change-Id: Iaddeb2df1f5c75cd090cc8321df2ac8e8e7db349
Reviewed-on: https://go-review.googlesource.com/c/go/+/182339
Reviewed-by: Adam Langley <agl@golang.org>
2019-06-13 18:33:33 -04:00
|
|
|
func expectError(t *testing.T, err error, sub string) {
|
|
|
|
|
if err == nil {
|
|
|
|
|
t.Errorf(`expected error %q, got nil`, sub)
|
|
|
|
|
} else if !strings.Contains(err.Error(), sub) {
|
|
|
|
|
t.Errorf(`expected error %q, got %q`, sub, err)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-18 17:33:49 -05:00
|
|
|
func TestKeyTooSmallForRSAPSS(t *testing.T) {
|
|
|
|
|
cert, err := X509KeyPair([]byte(`-----BEGIN CERTIFICATE-----
|
|
|
|
|
MIIBcTCCARugAwIBAgIQGjQnkCFlUqaFlt6ixyz/tDANBgkqhkiG9w0BAQsFADAS
|
|
|
|
|
MRAwDgYDVQQKEwdBY21lIENvMB4XDTE5MDExODIzMjMyOFoXDTIwMDExODIzMjMy
|
|
|
|
|
OFowEjEQMA4GA1UEChMHQWNtZSBDbzBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDd
|
|
|
|
|
ez1rFUDwax2HTxbcnFUP9AhcgEGMHVV2nn4VVEWFJB6I8C/Nkx0XyyQlrmFYBzEQ
|
|
|
|
|
nIPhKls4T0hFoLvjJnXpAgMBAAGjTTBLMA4GA1UdDwEB/wQEAwIFoDATBgNVHSUE
|
|
|
|
|
DDAKBggrBgEFBQcDATAMBgNVHRMBAf8EAjAAMBYGA1UdEQQPMA2CC2V4YW1wbGUu
|
|
|
|
|
Y29tMA0GCSqGSIb3DQEBCwUAA0EAxDuUS+BrrS3c+h+k+fQPOmOScy6yTX9mHw0Q
|
|
|
|
|
KbucGamXYEy0URIwOdO0tQ3LHPc1YGvYSPwkDjkjqECs2Vm/AA==
|
2019-05-21 08:24:27 -04:00
|
|
|
-----END CERTIFICATE-----`), []byte(testingKey(`-----BEGIN RSA TESTING KEY-----
|
2019-01-18 17:33:49 -05:00
|
|
|
MIIBOgIBAAJBAN17PWsVQPBrHYdPFtycVQ/0CFyAQYwdVXaefhVURYUkHojwL82T
|
|
|
|
|
HRfLJCWuYVgHMRCcg+EqWzhPSEWgu+MmdekCAwEAAQJBALjQYNTdXF4CFBbXwUz/
|
|
|
|
|
yt9QFDYT9B5WT/12jeGAe653gtYS6OOi/+eAkGmzg1GlRnw6fOfn+HYNFDORST7z
|
|
|
|
|
4j0CIQDn2xz9hVWQEu9ee3vecNT3f60huDGTNoRhtqgweQGX0wIhAPSLj1VcRZEz
|
|
|
|
|
nKpbtU22+PbIMSJ+e80fmY9LIPx5N4HTAiAthGSimMR9bloz0EY3GyuUEyqoDgMd
|
|
|
|
|
hXxjuno2WesoJQIgemilbcALXpxsLmZLgcQ2KSmaVr7jb5ECx9R+hYKTw1sCIG4s
|
|
|
|
|
T+E0J8wlH24pgwQHzy7Ko2qLwn1b5PW8ecrlvP1g
|
2019-05-21 08:24:27 -04:00
|
|
|
-----END RSA TESTING KEY-----`)))
|
2019-01-18 17:33:49 -05:00
|
|
|
if err != nil {
|
|
|
|
|
t.Fatal(err)
|
|
|
|
|
}
|
crypto/tls: disable RSA-PSS in TLS 1.2 again
Signing with RSA-PSS can uncover faulty crypto.Signer implementations,
and it can fail for (broken) small keys. We'll have to take that
breakage eventually, but it would be nice for it to be opt-out at first.
TLS 1.3 requires RSA-PSS and is opt-out in Go 1.13. Instead of making a
TLS 1.3 opt-out influence a TLS 1.2 behavior, let's wait to add RSA-PSS
to TLS 1.2 until TLS 1.3 is on without opt-out.
Note that since the Client Hello is sent before a protocol version is
selected, we have to advertise RSA-PSS there to support TLS 1.3.
That means that we still support RSA-PSS on the client in TLS 1.2 for
verifying server certificates, which is fine, as all issues arise on the
signing side. We have to be careful not to pick (or consider available)
RSA-PSS on the client for client certificates, though.
We'd expect tests to change only in TLS 1.2:
* the server won't pick PSS to sign the key exchange
(Server-TLSv12-* w/ RSA, TestHandshakeServerRSAPSS);
* the server won't advertise PSS in CertificateRequest
(Server-TLSv12-ClientAuthRequested*, TestClientAuth);
* and the client won't pick PSS for its CertificateVerify
(Client-TLSv12-ClientCert-RSA-*, TestHandshakeClientCertRSAPSS,
Client-TLSv12-Renegotiate* because "R" requests a client cert).
Client-TLSv13-ClientCert-RSA-RSAPSS was updated because of a fix in the test.
This effectively reverts 88343530720a52c96b21f2bd5488c8fb607605d7.
Testing was made more complex by the undocumented semantics of OpenSSL's
-[client_]sigalgs (see openssl/openssl#9172).
Updates #32425
Change-Id: Iaddeb2df1f5c75cd090cc8321df2ac8e8e7db349
Reviewed-on: https://go-review.googlesource.com/c/go/+/182339
Reviewed-by: Adam Langley <agl@golang.org>
2019-06-13 18:33:33 -04:00
|
|
|
|
|
|
|
|
clientConn, serverConn := localPipe(t)
|
|
|
|
|
client := Client(clientConn, testConfig)
|
2019-01-18 17:33:49 -05:00
|
|
|
done := make(chan struct{})
|
|
|
|
|
go func() {
|
|
|
|
|
config := testConfig.Clone()
|
|
|
|
|
config.Certificates = []Certificate{cert}
|
|
|
|
|
config.MinVersion = VersionTLS13
|
|
|
|
|
server := Server(serverConn, config)
|
|
|
|
|
err := server.Handshake()
|
2019-11-04 02:14:18 -05:00
|
|
|
expectError(t, err, "key size too small")
|
2019-01-18 17:33:49 -05:00
|
|
|
close(done)
|
|
|
|
|
}()
|
|
|
|
|
err = client.Handshake()
|
crypto/tls: disable RSA-PSS in TLS 1.2 again
Signing with RSA-PSS can uncover faulty crypto.Signer implementations,
and it can fail for (broken) small keys. We'll have to take that
breakage eventually, but it would be nice for it to be opt-out at first.
TLS 1.3 requires RSA-PSS and is opt-out in Go 1.13. Instead of making a
TLS 1.3 opt-out influence a TLS 1.2 behavior, let's wait to add RSA-PSS
to TLS 1.2 until TLS 1.3 is on without opt-out.
Note that since the Client Hello is sent before a protocol version is
selected, we have to advertise RSA-PSS there to support TLS 1.3.
That means that we still support RSA-PSS on the client in TLS 1.2 for
verifying server certificates, which is fine, as all issues arise on the
signing side. We have to be careful not to pick (or consider available)
RSA-PSS on the client for client certificates, though.
We'd expect tests to change only in TLS 1.2:
* the server won't pick PSS to sign the key exchange
(Server-TLSv12-* w/ RSA, TestHandshakeServerRSAPSS);
* the server won't advertise PSS in CertificateRequest
(Server-TLSv12-ClientAuthRequested*, TestClientAuth);
* and the client won't pick PSS for its CertificateVerify
(Client-TLSv12-ClientCert-RSA-*, TestHandshakeClientCertRSAPSS,
Client-TLSv12-Renegotiate* because "R" requests a client cert).
Client-TLSv13-ClientCert-RSA-RSAPSS was updated because of a fix in the test.
This effectively reverts 88343530720a52c96b21f2bd5488c8fb607605d7.
Testing was made more complex by the undocumented semantics of OpenSSL's
-[client_]sigalgs (see openssl/openssl#9172).
Updates #32425
Change-Id: Iaddeb2df1f5c75cd090cc8321df2ac8e8e7db349
Reviewed-on: https://go-review.googlesource.com/c/go/+/182339
Reviewed-by: Adam Langley <agl@golang.org>
2019-06-13 18:33:33 -04:00
|
|
|
expectError(t, err, "handshake failure")
|
2019-01-18 17:33:49 -05:00
|
|
|
<-done
|
|
|
|
|
}
|
crypto/tls: select only compatible chains from Certificates
Now that we have a full implementation of the logic to check certificate
compatibility, we can let applications just list multiple chains in
Certificates (for example, an RSA and an ECDSA one) and choose the most
appropriate automatically.
NameToCertificate only maps each name to one chain, so simply deprecate
it, and while at it simplify its implementation by not stripping
trailing dots from the SNI (which is specified not to have any, see RFC
6066, Section 3) and by not supporting multi-level wildcards, which are
not a thing in the WebPKI (and in crypto/x509).
The performance of SupportsCertificate without Leaf is poor, but doesn't
affect current users. For now document that, and address it properly in
the next cycle. See #35504.
While cleaning up the Certificates/GetCertificate/GetConfigForClient
behavior, also support leaving Certificates/GetCertificate nil if
GetConfigForClient is set, and send unrecognized_name when there are no
available certificates.
Fixes #29139
Fixes #18377
Change-Id: I26604db48806fe4d608388e55da52f34b7ca4566
Reviewed-on: https://go-review.googlesource.com/c/go/+/205059
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
2019-11-02 14:43:34 -04:00
|
|
|
|
|
|
|
|
func TestMultipleCertificates(t *testing.T) {
|
|
|
|
|
clientConfig := testConfig.Clone()
|
|
|
|
|
clientConfig.CipherSuites = []uint16{TLS_RSA_WITH_AES_128_GCM_SHA256}
|
|
|
|
|
clientConfig.MaxVersion = VersionTLS12
|
|
|
|
|
|
|
|
|
|
serverConfig := testConfig.Clone()
|
|
|
|
|
serverConfig.Certificates = []Certificate{{
|
|
|
|
|
Certificate: [][]byte{testECDSACertificate},
|
|
|
|
|
PrivateKey: testECDSAPrivateKey,
|
|
|
|
|
}, {
|
|
|
|
|
Certificate: [][]byte{testRSACertificate},
|
|
|
|
|
PrivateKey: testRSAPrivateKey,
|
|
|
|
|
}}
|
|
|
|
|
|
|
|
|
|
_, clientState, err := testHandshake(t, clientConfig, serverConfig)
|
|
|
|
|
if err != nil {
|
|
|
|
|
t.Fatal(err)
|
|
|
|
|
}
|
|
|
|
|
if got := clientState.PeerCertificates[0].PublicKeyAlgorithm; got != x509.RSA {
|
|
|
|
|
t.Errorf("expected RSA certificate, got %v", got)
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-08-01 12:18:31 +01:00
|
|
|
|
2020-10-15 18:32:20 -07:00
|
|
|
func TestAESCipherReordering(t *testing.T) {
|
|
|
|
|
currentAESSupport := hasAESGCMHardwareSupport
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
defer func() { hasAESGCMHardwareSupport = currentAESSupport }()
|
2020-10-15 18:32:20 -07:00
|
|
|
|
|
|
|
|
tests := []struct {
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
name string
|
|
|
|
|
clientCiphers []uint16
|
|
|
|
|
serverHasAESGCM bool
|
|
|
|
|
serverCiphers []uint16
|
|
|
|
|
expectedCipher uint16
|
2020-10-15 18:32:20 -07:00
|
|
|
}{
|
|
|
|
|
{
|
|
|
|
|
name: "server has hardware AES, client doesn't (pick ChaCha)",
|
|
|
|
|
clientCiphers: []uint16{
|
|
|
|
|
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
|
|
|
|
|
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
|
|
|
|
|
TLS_RSA_WITH_AES_128_CBC_SHA,
|
|
|
|
|
},
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
serverHasAESGCM: true,
|
|
|
|
|
expectedCipher: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
|
2020-10-15 18:32:20 -07:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name: "client prefers AES-GCM, server doesn't have hardware AES (pick ChaCha)",
|
|
|
|
|
clientCiphers: []uint16{
|
|
|
|
|
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
|
|
|
|
|
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
|
|
|
|
|
TLS_RSA_WITH_AES_128_CBC_SHA,
|
|
|
|
|
},
|
|
|
|
|
serverHasAESGCM: false,
|
|
|
|
|
expectedCipher: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name: "client prefers AES-GCM, server has hardware AES (pick AES-GCM)",
|
|
|
|
|
clientCiphers: []uint16{
|
|
|
|
|
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
|
|
|
|
|
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
|
|
|
|
|
TLS_RSA_WITH_AES_128_CBC_SHA,
|
|
|
|
|
},
|
|
|
|
|
serverHasAESGCM: true,
|
|
|
|
|
expectedCipher: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name: "client prefers AES-GCM and sends GREASE, server has hardware AES (pick AES-GCM)",
|
|
|
|
|
clientCiphers: []uint16{
|
|
|
|
|
0x0A0A, // GREASE value
|
|
|
|
|
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
|
|
|
|
|
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
|
|
|
|
|
TLS_RSA_WITH_AES_128_CBC_SHA,
|
|
|
|
|
},
|
|
|
|
|
serverHasAESGCM: true,
|
|
|
|
|
expectedCipher: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name: "client prefers AES-GCM and doesn't support ChaCha, server doesn't have hardware AES (pick AES-GCM)",
|
|
|
|
|
clientCiphers: []uint16{
|
|
|
|
|
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
|
|
|
|
|
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
|
|
|
|
|
TLS_RSA_WITH_AES_128_CBC_SHA,
|
|
|
|
|
},
|
|
|
|
|
serverHasAESGCM: false,
|
|
|
|
|
expectedCipher: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
|
|
|
|
|
},
|
|
|
|
|
{
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
name: "client prefers AES-GCM and AES-CBC over ChaCha, server doesn't have hardware AES (pick ChaCha)",
|
2020-10-15 18:32:20 -07:00
|
|
|
clientCiphers: []uint16{
|
|
|
|
|
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
|
|
|
|
|
TLS_RSA_WITH_AES_128_CBC_SHA,
|
|
|
|
|
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
|
|
|
|
|
},
|
|
|
|
|
serverHasAESGCM: false,
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
expectedCipher: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
|
2020-10-15 18:32:20 -07:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name: "client prefers AES-GCM over ChaCha and sends GREASE, server doesn't have hardware AES (pick ChaCha)",
|
|
|
|
|
clientCiphers: []uint16{
|
|
|
|
|
0x0A0A, // GREASE value
|
|
|
|
|
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
|
|
|
|
|
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
|
|
|
|
|
TLS_RSA_WITH_AES_128_CBC_SHA,
|
|
|
|
|
},
|
|
|
|
|
serverHasAESGCM: false,
|
|
|
|
|
expectedCipher: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
|
|
|
|
|
},
|
|
|
|
|
{
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
name: "client supports multiple AES-GCM, server doesn't have hardware AES and doesn't support ChaCha (AES-GCM)",
|
2020-10-15 18:32:20 -07:00
|
|
|
clientCiphers: []uint16{
|
|
|
|
|
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
|
|
|
|
|
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
|
|
|
|
|
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
|
|
|
|
|
},
|
|
|
|
|
serverHasAESGCM: false,
|
|
|
|
|
serverCiphers: []uint16{
|
|
|
|
|
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
|
|
|
|
|
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
|
|
|
|
|
},
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
expectedCipher: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name: "client prefers AES-GCM, server has hardware but doesn't support AES (pick ChaCha)",
|
|
|
|
|
clientCiphers: []uint16{
|
|
|
|
|
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
|
|
|
|
|
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
|
|
|
|
|
TLS_RSA_WITH_AES_128_CBC_SHA,
|
|
|
|
|
},
|
|
|
|
|
serverHasAESGCM: true,
|
|
|
|
|
serverCiphers: []uint16{
|
|
|
|
|
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
|
|
|
|
|
},
|
|
|
|
|
expectedCipher: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,
|
2020-10-15 18:32:20 -07:00
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for _, tc := range tests {
|
|
|
|
|
t.Run(tc.name, func(t *testing.T) {
|
|
|
|
|
hasAESGCMHardwareSupport = tc.serverHasAESGCM
|
|
|
|
|
hs := &serverHandshakeState{
|
|
|
|
|
c: &Conn{
|
|
|
|
|
config: &Config{
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
CipherSuites: tc.serverCiphers,
|
2020-10-15 18:32:20 -07:00
|
|
|
},
|
|
|
|
|
vers: VersionTLS12,
|
|
|
|
|
},
|
|
|
|
|
clientHello: &clientHelloMsg{
|
|
|
|
|
cipherSuites: tc.clientCiphers,
|
|
|
|
|
vers: VersionTLS12,
|
|
|
|
|
},
|
|
|
|
|
ecdheOk: true,
|
|
|
|
|
rsaSignOk: true,
|
|
|
|
|
rsaDecryptOk: true,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
err := hs.pickCipherSuite()
|
|
|
|
|
if err != nil {
|
|
|
|
|
t.Errorf("pickCipherSuite failed: %s", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if tc.expectedCipher != hs.suite.id {
|
|
|
|
|
t.Errorf("unexpected cipher chosen: want %d, got %d", tc.expectedCipher, hs.suite.id)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
func TestAESCipherReorderingTLS13(t *testing.T) {
|
2020-10-15 18:32:20 -07:00
|
|
|
currentAESSupport := hasAESGCMHardwareSupport
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
defer func() { hasAESGCMHardwareSupport = currentAESSupport }()
|
2020-10-15 18:32:20 -07:00
|
|
|
|
|
|
|
|
tests := []struct {
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
name string
|
|
|
|
|
clientCiphers []uint16
|
|
|
|
|
serverHasAESGCM bool
|
|
|
|
|
expectedCipher uint16
|
2020-10-15 18:32:20 -07:00
|
|
|
}{
|
|
|
|
|
{
|
|
|
|
|
name: "server has hardware AES, client doesn't (pick ChaCha)",
|
|
|
|
|
clientCiphers: []uint16{
|
|
|
|
|
TLS_CHACHA20_POLY1305_SHA256,
|
|
|
|
|
TLS_AES_128_GCM_SHA256,
|
|
|
|
|
},
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
serverHasAESGCM: true,
|
|
|
|
|
expectedCipher: TLS_CHACHA20_POLY1305_SHA256,
|
2020-10-15 18:32:20 -07:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name: "neither server nor client have hardware AES (pick ChaCha)",
|
|
|
|
|
clientCiphers: []uint16{
|
|
|
|
|
TLS_CHACHA20_POLY1305_SHA256,
|
|
|
|
|
TLS_AES_128_GCM_SHA256,
|
|
|
|
|
},
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
serverHasAESGCM: false,
|
|
|
|
|
expectedCipher: TLS_CHACHA20_POLY1305_SHA256,
|
2020-10-15 18:32:20 -07:00
|
|
|
},
|
|
|
|
|
{
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
name: "client prefers AES, server doesn't have hardware (pick ChaCha)",
|
2020-10-15 18:32:20 -07:00
|
|
|
clientCiphers: []uint16{
|
|
|
|
|
TLS_AES_128_GCM_SHA256,
|
|
|
|
|
TLS_CHACHA20_POLY1305_SHA256,
|
|
|
|
|
},
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
serverHasAESGCM: false,
|
|
|
|
|
expectedCipher: TLS_CHACHA20_POLY1305_SHA256,
|
2020-10-15 18:32:20 -07:00
|
|
|
},
|
|
|
|
|
{
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
name: "client prefers AES and sends GREASE, server doesn't have hardware (pick ChaCha)",
|
2020-10-15 18:32:20 -07:00
|
|
|
clientCiphers: []uint16{
|
|
|
|
|
0x0A0A, // GREASE value
|
|
|
|
|
TLS_AES_128_GCM_SHA256,
|
|
|
|
|
TLS_CHACHA20_POLY1305_SHA256,
|
|
|
|
|
},
|
|
|
|
|
serverHasAESGCM: false,
|
|
|
|
|
expectedCipher: TLS_CHACHA20_POLY1305_SHA256,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name: "client prefers AES, server has hardware AES (pick AES)",
|
|
|
|
|
clientCiphers: []uint16{
|
|
|
|
|
TLS_AES_128_GCM_SHA256,
|
|
|
|
|
TLS_CHACHA20_POLY1305_SHA256,
|
|
|
|
|
},
|
|
|
|
|
serverHasAESGCM: true,
|
|
|
|
|
expectedCipher: TLS_AES_128_GCM_SHA256,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name: "client prefers AES and sends GREASE, server has hardware AES (pick AES)",
|
|
|
|
|
clientCiphers: []uint16{
|
|
|
|
|
0x0A0A, // GREASE value
|
|
|
|
|
TLS_AES_128_GCM_SHA256,
|
|
|
|
|
TLS_CHACHA20_POLY1305_SHA256,
|
|
|
|
|
},
|
|
|
|
|
serverHasAESGCM: true,
|
|
|
|
|
expectedCipher: TLS_AES_128_GCM_SHA256,
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for _, tc := range tests {
|
|
|
|
|
t.Run(tc.name, func(t *testing.T) {
|
|
|
|
|
hasAESGCMHardwareSupport = tc.serverHasAESGCM
|
crypto/ecdh: new package
We use crypto/internal/edwards25519/field to implement X25519 directly,
so that golang.org/x/crypto/curve25519 can be dropped from the src
module dependencies, and eventually replaced with a crypto/ecdh wrapper,
removing the need to keep golang.org/x/crypto/curve25519/internal/field
in sync with crypto/internal/edwards25519/field.
In crypto/internal/nistec, we add BytesX to serialize only the x
coordinate, which we'll need for the horrible ECDSA x-coord-to-scalar
operation, too.
In crypto/tls, we replace the ECDHE implementation with crypto/ecdh,
dropping the X25519 special cases and related scaffolding.
Finally, FINALLY, we deprecate the ~white whale~ big.Int-based APIs of
the crypto/elliptic package. •_•) ( •_•)>⌐■-■ (⌐■_■)
Fixes #52182
Fixes #34648
Fixes #52221
Change-Id: Iccdda210319cc892e96bb28a0e7b7123551982c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/398914
Reviewed-by: Fernando Lobato Meeser <felobato@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-04-07 15:15:31 -04:00
|
|
|
pk, _ := ecdh.X25519().GenerateKey(rand.Reader)
|
2020-10-15 18:32:20 -07:00
|
|
|
hs := &serverHandshakeStateTLS13{
|
|
|
|
|
c: &Conn{
|
crypto/tls: make cipher suite preference ordering automatic
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes #45430
Fixes #41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
2021-04-28 01:37:09 -04:00
|
|
|
config: &Config{},
|
|
|
|
|
vers: VersionTLS13,
|
2020-10-15 18:32:20 -07:00
|
|
|
},
|
|
|
|
|
clientHello: &clientHelloMsg{
|
|
|
|
|
cipherSuites: tc.clientCiphers,
|
|
|
|
|
supportedVersions: []uint16{VersionTLS13},
|
|
|
|
|
compressionMethods: []uint8{compressionNone},
|
crypto/ecdh: new package
We use crypto/internal/edwards25519/field to implement X25519 directly,
so that golang.org/x/crypto/curve25519 can be dropped from the src
module dependencies, and eventually replaced with a crypto/ecdh wrapper,
removing the need to keep golang.org/x/crypto/curve25519/internal/field
in sync with crypto/internal/edwards25519/field.
In crypto/internal/nistec, we add BytesX to serialize only the x
coordinate, which we'll need for the horrible ECDSA x-coord-to-scalar
operation, too.
In crypto/tls, we replace the ECDHE implementation with crypto/ecdh,
dropping the X25519 special cases and related scaffolding.
Finally, FINALLY, we deprecate the ~white whale~ big.Int-based APIs of
the crypto/elliptic package. •_•) ( •_•)>⌐■-■ (⌐■_■)
Fixes #52182
Fixes #34648
Fixes #52221
Change-Id: Iccdda210319cc892e96bb28a0e7b7123551982c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/398914
Reviewed-by: Fernando Lobato Meeser <felobato@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-04-07 15:15:31 -04:00
|
|
|
keyShares: []keyShare{{group: X25519, data: pk.PublicKey().Bytes()}},
|
2024-05-18 19:35:39 +02:00
|
|
|
supportedCurves: []CurveID{X25519},
|
2020-10-15 18:32:20 -07:00
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
err := hs.processClientHello()
|
|
|
|
|
if err != nil {
|
|
|
|
|
t.Errorf("pickCipherSuite failed: %s", err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if tc.expectedCipher != hs.suite.id {
|
|
|
|
|
t.Errorf("unexpected cipher chosen: want %d, got %d", tc.expectedCipher, hs.suite.id)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-08-01 12:18:31 +01:00
|
|
|
|
2022-04-07 15:13:47 +09:00
|
|
|
// TestServerHandshakeContextCancellation tests that canceling
|
2021-03-28 16:39:47 +01:00
|
|
|
// the context given to the server side conn.HandshakeContext
|
|
|
|
|
// interrupts the in-progress handshake.
|
2020-08-01 12:18:31 +01:00
|
|
|
func TestServerHandshakeContextCancellation(t *testing.T) {
|
|
|
|
|
c, s := localPipe(t)
|
|
|
|
|
ctx, cancel := context.WithCancel(context.Background())
|
2021-03-28 16:39:47 +01:00
|
|
|
unblockClient := make(chan struct{})
|
|
|
|
|
defer close(unblockClient)
|
2020-08-01 12:18:31 +01:00
|
|
|
go func() {
|
|
|
|
|
cancel()
|
2021-03-28 16:39:47 +01:00
|
|
|
<-unblockClient
|
|
|
|
|
_ = c.Close()
|
2020-08-01 12:18:31 +01:00
|
|
|
}()
|
|
|
|
|
conn := Server(s, testConfig)
|
2021-03-28 16:39:47 +01:00
|
|
|
// Initiates server side handshake, which will block until a client hello is read
|
|
|
|
|
// unless the cancellation works.
|
2020-08-01 12:18:31 +01:00
|
|
|
err := conn.HandshakeContext(ctx)
|
|
|
|
|
if err == nil {
|
|
|
|
|
t.Fatal("Server handshake did not error when the context was canceled")
|
|
|
|
|
}
|
|
|
|
|
if err != context.Canceled {
|
|
|
|
|
t.Errorf("Unexpected server handshake error: %v", err)
|
|
|
|
|
}
|
|
|
|
|
if runtime.GOARCH == "wasm" {
|
|
|
|
|
t.Skip("conn.Close does not error as expected when called multiple times on WASM")
|
|
|
|
|
}
|
|
|
|
|
err = conn.Close()
|
|
|
|
|
if err == nil {
|
|
|
|
|
t.Error("Server connection was not closed when the context was canceled")
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// TestHandshakeContextHierarchy tests whether the contexts
|
|
|
|
|
// available to GetClientCertificate and GetCertificate are
|
|
|
|
|
// derived from the context provided to HandshakeContext, and
|
2021-04-09 03:48:14 +00:00
|
|
|
// that those contexts are canceled after HandshakeContext has
|
2020-08-01 12:18:31 +01:00
|
|
|
// returned.
|
|
|
|
|
func TestHandshakeContextHierarchy(t *testing.T) {
|
|
|
|
|
c, s := localPipe(t)
|
|
|
|
|
clientErr := make(chan error, 1)
|
|
|
|
|
clientConfig := testConfig.Clone()
|
|
|
|
|
serverConfig := testConfig.Clone()
|
|
|
|
|
ctx, cancel := context.WithCancel(context.Background())
|
|
|
|
|
defer cancel()
|
|
|
|
|
key := struct{}{}
|
|
|
|
|
ctx = context.WithValue(ctx, key, true)
|
|
|
|
|
go func() {
|
|
|
|
|
defer close(clientErr)
|
|
|
|
|
defer c.Close()
|
|
|
|
|
var innerCtx context.Context
|
|
|
|
|
clientConfig.Certificates = nil
|
|
|
|
|
clientConfig.GetClientCertificate = func(certificateRequest *CertificateRequestInfo) (*Certificate, error) {
|
|
|
|
|
if val, ok := certificateRequest.Context().Value(key).(bool); !ok || !val {
|
|
|
|
|
t.Errorf("GetClientCertificate context was not child of HandshakeContext")
|
|
|
|
|
}
|
|
|
|
|
innerCtx = certificateRequest.Context()
|
|
|
|
|
return &Certificate{
|
|
|
|
|
Certificate: [][]byte{testRSACertificate},
|
|
|
|
|
PrivateKey: testRSAPrivateKey,
|
|
|
|
|
}, nil
|
|
|
|
|
}
|
|
|
|
|
cli := Client(c, clientConfig)
|
|
|
|
|
err := cli.HandshakeContext(ctx)
|
|
|
|
|
if err != nil {
|
|
|
|
|
clientErr <- err
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
select {
|
|
|
|
|
case <-innerCtx.Done():
|
|
|
|
|
default:
|
2021-04-09 03:48:14 +00:00
|
|
|
t.Errorf("GetClientCertificate context was not canceled after HandshakeContext returned.")
|
2020-08-01 12:18:31 +01:00
|
|
|
}
|
|
|
|
|
}()
|
|
|
|
|
var innerCtx context.Context
|
|
|
|
|
serverConfig.Certificates = nil
|
|
|
|
|
serverConfig.ClientAuth = RequestClientCert
|
|
|
|
|
serverConfig.GetCertificate = func(clientHello *ClientHelloInfo) (*Certificate, error) {
|
|
|
|
|
if val, ok := clientHello.Context().Value(key).(bool); !ok || !val {
|
|
|
|
|
t.Errorf("GetClientCertificate context was not child of HandshakeContext")
|
|
|
|
|
}
|
|
|
|
|
innerCtx = clientHello.Context()
|
|
|
|
|
return &Certificate{
|
|
|
|
|
Certificate: [][]byte{testRSACertificate},
|
|
|
|
|
PrivateKey: testRSAPrivateKey,
|
|
|
|
|
}, nil
|
|
|
|
|
}
|
|
|
|
|
conn := Server(s, serverConfig)
|
|
|
|
|
err := conn.HandshakeContext(ctx)
|
|
|
|
|
if err != nil {
|
|
|
|
|
t.Errorf("Unexpected server handshake error: %v", err)
|
|
|
|
|
}
|
|
|
|
|
select {
|
|
|
|
|
case <-innerCtx.Done():
|
|
|
|
|
default:
|
2021-04-09 03:48:14 +00:00
|
|
|
t.Errorf("GetCertificate context was not canceled after HandshakeContext returned.")
|
2020-08-01 12:18:31 +01:00
|
|
|
}
|
|
|
|
|
if err := <-clientErr; err != nil {
|
|
|
|
|
t.Errorf("Unexpected client error: %v", err)
|
|
|
|
|
}
|
|
|
|
|
}
|