search

xvzcf / tls-interop-runner

Interoperability testing of TLS implementations.
Other
10 stars 13 forks source link

"ech-reject" test case and expected number of connections #27

Closed cjpatton closed 3 years ago

cjpatton commented 3 years ago

We will soon want to add a test case for exercising the rejection codepath for ECH. In this setting, the client offers the ECH extension encrypted using a configuration the server doesn't recognize. In this case, the server terminates the connection with a fallback certificate --- the "client-facing" certificate, in ECH parlance --- and transmits an acceptable ECH config in its EncryptedExtensions message. The client is then expected to abort the connection with an "ech_required" alert and retry the connection with the new configuration.

This test case raises questions that we haven't fully addressed.

  1. Currently, the boringssl and cloudflare-go servers quit after one connection attempt. On the other hand, rustls and nss (#25) stay open after the first connection is torn down. Is it desirable to have the server quit after some number of connection attempts, perhaps a number specified by the test case?
  2. Handling more than one connection adds a bit of complexity, especially if we decide to inspect the protocol transcript to determine whether a given test succeeded (as in #24). Perhaps we should decide that the scope of each test case is a single run of the protocol? This would reasonable for the ECH rejection test case, since checking that rejection worked properly amounts to checking that the client aborted with the proper alert.
cjpatton commented 3 years ago

FWIW, my preference would be to quit after one connection attempt. This avoids the need to manage complexity we don't need right now.

chris-wood commented 3 years ago

FWIW, my preference would be to quit after one connection attempt. This avoids the need to manage complexity we don't need right now.

I concur. I think we can adequately test this feature with only a single connection. (Check for the alert, as you suggest, and check that the retry config is sent.) If we need to handle more than one connection for other use cases, we can revisit this in the future.

cjpatton commented 3 years ago

In that spirit, we have the following TODOs:

  1. Modify the nss and rustls endpoints so that the sever quits after one handshake attempt.
  2. Create "ech-reject" test.

I'll work on PRs for these this week.

cjpatton commented 3 years ago

This is done!