[TLS] Re: ECH Proxy Mode

[A A <[e-mail]>]

- all

 

I don't think need to use random, we can use Session ID, which is deprecated since TLS 1.3. Random is used to derive master key, AFAIK.

 

 

11.09.2024, 17:29, "涛叔" <hi=[e-mail]>:

Dear Raghu,

 

The MiTM solution may works for self-host, because the user controls both the browser and

the proxy node. However, it is not acceptable for public proxy, because the middle node

could see all the plain traffic between the user and the target, which is a far more serious

problem than the leak of SNI.

 

The only obstacle of my envisioned ECH-based SNI proxy is that the server side accept confirmation

must be placed in the SH.random field, which will be further used to generate the master secret.

As a result, the middle proxy node can't respond this confirmation on  behalf of the backed server.

 

The ECH-based SNI proxy is just a possible by-product of ECH. It's not a big problem if we

can not implement such proxy. However, my real concern is the deployment rate of the current draft.

 

The current design requires both the client and backend server to be modified to be ECH-aware.

 

For solo web site, as the administrator has the full control and there is no inter node, they may

upgrade quickly.

 

But there are far too many sites using some proxy service, for example, Cloudflare, AWS ALB, etc.

For stability consideration, service provider like AWS does not upgrade their infrastructure very quickly.

If web site use AWS LB as their TLS terminal edge server, it may cost too long time to deploy ECH.

 

Apart from technical issues, deploy ECH does almost no benefit to this business. I doubt if they are

interested in ECH.

 

On the other hand, let's recall the origin of the server side confirmation.

 

According to the original discussion https://github.com/tlswg/draft-ietf-tls-esni/issues/274" rel="noopener noreferrer nofollow">https://github.com/tlswg/draft-ietf-tls-esni/issues/274

 

> In the current spec, the server provides no indication of whether the inner or outer ClientHello (CH) was used. This means the client must do trial decryption to make this determination, which creates complexity and potentially raises security concerns. 

 

It seems that the main consideration of the accept_confirmation is just to simplify the client side logic.

This simplification may cause a slow deployment of ECH. I am wondering if it really make sense.

 

The ECH is very complicated itself. The purpose of such an complicated protocol is to

protect the privacy of the Internet, so we should in favor of the easy deployment instead of

of the simplified implementation. If the simplification is the first consideration, the ECH should not

be considered at all.

 

On Sep 11, 2024, at 15:16, Raghu Saxena <[e-mail]> wrote:

 

By the way, you may be interested in this project: https://github.com/quininer/nosni-proxy" rel="noopener noreferrer nofollow">https://github.com/quininer/nosni-proxy , which has a similar idea, but instead to completely strip SNI, and relying on TLS interception. One could think of an alternative, basically like the Cloudflare MiTM model you mentioned, except self-hosted with certificates manually trusted. Then the DoH server would return the IP of this server, which would allow an ECH-TLS connection to it, but then performs a separate TLS handshake with the real origin server.

It is not as elegant as what you mentioned since now there is a need to manually trust certificates, but could still be an approach.

,

_______________________________________________
TLS mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]