crypto/tls: SCTs increment by one byte on resume during tls 1.0, tls 1.1, and 1.2 BoringSSL OnResume tests #68516
Comments
|
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 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: |
|
Change https://go.dev/cl/597195 mentions this issue: |
|
Whoops, yeah, I think I collided "must only be sent on full handshakes" and "must not be sent on resumption" in that comment. |
cherrymui
added
the
NeedsInvestigation
Go version
go version go1.23 darwin/arm64
Output of
go envin your module/workspace:What did you do?
When running TestBogoSuite with the flags
-enable-signed-cert-timestampsand-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 duringOnResumetests).go test ./crypto/tls -run "TestBogoSuite/(SignedCertificateTimestampList|SendSCTListOnResume)" -vproduces: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.
The text was updated successfully, but these errors were encountered: