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
