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> On Behalf Of Safe Browsing >>> Sent: Wednesday, October 19, 2022 4:56 AM >>> To: Eric Rescorla <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 list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
