If you are able to install a new trust anchor, then you should be able to use the enterprise configuration mechanisms in browsers to disable ECH.
-Ekr On Fri, Oct 7, 2022 at 8:40 PM Safe Browsing <safebrowsing...@gmail.com> wrote: > Hi Rich, > > When I say “authoritative”, I mean it in the true TLS sense, in the way > that I believe the ECH draft also suggests and requires. > > In other words, the middlebox serves a cert to the client that is > cryptographically valid for the said public name of the client facing > server. > > How can that be when the client facing server guards its private key > properly? By re-signing the server certificate on the middlebox with a > private key, local to the middle box only, for which the corresponding > certificate has been installed in the trust store of the client, before > sending it on to the client. Only after the original server certificate > has been validated properly on the middlebox, of course. Message digests > being managed accordingly/appropriately. > > That is a very typical setup for most (all?) TLS inspection devices (next > gen firewalls and such). > > Thus this part of ECH, requiring the middlebox to be authoritative for the > server, is well understood and prolifically exercised in inspected TLS > sessions today. What is new is that these connections can now fail/close, > in the “securely disabling ECH” case, and the onus is on the TLS client, > not the application, to retry the connection without ECH. > > I am after such a client, if one exists already. > > Thank you. > > Sent from my phone > > On Oct 7, 2022, at 11:41 AM, Salz, Rich <rs...@akamai.com> wrote: > > > > > > - Client <-> *Middlebox* <-> Client-facing server <-> Backend server > > > > - With "Middlebox" really meaning a middlebox like a firewall or > similar. > > > > The middlebox is not allowed to modify traffic between the client and the > server. Doing so would mean that the packets the client sent are not the > ones that the server received, and the two message digests would disagree. > (If you think about things, it **has** to be this way, otherwise TLS > would not be able to provide integrity guarantees.) > > > > - From the draft, ECH seems to be designed to still allow successful > TLS connection establishment if the encrypted_client_hello extension is > dropped from the ClientHello on a conforming middlebox. Provided that the > middlebox is authoritative for the client-facing server's public name, as > reported/delivered by DNS to the client. We can assume that this is the > case here. > > > > I do not understand what you mean by this. The word “authoritative” is > used to mean that it has a certificate and keypair and can do TLS > termination. DNS giving the client a particular IP address is not > authoritative. It can be confusing because DNS terminology uses > authoritative to mean that a particular entity can prepare data used for > DNS responses. But it is not authoritative in the TLS sense. > > > > I think your questions can be answered with those two overall corrections > above. If not, please continue the thread. (And feel free to repost from > your note since I trimmed for brevity.) > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
