If one connects to a proxy, shouldn't the SNI point to the name of the
proxy?
-- Christian Huitema
On 10/18/2022 8:49 PM, Hannes Tschofenig wrote:
Giving someone, other than those managing the endpoints, the ability
to disable a security feature like ECH is problematic.
If I read your email correctly then I believe that’s what you are
suggesting. I hope I am missing something.
Ciao
Hannes
*From:* TLS <[email protected]> *On Behalf Of * Safe Browsing
*Sent:* Wednesday, October 19, 2022 4:56 AM
*To:* Eric Rescorla <[email protected]>
*Cc:* [email protected]
*Subject:* Re: [TLS] Securely disabling ECH
Hi Eric,
Picking up on your (earlier) reply here.
Though it would be possible to adjust the setting in browsers
(disabling ECH), this is not an ideal/sufficient method of disabling ECH.
Some reasons it is not sufficient:
- Not all TLS clients are browsers
- Not all browsers (or other TLS clients) may implement this ability
- In a multi-browser environment it means that it needs to be
configured in more than one place, each using a different method of
achieving the same (cumbersome)
- even worse if there are other, non-browser, ECH supporting clients
present for which ECH needs to be disabled
It seems therefore that the ideal place to achieve this is within the
protocol itself. Making ECH disabling client agnostic.
The draft does consider this by allowing ECH to be disabled - as
discussed in this thread. Albeit at the cost of an extra round trip.
However, the connection retry logic in the presence of ECH disabling
is currently optional.
The draft states, in Section 8.2:
“ this may trigger the retry logic”
It seems this text must change to:
“ this MUST trigger the retry logic”
In order to ensure functional connections in a TLS client agnostic
manner, in the presence of protocol level ECH disabling.
I would appreciate your thoughts/input.
On Oct 8, 2022, at 7:41 PM, Eric Rescorla <[email protected]> wrote:
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
<[email protected]> 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 <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose
the contents to any other person, use it for any purpose, or store or
copy the information in any medium. Thank you.
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
