Open monkwire opened 1 month ago
Related Issues and Documentation
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
I believe the change on resumption is actually expected, see https://boringssl.googlesource.com/boringssl/+/refs/heads/master/ssl/test/runner/runner.go#8517.
Why this doesn't happen on 1.3 is not immediately clear to me, but may be because we are storing the state in the session ticket and restoring it, but not doing that consistently?
Ah, yup, in <1.3 we allow the server to override the stored SCTs: https://go.googlesource.com/go/+/refs/heads/master/src/crypto/tls/handshake_client.go#925, but in 1.3 we do not: https://go.googlesource.com/go/+/refs/heads/master/src/crypto/tls/handshake_client_tls13.go#477.
That should probably be consistent, I have no memory of why it is this way.
Oh it's because SCTs are not sent in the hello in 1.3, which I documented in the CL description when we implemented this https://go-review.googlesource.com/c/go/+/234237.
Ahh I see. Since BoringSSL always passes in an expected SCT value as a flag argument, how should OnResume tests be handled in bogo_shim_test
? Does it make sense to explicitly allow for SCTs to be either what BoringSSL passes in ([][]uint8{[]uint8{0x5, 0x6, 0x7, 0x8}}
) or what BoringSSL passes in with the last byte incremented ([][]uint8{[]uint8{0x5, 0x6, 0x7, 0x9}}
?
BoringSSL OnResume Tests:
var testSCTList = []byte{0, 6, 0, 4, 5, 6, 7, 8}
// ...
// The SCT extension did not specify that it must only be sent on resumption as it
// should have, so test that we tolerate but ignore it.
testCases = append(testCases, testCase{
protocol: protocol,
name: "SendSCTListOnResume-" + suffix,
config: Config{
MaxVersion: ver.version,
Credential: rsaCertificate.WithSCTList(testSCTList),
Bugs: ProtocolBugs{
SendSCTListOnResume: differentSCTList,
},
},
flags: []string{
"-enable-signed-cert-timestamps",
"-expect-signed-cert-timestamps",
base64FlagValue(testSCTList),
},
resumeSession: true,
})
Probably reasonable to match the boringssl behavior and ignore the SCT extension on resume. That change should be a separate CL for crypto/tls.
@davidben the runner.go comment seems confusing, did you mean that the SCT extension should not be sent on resumption, rather than only sent on resumption?
Change https://go.dev/cl/599615 mentions this issue: crypto/tls: support signed cert timestamps flags in bogo_shim_test
Change https://go.dev/cl/597195 mentions this issue: crypto/tls: support signed cert timestamps flags in bogo_shim_test
Whoops, yeah, I think I collided "must only be sent on full handshakes" and "must not be sent on resumption" in that comment.
Go version
go version go1.23 darwin/arm64
Output of
go env
in your module/workspace:What did you do?
When running TestBogoSuite with the flags
-enable-signed-cert-timestamps
and-expect-signed-cert-timestamps
, the last byte of an SCT increments by one duringSendSCTListOnResume-
tests for connections using TLS 1.0, TLS 1.1, and TLS 1.2. This does not happen when TLS 1.3 is used.Here are the changes I made to see this:
What did you see happen?
The SCTs change from
[][]uint8{[]uint8{0x5, 0x6, 0x7, 0x8}}
to[][]uint8{[]uint8{0x5, 0x6, 0x7, 0x9}}
when resume count is 1 (only duringOnResume
tests).go test ./crypto/tls -run "TestBogoSuite/(SignedCertificateTimestampList|SendSCTListOnResume)" -v
produces:What did you expect to see?
I expect the SCTs not to change on resume.
Additionally, I expect the behavior of TLS 1.0, 1.1, and 1.2 to be the the same as behavior for TLS 1.3.