Re: [TLS] Securely disabling ECH

Hi,

provided the middlebox is authoritative (has a valid TLS certificate for 
the server in question), then Firefox will carry out the described retry 
behavior. Currently all ECH support is disabled behind a pref by 
default, but you can enable it by setting network.dns.echconfig.enabled 
to true. You will also need to enable DNS over HTTPS and browse to a 
domain with an ECH config.

Best,
Dennis

On 08/10/2022 04:40, Safe Browsing 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