Re: [TLS] Securely disabling ECH

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 <safebrowsingnow@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 <rsalz@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
>