Discussed a few days ago here on HN, and described by ‘ivanr’ as “misusing TLS session IDs, but the technique doesn't work reliably and it's not secure”:
Indeed, it's a misuse of TLS session IDs for pervasive surveillance. The early web application firewalls also used TLS session IDs to better understand clients, for example correlating the observed values with HTTP session identifiers. I believe that many intrusion detection systems today support rich parsing of TLS traffic to enhance their operation.
Back on TLS, there's are several other ways in which it leaks information that could be used for surveillance. Say, a decade ago, back when revocation checking with OCSP used to be much more widely supported, you could track someone's browsing habits by observing which OCSP responders they talked to. OCSP responses are signed, but the traffic is otherwise not encrypted. Given that most certificates were (and still are) issued by a handful of CAs, you only needed to listen for global traffic at a small number of points. Of course, the fact that OCSP traffic is not encrypted further increases the amount of information available for fingerprinting.
Then there is client fingerprinting at TLS level, which is possible because TLS is actually a mix of protocols, cipher suites, extensions, and various other parameters. ClientHello messages (which are used to initiate TLS handshakes) leak a lot of information that can be converted to useful signals for fingerprinting.
Even at a single web site level, information is leaked via TLS record (i.e., packet) length. A careful observer can look at the record lengths and deduce which resources (e.g., pages, images) are downloaded.
What would this tracking mean in regards to following the EU ePrivacy directive? My understanding is that session resumption mechanisms could be used to track users by capturing the session ID and associating it with the user's IP address, it should follow that the use of such devices should be allowed only for legitimate purposes, with the knowledge of the users concerned?
"(24) Terminal equipment of users of electronic communications networks and any information stored on such equipment are part of the private sphere of the users requiring protection under the European Convention for the Protection of Human Rights and Fundamental Freedoms. So-called spyware, web bugs, hidden identifiers and other similar devices can enter the user's terminal without their knowledge in order to gain access to information, to store hidden information or to trace the activities of the user and may seriously intrude upon the privacy of these users. The use of such devices should be allowed only for legitimate purposes, with the knowledge of the users concerned.
25) However, such devices, for instance so-called "cookies", can be a legitimate and useful tool, for example, in analysing the effectiveness of website design and advertising, and in verifying the identity of users engaged in on-line transactions. Where such devices, for instance cookies, are intended for a legitimate purpose, such as to facilitate the provision of information society services, their use should be allowed on condition that users are provided with clear and precise information in accordance with Directive 95/46/EC about the purposes of cookies or similar devices so as to ensure that users are made aware of information being placed on the terminal equipment they are using."
Source: (24) Terminal equipment of users of electronic communications networks and any information stored on such equipment are part of the private sphere of the users requiring protection under the European Convention for the Protection of Human Rights and Fundamental Freedoms. So-called spyware, web bugs, hidden identifiers and other similar devices can enter the user's terminal without their knowledge in order to gain access to information, to store hidden information or to trace the activities of the user and may seriously intrude upon the privacy of these users. The use of such devices should be allowed only for legitimate purposes, with the knowledge of the users concerned."
The ePrivacy Directive makes a bit of a distinction between data stored on the client, vs network information. Cookies are the former, IP addresses are the latter. From reading the paper, the TLS session ID is stored on the client, and sent to the server. So for the ePD, this is in the same category as cookies, not IP addresses.
The complicating factor is that the TLS session ID has a legitimate purpose, and this tracking is a secondary use of that data. I know what GDPR says about that topic, but I'm less familiar with the ePD. I'm trying to read the law, but it's less approachable than GDPR. I think secondary uses still require strict consent, but I'm not sure.
The UK implementation of ePD is a pretty strict application, only allowing 2 grounds to use a "cookie" (note that means other identifiers like session identifiers, although everyone says cookie.
One grounds is necessity to deliver the packets to you (IP address can be used to route a reply back to you in TCP/IP), and the other grounds is to deliver a feature you explicitly request, and can't be done otherwise (adding an item to your shopping basket, for example).
Neither lets you go beyond functionality, so use of a TLS session identifier to me would be a straightforward breach, if the purpose was anything beyond basic connection setup. At that point, informed, explicit, specific, opt-in consent is required. And contrary to all the illegal cookie walls, you can't require or presume this consent - that isn't consent!
Yet another advantage of using a TLS-capable proxy bound to the loopback. It is very easy to disable session resumption.
A comment above mentioned SNI and some other stuff. Easy to disable or filter those things, too. Most sites do not require SNI and I never send it unless necessary. By MITM'ing TLS I can modify/delete headers/page content as well, before it hits a browser.
But there is no config to disable SNI, so Firefox send cleartext domainname in every ClientHello. Makes me think the session ID about:config is not really aimed at privacy concerns.
You can toggle the "network.security.esni.enabled" setting in about config. However, turning off SNI will cause any server that is hosting multiple websites to just break. So you can't really just shut SNI off sadly.
Most sites I visit that are posted to HN do not require SNI. I have a whitelist of sites requiring SNI. It is only a fraction of the whitelist I have for all sites. SNI is off by default in the proxy configs I use. Works for me.
AFAIK the only sites that offer ESNI are defo.ie and sites using Cloudflare. For ESNI, I have only used Stephen Farrell's ESNI-enabled OpenSSL, not Firefox.
No doubt mitmproxy could probably be used. Personally I prefer haproxy or stunnel. Among other advantages, this allows me to do proxying on smaller computers with limited storage where installing Python would be costly.
Does spawning new incognito sessions mitigate this? I know for me I have set all my various browsers to use incognito mode by default, so all my sessions are insulated from each other and can't 'talk' to each other. For sessions where I need to be logged in/use cookies, I have a dedicated Firefox profile that I launch with the `-p` switch in the launcher icon, and I never do anything sensitive in this session, so I don't care about secrets being leaked into that session.
Not sure, as for example here on HN, if I viewed a link from one container, and come back to the main page within another ( new and otherwise unrelated ) container, new tab and all + logged out, the link I viewed will still show in grey. Can someone explain how that works by the way ?
the color of the link depends on what is in your history, i don't know if hat is a property that can be queried with javascript. i believe it is only local to the browser. iaw: the browser uses the color for visited links defined in css or elsewhere, but you can't check any property if a link is visited or not. that would be a privacy violation even without containers, as i could just create a webpage with many links that i am interested in, and when you go to my page i'd be able to tell what is in your history.
TLS refers to Transport Layer Security. Its what came after SSL (Secure Sockets Layer), is the protocol under the secure web connection (https) and involves a session key that can be used to track, basically. Just stripping the acronyms for the all-caps averse.
1. https://news.ycombinator.com/item?id=26770261