s2n-tls server reports signature scheme for TLS1.2 session resumption

[lrstewart]

Security issue notifications

If you discover a potential security issue in s2n we ask that you notify
AWS Security via our vulnerability reporting page. Please do not create a public github issue.

Problem:

Like #5477, we also incorrectly report a server signature for TLS1.2 session resumption.

See s2nd output:

s2nd localhost 8000
libcrypto: AWS-LC 1.49.1
Listening on localhost:8000
CONNECTED:
Handshake: NEGOTIATED|FULL_HANDSHAKE|TLS12_PERFECT_FORWARD_SECRECY|WITH_SESSION_TICKET
Client hello version: 33
Client protocol version: 33
Server protocol version: 33
Actual protocol version: 33
Server name: localhost
Curve: secp256r1
Cipher negotiated: ECDHE-RSA-AES128-GCM-SHA256
Server signature negotiated: RSA-PSS-RSAE+SHA256
Early Data status: NOT REQUESTED
JA3: 736793ccdc2f357bd358e78e28f849ba
Wire bytes in: 302
Wire bytes out: 3024
s2n is ready
CONNECTED:
Handshake: NEGOTIATED
Client hello version: 33
Client protocol version: 33
Server protocol version: 33
Actual protocol version: 33
Server name: localhost
Curve: secp256r1
Cipher negotiated: ECDHE-RSA-AES128-GCM-SHA256
Server signature negotiated: RSA-PSS-RSAE+SHA256 <--- NOT CORRECT
Resumed session
Early Data status: NOT REQUESTED
JA3: 736793ccdc2f357bd358e78e28f849ba
Wire bytes in: 365
Wire bytes out: 147
s2n is ready

As opposed to s2nc:

s2nc localhost 8000 -r
libcrypto: AWS-LC 1.49.1
CONNECTED:
Handshake: NEGOTIATED|FULL_HANDSHAKE|TLS12_PERFECT_FORWARD_SECRECY|WITH_SESSION_TICKET
Client hello version: 33
Client protocol version: 33
Server protocol version: 33
Actual protocol version: 33
Server name: localhost
Curve: secp256r1
Cipher negotiated: ECDHE-RSA-AES128-GCM-SHA256
Server signature negotiated: RSA-PSS-RSAE+SHA256
Early Data status: NOT REQUESTED
Wire bytes in: 3024
Wire bytes out: 302
s2n is ready
Connected to localhost:8000
CONNECTED:
Handshake: NEGOTIATED
Client hello version: 33
Client protocol version: 33
Server protocol version: 33
Actual protocol version: 33
Server name: localhost
Curve: NONE
Cipher negotiated: ECDHE-RSA-AES128-GCM-SHA256
Server signature negotiated: None+None <--- CORRECT
Resumed session
Early Data status: NOT REQUESTED
Wire bytes in: 147
Wire bytes out: 365
s2n is ready

This is not a problem for TLS1.3. I confirmed that with both the code and s2nc/s2nd.

Need By Date:

None, no customer reach outs. I think this is just a visibility / logging / metrics issue.

Solution:

Like #5477, don't choose a signature scheme if resuming a session. It might be a little trickier though, since I don't think we actually decrypt + confirm the session until after we choose a signature scheme. We might have to reset the signature scheme instead.

Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

• RFC links: Links to relevant RFC(s)
• Related Issues: Link any relevant issues
• Will the Usage Guide or other documentation need to be updated?
• Testing: How will this change be tested? Call out new integration tests, functional tests, or particularly interesting/important unit tests.
  • Will this change trigger SAW changes? Changes to the state machine, the s2n_handshake_io code that controls state transitions, the DRBG, or the corking/uncorking logic could trigger SAW failures.
  • Should this change be fuzz tested? Will it handle untrusted input? Create a separate issue to track the fuzzing work.

Out of scope:

Is there anything the solution will intentionally NOT address?