Pull Request Dependencies

This is based on #3064

Description

This applies preparatory refactorings to (hopefully) make the initial pull request towards a TLS 1.3 server easier to review.

Overview of Changes

Client Hello Marshalling

The wire-format of the client hello message did not change between TLS 1.2 and 1.3. I.e. we can reuse the parsing and serialization code. Similarly to the Server_Hello (already merged in TLS 1.3 client) this introduces a "dumb" Client_Hello_Internal class that encapsulates the marshalling.

Client_Hello_13 gains a ::parse() factory method that decides whether it deals with a 1.2 or 1.3 client hello and returns the appropriate type in a std::variant<>. The constructor of Client_Hello_13 already contains some of the local sanity checks required in RFC 8446.

Removal of the Server_Impl Interface

This interface class was introduced way back by the Elektrobit folks. It turned out that it is not needed as all its defined methods are either TLS 1.2-specific or better defined in the generic Channel_Impl class. Similarly, we removed this Client_Impl counter-part during the TLS 1.3 client implementation.

application_protocol() vs. next_protocol()

To the best of my understanding, they have the same semantics. Hence, I removed the next_protocol() method from the lower-level code. The user-facing method (in TLS::Server) is now just a delegate to application_protocol() and is deprecated. Or should we remove it right away, @randombit?

Policy::choose_key_exchange_group()

This callback now has an additional parameter allowing applications to take the peer's offered groups into account. This way an application can define when to fall back to a Hello Retry Request even when mutually acceptable groups were already offered. One potential use case: A client might advertise support for a PQC exchange group but offered standard ECDH only. With this addition, the server could enforce PQ crypto at its own discretion.

Signature_Algorithms and Signature_Algorithms_Cert extensions

While we don't fully honor the "signature_algorithms_cert" semantics just yet, we must be able to parse it. Both extensions share the same schema, hence this tries to unify their marshalling code better. See also #2990.

Cipher State allows to receive data before ingesting the client Finished message

The server may start sending records encrypted under its "application traffic secret" even before receiving the client's Finished message. The Cipher_State must be able to handle this by deriving the server's traffic secrets ahead, while deferring the derivation of the client's secrets until after receiving the client's Finished. This was found via BoGo tests that expect to exchange a protected Alert record in this meta-situation.

Server_Name_Indication can be rendered by the Server

According to RFC 6066, the server may send an empty SNI extension as acknowledgement:

Servers that receive a client hello containing the "trusted_ca_keys"
extension MAY use the information contained in the extension to guide
their selection of an appropriate certificate chain to return to the
client. In this event, the server SHALL include an extension of type
"trusted_ca_keys" in the (extended) server hello. The
"extension_data" field of this extension SHALL be empty.

generalize_to<> Helper

This is a helper function that allows transforming a specific std::variant<> type (or individual concrete type) into a super-set. E.g.

using Pet = std::variant<Cat, Dog>;
using Animal = std::variant<Cat, Dog, Bat, Spider, Snake>;
Pet pet = Cat();
Cat cat;
auto animal = generalize_to<Animal>(pet);
auto other_animal = generalize_to<Animal>(cat);

Protocol Version Downgrade

Downgrading can now be explicitly requested by the concrete TLS client/server implementation class. Before, the Channel took a downgrade decision simply by reacting to a Server_Hello_12. This is not possible anymore, because TLS 1.3 servers must be able to downgrade even when receiving a Client_Hello_13 (that explicitly negotiates TLS 1.2 in its "supported_versions" extension).

tls_stream_integration test

This is an integration test of the TLS asio adapter that sets up a test client and test server (as asio streams) and lets them talk to each other via a local TCP connection. We found some races and roadblocks when trying to extend this test with additional configurations using the TLS 1.3 server. This restructures the test's internal steering logic to better handle timeouts. Also, it adds some machinery to allow running the internal test cases with various TLS policies.