The next revision of the IETF-standardized TLS protocol is known as Encrypted ClientHello (ECH) [0] formerly known as Encrypted SNI (ESNI). There is a related standard DNS RR Type known as SVCB or HTTPS [8]. ECH is built on top of TLSv1.3 and completes unfinished work from the TLSv1.3 effort. It is now in draft-13 and there are many implementations that are interoperating. I'm posting to start the discussion about implementing this in OpenJDK. The IETF process is now in the interoperability testing phase, so we now need feedback from implementers.
ECH adds a new key to the TLS exchange, and the recommended way to get that key is from HTTPS/SVCB DNS queries. It is not yet fixed where the right place to handle that DNS query, but it is clear that clients will have to do things differently to support ECH and/or SVCB. The recommended way to use ECH is to get the ECH Config List and IP address info from the same DNS query. This probably means that the DNS query needs to happen first, before creating the SSLSocket.
ECH is working for openssl[2], boringssl[3], nginx, Apache HTTP Server, lighttpd, HAProxy, Conscrypt[4], curl, and more. There is work underway in Firefox [5] and Chromium [6]. It has been sketched out for OkHTTP [7]. Draft versions of ESNI and ECH have been deployed in Firefox releases and some production web services.
Here are some key pieces that need implementing for the client: * HTTPS/SVCB DNS queries for getting ECH Config Lists. * A way to provide ECH Config Lists as bytes to the SSLSocket. * A method to ensure encrypted DNS is used so all metadata is encrypted, and that the DNS resolver is modern enough to handle new RR types. * A callback that gets called whenever ECH negotiation fails and the server offers a "Retry Config". FYI, the IETF TLS WG maintain a page with information about other implementations: https://github.com/tlswg/draft-ietf-tls-esni/wiki/Implementations [0] https://www.ietf.org/archive/id/draft-ietf-tls-esni-13.html [1] https://bugs.python.org/issue45567 [2] https://github.com/openssl/openssl/issues/7482 [3] https://bugs.chromium.org/p/boringssl/issues/detail?id=275 [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1725938 [6] https://bugs.chromium.org/p/chromium/issues/detail?id=1091403 [6] https://github.com/google/conscrypt/issues/730 [7] https://github.com/square/okhttp/issues/6539 [8] https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-07.html [9] https://github.com/sftcd/openssl Below is a draft JEP: ============================================================= Title: TLS Encrypted ClientHello (ECH) Author: Hans-Christoph Steiner Organization: DEfO/Guardian Project Created: 2021/11/22 Type: Feature State: Draft Exposure: Open Scope: SE Component: security-libs/javax.net.ssl Discussion: security-dev@openjdk.java.net Effort: M Summary ------- Implement the TLS Encrypted ClientHello (ECH) Extension to allow more secure and private internet connections when using TLS protocols. Motivation ---------- TLS ECH is the next step in the development of the TLS protocol. It provides significant security improvements over previous versions. Several early implementations from other vendors are already available. Java should support TLS ECH to remain compatible with the latest TLS standards. The JDK should support ECH so that Java clients can use ECH when talking to web services. Since Java web services are often behind other servers which handle terminating TLS, it is less important that the server-side is implemented. There are already many interoperable implementations: * Firefox supports ESNI in releases and is implementing ECH. * Chromium is implementing ECH. * BoringSSL merged working ECH support. * Cloudflare deployed ESNI in production and has working ECH support. There are working development forks of many projects that have been reviewed by the upstream developers. These should be merged once ECH hits RFC status: * Apache HTTP Server * boringssl * Conscrypt * curl * HAProxy * LigHTTPD * nginx * OkHTTP * OpenSSL Description ----------- ECH is an extension to the TLS 1.3 protocol to encrypt sensitive metadata that is currently in plain text in the TLS 1.3 negotiation process. The primary goal of this JEP is a minimal interoperable and compatible TLS ECH implementation. A minimal implementation should support: * Automatic fetching of ECH Config Lists from DNS via HTTPS and SVCB RR Types * API for passing ECH Config Lists (byte arrays) the SSLSocket * Enabling/disabling ECH GREASE * Automatic handling of ECH Retry Configs * SSLServerSocket API for setting and rotating ECH Key and Config * API for generating ECH Key and Config for the server-side Alternatives ------------ In order to provide more complete privacy protections, many setups have to use VPNs and/or encrypted tunnels to reduce metadata leakage to the networks. Testing ------- There are already public web services available that use ECH. There are also other client and server implementations available to test against. Assumptions ----------- A third party TLS 1.3 ECH implementation that supports the RFC is required for interoperability testing. There are already working implementations in openssl, boringssl, and live on Cloudflare. Dependencies ----------- The DNS will work with JNDI using numeric RR Types (e.g. "65" for HTTPS). Ideally, the "HTTPS" and "SVCB" DNS RR Type names would be included in JNDI. Impact ------ * Other JDK components: no impact on other JDK components * Compatibility: no impact on compatibility for older TLS versions * User Interface: no graphic user interface * Portability: the DNS component works with JNDI * Documentation: need to doc the new methods * Internationalization: minimal impact, new error messages and methods * Legal: no legal issue -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556
