Tracking Users Across the Web via TLS Session Resumption (2018) [pdf]
svs.informatik.uni-hamburg.de
svs.informatik.uni-hamburg.de
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.
CORS
img tag GET request cookie sanitation on modern browsers
3rd party cookie filter/discard
All kind of other privacy filtering
It's just like TLS SNI a very obvious feature completely contrary to TLS privacy purpose, but which very few people know about.
"(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."
Source ePrivacy diretive: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...
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.
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!
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.
Can you share a tutorial or gist with the config? Would mitmproxy be a good option for this or something else?
This prevents the browser from using session identifiers and will renegotiate a new key for every session.
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.
Here's some previous discussion: https://news.ycombinator.com/item?id=18251844