How NOT to Use I2P and TOR: Common Mistakes That Compromise Anonymity

How NOT to Use I2P and TOR

Or, a tale of unexpected ways users of distributed anonymizing networks can be exposed.

Users of anonymous networks and browsers typically use them to access mostly blocked or protected websites. However, not all of them expect that their visits will remain truly anonymous. If you’re not concerned about anonymity, the rest of this article probably won’t interest you. For everyone else, read on for some abstract musings from a budding paranoiac about how users of anonymous browsers can be unmasked.

Disclaimer

The author takes no responsibility for any bouts of paranoia you may experience while reading this publication, nor for the accuracy of the information contained herein.

Attack Vectors

We won’t delve into the technical details of how these networks function or try to hack them. As is well known, even the most advanced security tool has a human as its weakest link. So, let’s talk about methods that bypass distributed protocols and exploit common user mistakes, misconfigurations, or software flaws.

Here, “de-anonymization” means revealing the user’s real IP address.

Fingerprinting

If you use the same browser for both regular and “anonymous” browsing, you can easily be identified by your browser fingerprint. This fingerprint, saved during your “anonymous” session, can later be matched in massive fingerprint databases maintained by Google, Facebook, and even government agencies.

There are many ways to collect fingerprints, all well-known, so I won’t list them here. Use a separate browser for browsing the “closed” internet, and ideally, clear your history after each use.

Access to the Regular Internet

Even if you use a separate browser for the “closed” network, if that browser can still access the regular internet outside the “protected network,” a site on an onion/i2p domain can exploit this to de-anonymize you by sending a request where it shouldn’t. This can happen via HTTP, DNS, WebRTC, etc.

To prevent this, at a minimum, block all incoming and outgoing connections for this browser in your firewall except for localhost and the port your anonymizing proxy uses.

You can’t do this if your anonymizer is built into the browser and runs in the same process.

Additionally, make sure your browser never uses the operating system’s DNS resolution APIs under any circumstances.

You can check this by making a request in the address bar while monitoring traffic with Wireshark or tcpdump.

Non-Standard Protocols

Besides http:// and https://, there are other protocols that may have their own vulnerabilities. For example, file:// and smb:// can be used to trick your browser or OS into sending a request to a specific address.

All protocols except http:// and https:// should be completely disabled in your browser.

GPS Coordinates, Microphone, and Camera in the Browser

This is obvious, but it’s very easy to slip up. Don’t allow your browser access to your location, microphone, or camera when using anonymous networks.

Browser Vulnerabilities

This is pretty self-explanatory: browsers are full of holes. Update them regularly, but even that won’t fully protect you. Sooner or later, a new vulnerability will appear.

Browser Plugins

Be careful with browser plugins. They may have vulnerabilities, can see everything you do, and in some cases, can send data elsewhere.

Antivirus Software

Your antivirus can de-anonymize you. How? A site on an onion/i2p domain can have you download a unique page or file. Your browser saves it to disk. Before scanning it for viruses, your antivirus may first check the file’s hash with the antivirus company’s database or a distributed network of users. This can expose your identity.

OS Telemetry

Your operating system may have built-in antivirus or telemetry tools that also collect and send file hashes to the cloud.

What to Do

I recommend using a network-isolated virtual machine (VM) that automatically shuts down if it detects unexpected traffic (anything other than tor/i2p) from its IP address.

Control should be external—using another VM or, better yet, a separate physical host.

Here’s a recommended approach based on three types of traffic from the VM:

  • Green: Only access to the I2P/TOR proxy running on ANOTHER virtual machine. The VM itself should have no way to access the open internet or know the user’s external IP.
  • Yellow: Previously analyzed third-party traffic deemed acceptable. This should be completely blocked. “Acceptable” means the VM won’t be stopped if detected, just blocked. For example, Windows trying to reach Windows Update or send telemetry. (Mentioning Windows as a guest OS here is more of a joke than a recommendation.)
  • Red: Everything else. Completely blocked. If detected, the VM is immediately stopped, and the traffic log (which is continuously recorded) and VM state are analyzed. If the traffic can’t be guaranteed as “yellow,” I recommend rolling the VM back to “factory settings.” In general, I recommend resetting to “factory settings” after each use.

Don’t use this VM for anything except browsing protected networks. Be careful with software license keys, MAC addresses, and hardware serial numbers visible to the VM’s OS, as all of these can be leaked—even through a protected network—without triggering the VM’s auto-shutdown. For this reason, I strongly advise against doing any of this on real hardware.

Cameras and Microphones Within Reach

Cameras are an obvious risk—hopefully, no one is browsing closed sites in front of a camera. Microphones on other devices are less obvious, but still a risk.

When you type a message on a “protected” site, that site (or an embedded script) can measure the intervals between your keystrokes. Interestingly, this information can even be extracted from an encrypted TCP/HTTPS session by measuring the intervals between IP packets.

A microphone (for example, in your phone) within range can do the same. Based on this, a special index can be created that, similar to music recognition services, can determine that it’s you typing the message.

Disabling JavaScript helps somewhat, but mouse clicks when navigating pages still remain, so keep microphones away from your workspace.

P.S. Wishing you a healthy dose of paranoia, comrades!

Leave a Reply