[TLS] ECH Proxy Mode

[涛叔 <[e-mail]>]

Hi,

In the split mode of the current draft of ECH, both the client-facing
server and the backend server are needed to be ECH-aware. As upon the
client-facing server decrypted the ClientHelloOut, it will forward the
ClientHelloInner to the backend server, and waiting the backend's
ServerHello with random embed with the accept_confirmation.

If you want to deploy ECH, you have to upgrade both the client-facing
server and the backend server. However, it is not an easy task to upgrade
all the backend server in one day. So I am wondering if it is possible
to adjust the design to allow the deployment without altering the
backend server.

Suppose we use the following topology:

browser <-----> ECH-aware Client-facing server <------> normal TLS backend server

For any TLS backend server, for example, https://example.com,

We only upgrade the browser and the client-facing server. The browser
fetch the ECH config from DNS, and encrypt the ClientHello according
the current draft design. The client-facing decrypt the ClientHelloInner and
use it as the normal ClientHello to do the TLS handshake to the normal TLS
backend server without any ECH extension.

Upon the normal TLS backend server receive the decrypted ClientHello, it response
the normal ServerHello to the client-facing server.

After receiving the ServerHello from the backend server, the client-facing server
need to response the accept_confirmation to the browser. This is the design changes
I propose to change. Because the current draft requires the backed server generate
the accept_confirmation bytes and embed it into the random of ServerHello, which
can not be changed by the client-facing server.

In order to support ECH for normal existing TLS server, we may let the client-facing
response the accept_confirmation on behalf of the backend server, which means we
can not use the random field of ServerHello to store the accept_confirmation, because
changing it will abort the TLS handshake.

So is it possible to transfer the accept_confirmation in some plain text extensions
like Key Share, or other dedicated extension?

If it is possible, we can deploy ECH by only upgrading the browser and client-facing
server without require change all the existing backend server.

This idea was derived from my attempt to implement encrypted TLS SNI Proxy. The SNI
does not only expose privacy information, many ISP use it to block certain web site.
Even though the current draft of ECH works to protect the ClientHello, it can only
protect the sites that deployed the ECH.

If we can adjust the current design and let the client-facing generate and response
the accept_confirmation signal, we can make ECH everywhere without upgrading any of
current TLS backend server. Which means the client-facing can work as an encrypted
TLS SNI Proxy.

Please consider my proposal and give your comments

Thanks.