They seem to be operating reliably in numerous products/deployments though.
Regardless, Nick brought my attention to Section 8.2, where proxies/middleboxes are not involved, but the same questions are elicited. Thanks, On Thu, Oct 20, 2022 at 12:34 AM Christian Huitema <huit...@huitema.net> wrote: > So called "transparent" proxies relie on lies. The price of lies is of > course brittleness. Configured proxies could be made robust. > > -- Christian Huitema > > On Oct 19, 2022, at 5:55 PM, Safe Browsing <safebrowsing...@gmail.com> > wrote: > > > Hi Christian, > > For transparent proxies, no. > > Thanks > > On Wed, Oct 19, 2022 at 4:51 AM Christian Huitema <huit...@huitema.net> > wrote: > >> 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 <tls-boun...@ietf.org> <tls-boun...@ietf.org> *On Behalf Of * >> Safe Browsing >> *Sent:* Wednesday, October 19, 2022 4:56 AM >> *To:* Eric Rescorla <e...@rtfm.com> <e...@rtfm.com> >> *Cc:* TLS@ietf.org >> *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 <e...@rtfm.com> 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 <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 >> >> 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 listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls >> >>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
