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-harmful 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
OpenPGP_0xA1E21ED06A67D28A.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
