Raghu, I certainly am not advocating believing in only SNI by itself, an advanced DPI system will use dozens of metadata features, SNI being only one.
Indeed, in those cases where there is a single service behind an IP address, there is no reason for SNI to be present (although it often is anyway) and can certainly be faked. As I said in my ID you can't rely on client-side software. 99% of clients don't know what they are doing, and won't keep their protections up-to-date. And MiTM of any type is an abomination - we don't want to replace one attack with a worse one. In any case I am talking about a large ISP network, not a small or campus-size one where admins can set up proxies for individual users. Y(J)S -----Original Message----- From: Raghu Saxena <poiasdpoi...@live.com> Sent: Thursday, July 10, 2025 11:50 AM To: tls@ietf.org Subject: [EXTERNAL] [TLS] Re: FW: New Version Notification for draft-stein-tls-ech-considered-harmful-00.txt External Email: Be cautious do not click links or open attachments unless you recognize the sender and know the content is safe Dear Yaakov, I would be careful about relying on plaintext SNI for detecting malicious flows. The SNI parameter is controlled by the client, and can even be ignored by the server. One would think that any decent malware author would either not set the SNI, or just "spoof" it - in which case if threat analysis software is relying on this field, it'd think the flow is legitimate and let is pass, which is probably even worse. In fact, recently when traveling on British Airways, I was able to (ab)use SNI, to use their "Free Messaging WiFi" for arbitrary traffic [0]. In environments where it is essential that network administrators inspect users' traffic to detect malicious flows, I think the better solution is to install MiTM CAs on client, which then allow the network admin to decrypt TLS and inspect the traffic. If this is then considered as an invasion of privacy in that setting, I'd argue inspecting SNI is the same; the client would rather hide it if they can. In fact, personally, I think browser's behavior to set SNI by default is actually harmful to privacy, since there are very popular websites (Top25) that function fine without the SNI extension, yet ISPs (such as "Jio" in India - from my experience) use this leakage to block them. If you want to argue that the users' are "OK" with monitoring of the domains, but not of their entire TLS traffic, then the network admin can setup an HTTP(S) proxy (without MiTM), which would be able to log the domains via the `CONNECT` header, while blocking all other traffic. Once again, if this level of control over client's traffic is not possible, one should rethink if the "admins" should be able to peek into the SNI at all. Regards, Raghu Saxena [0] https://www.saxrag.com/tech/reversing/2025/06/01/BAWiFi.html On 7/2/25 10:43 PM, Yaakov Stein wrote: > Just in case anyone missed this ... > > Y(J)S > > -----Original Message----- > From: internet-dra...@ietf.org <internet-dra...@ietf.org> > Sent: Tuesday, July 1, 2025 4:52 PM > To: Yaakov Stein <yst...@allot.com>; Yaakov Stein <yst...@allot.com> > Subject: New Version Notification for > draft-stein-tls-ech-considered-harmful-00.txt > > A new version of Internet-Draft > draft-stein-tls-ech-considered-harmful-00.txt > has been successfully submitted by Yaakov (J) Stein and posted to the IETF > repository. > > Name: draft-stein-tls-ech-considered-harmful > Revision: 00 > Title: ECH Considered Harmful > Date: 2025-07-01 > Group: Individual Submission > Pages: 7 > URL: > https://www.ietf.org/archive/id/draft-stein-tls-ech-considered-harmful-00.txt > Status: > https://datatracker.ietf.org/doc/draft-stein-tls-ech-considered-harmful/ > HTML: > https://www.ietf.org/archive/id/draft-stein-tls-ech-considered-harmful-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-stein-tls-ech-considered-h > armful > > > Abstract: > > Encrypted Client Hello is designed to enhance personal privacy, in > particular obstructing the ability of communications service > providers (but not Over The Top service providers) to map packet > flows to applications. While mostly ineffective in attaining this > goal, it does severely hamper network-based detection of malicious > flows, thus exposing end-users to various security risks that were > previously avoidable. > > > > The IETF Secretariat > > > This message is intended only for the designated recipient(s). It may contain > confidential or proprietary information. If you are not the designated > recipient, you may not review, copy or distribute this message. If you have > mistakenly received this message, please notify the sender by a reply e-mail > and delete this message. Thank you. > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org This message is intended only for the designated recipient(s). It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you. _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
