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 <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
