| Both of these vulnerabilities are bogus. 1. "using JavaScript, you can identify the scrollbar width [...] so an attacker can identify the underlying operating system" Using JavaScript, you can simply ask Tor Browser what platform it's on using navigator.userAgent, and it will tell you the truth because lying breaks e.g. websites' custom key combinations. Tor Browser will however attempt to anonymize the platform in passive indicators, i.e. HTTP User-Agent: https://blog.torproject.org/new-release-tor-browser-801 (search for "User Agent") (EDIT) This was too dismissive, because scrollbar width differences are more fine-grained than platform differences: https://bugzilla.mozilla.org/show_bug.cgi?id=1397996#c5 2. Blocking entry node connections: "Checking every network connection against every possible Tor node takes time. This is fine if you have a slow network or low traffic volume, but it doesn't scale well for high-volume networks." If you can muck around in TLS cert fields in real time, you can look up an IP address in a hash table... "Second, the list of nodes changes often. This creates a race condition, where there may be a new Tor node that is seen by Tor users but isn't in your block list yet." Oh no! (clutches pearls) Not to say that it isn't worthwhile to tidy up the TLS fields some more, but hyping this as a zeroday is absurd. |
There are many other ways to detect TOR connections or nodes and block them. Theres enough that there are a whole set of ways of obfuscating traffic called pluggable transports: https://trac.torproject.org/projects/tor/wiki/doc/AChildsGar...