Unit Tests for "dummy" EncryptedClientHello

[alexw91]

Problem:

Some TLS Clients (Browsers) are sending dummy EncryptedClientHello values (filled with a stream of 0xFF bytes) to all TLS server endpoints they connect to so that ISP's and middleboxes can't just block all TLS ClientHellos that send an EncryptedClientHello extension.

Need By Date:

None

Solution:

s2n-tls server already correctly handles this case by ignoring unknown TLS extensions, but we should add an explicit unit test that ensures we don't regress on this behavior, and verifies that s2n-tls ignores invalid ECH extensions.

Requirements / Acceptance Criteria:

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

• RFC links: https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni
• Related Issues: Add support for EncryptedClientHello #4231
• 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? No
  • Should this change be fuzz tested? No

Out of scope:

Supporting EncryptedClientHello extension

[maddeleine]

The dummy encrypted client hellos are actually filled with random bytes, not a stream of 0xFF bytes. They are by definition indistinguishable from valid encrypted client hellos, to prevent middleboxes from differentiating the valid ECHs from the dummy ECHs.

[jmayclin]

Alternate thought: this could be a known-value test. E.g. take the ClientHello supplied by modern browsers (which includes a dummy ECH extension) and replay it against s2n-tls.