DEfO project (defo.ie), 2021-12-03 contact: info@defo.ie
The DEfO project implemented Encrypted ClientHello (ECH) support for OpenSSL and Conscrypt, caried out interoperability testing of those implementations, and also used those libraries to ECH-enable various web servers and clients. We deployed services using these web servers and the DNS infrastructure required to supoort automated key upated for the HTTPS RRs asociated with those services. Here we provide a short overview of that work in order to help with larger scale experiments and with further development of the ECH specification.
As part of the DEfO project, we ECH-enabled two important TLS libraries:
We ECH-enabled implemented the following TLS client applications:
s_client - this client application comes as part
of the OpenSSL build but is commonly used for testing and as an
extremely simple scriptable TLS client.We ECH-enabled implemented the following web servers:
s_server - this example server application is
part of the OpenSSL build and is commonly used for testing
and experimentation.Amongst the test tooling we developed are:
make test targets for HPKE round-tripping, ECH key pair
reading and use of ECH between clients and servers.We deployed the non-trivial DNS infrastructure required to support ECH and hourly key rotation for the defo.ie domain. Other than for ECH key rotation that only required our standard DNS services (incl. DNSSEC).
For ECH key rotation we documented our implementation in an Internet-draft that we have proposed be standardised. (We also documented a PEM file format in another Internet-draft.)
We saw the following issues that could benefit from further work to ease deployment of ECH:
For haproxy, it makes sense to handle split-mode ECH using "tcp" mode (as opposed to "http" mode which is suitable when haproxy is acting as the TLS server endpoint); it appears that haproxy in tcp mode can only examine or change the first message in a connection (presumably for performance reasons, but that's still TBC) - the result may be that HRR can't easily work in one setup where it might be most relevant.
There can sometimes be a lack of clarity as to which software component should be responsible for choosing to attempt real (i.e. non-GREASEd) ECH, and hence to be responsible for the additional DNS queries required to acquire an ECHConfig. For libraries like OpenSSl and boringssl it clearly only makes sense for that decision (and hence any new DNS handling code) to be outside the library. For a browser, it as clearly makes sense for that code to be in the browser application layer. With "middleware" though, such as OkHTTP or Conscrypt it can be hard to know which is the correct decision.
The new DNS code required for handling HTTPS RRs is not too complex but the full generality of SVCB is exteremely complex. Adding such complexity (and associated caching) is a major change for clients like curl that have to date only had to have a very simple model for DNS - essentially only querying A/AAAA and having almost trivial caching in the application itself.
The client implementation of ECH is relatively complex in that it "touches" the TLS state machine in many ways, and hence requires changes in a lot of places. As well as increasing the cost of implementing this also increases the costs associated with testing and upstreaming.
ECH is demonstrably implementable and can be deployed. We don't yet know if new issues will become apparent as large-scale experiments are carried out, but we should know that in the next few months.