Anonymous Browsing

A List of Tools

Below is a list of tools related to anonymous browsing and maintaining privacy while you use the web. There's also an explanation of how all these tools fit together into the encryption sandwich that's needed to successfully browse teh interwebz as an0n.

Tails - a distribution of Linux dedicated to keeping you anonymous.

Whonix - another Linux distribution dedicated to keeping you anonymous.

Tor - Tor is a tool for anonymization. All it does is anonymize your traffic. Tor is NOT an encryption tool - your traffic is not encrypted by Tor. Tor is NOT a content filter - it does not block cookies, Javascript, Flash, or any other nefarious elements in web pages that may be used to identify and track you. TOR ALONE IS NOT ENOUGH FOR TOTAL ANONYMITY.

Privoxy - acts as a content firewall, parsing and filtering HTTP content, searching/replacing, blocking ads/images/scripts, etc. Combined with Tor, this can provide you with powerful protection against cookies, Javascript, and other things that can identify and track you.

Stunnel - stunnel is a way of building encrypted HTTPS tunnels to carry arbitrary traffic through arbitrary ports. Can't get SSH through that pesky firewall? Wrap the request in SSL, run it through port 443 (HTTPS port), and you're on your way! Stunnel works similarly to SSH, in that you need a command line at both machines for this to work.

SSH - ah, yes, good ol' SSH. You can tunnel lots of stuff through SSH, which is protected with an SSL encryption layer. SSH tunnels are particularly versatile. For example, you can create an SSH tunnel to a local port, then run all of your browser traffic through that local port. All of your traffic will come out the other end, and all traffic will appear to come from the other end of the tunnel.

OpenVPN - you can use OpenVPN to build VPN networks, but there can be some gotchas to watch out for. Example: DNS requests may not be sent through the VPN, by default, which would make the use of a VPN to mask your location useless.

Proxychains - a program allowing you to run other programs through a proxy. This means you could, for example, run Nmap through a proxy server, or run it through Tor.

VPN: OpenVPN

The first tool you can use to protect yourself is not to use your home ISP, but to VPN into a rented server with a different (presumably more forgiving) ISP.

You can set up a simple static key VPN for using a single client and a single server. Instructions for setting up a VPN, and double-checking the connection for leaky information, is covered here: OpenVPN/Static Key

However, OpenVPN by itself won't protect your traffic once it leaves the OpenVPN server. Traffic that's unencrypted when it is sent over the VPN tunnel is unencrypted when it comes out the other end. That's why you use OpenVPN and friends!

VPN + Content Filtering: Privoxy + OpenVPN

We can start by combining a VPN with a basic content firewall/filter like Privoxy. Privoxy is a proxy server running as a service on port 8118, so we'll be redirecting all of our browser traffic into port 8118.

The browser traffic will flow into the computer via port 8118 to Privoxy, which will perform content filtering. That traffic will come from our local VPN.

OpenVPN and Privoxy

How The Tools Fit Together

Anonymous browsing requires a sandwich of tools to serve various purposes. This is because a computer does lots of different things that might give away its identity: perhaps through a bit of unencrypted traffic, or a native MAC address, or a nearby router, or a single login from an unobfuscated IP address, or a DNS request that wasn't sent through the right tunnel.

Think of anonymous browsing like launching a rocket. If you are successful, you can accomplish the (truly amazing) feat of being anonymous. You have the opportunity to step outside of your identity. But to successfully launch a rocket, you need to know all the different things that can go wrong (i.e., you've learned about all the other rockets that have exploded and figured out what they did wrong), and you have to take countermeasures, and make sure everything is secured properly, and all systems are go.

But rockets have many, many stages, just like you have many, many attack surfaces when you browse the internet. There are many methods for identification, fingerprinting, tracking, and location with all sorts of traffic, so it's important to understand what tells what to whom.

The different layers of the sandwich depend on the situation, but with a browser typically looks like this:

• You
• The Browser
• Content Filter
• Traffic Encryption
• Firewall
• Traffic Location Anonymization

You and the Browser

Traffic passing between you and the browser is definitely vulnerable to attack - if you're using a bluetooth keyboard, or a computer with a keylogger installed. (Hard to browse anonymously when your keystrokes are being broadcast, eh?) But we'll skip that for now.

The browser (I'll presume Firefox) is the final recipient of HTTP (port 80) and HTTPS (port 443) traffic. It renders what it receives into web pages. By itself, Firefox doesn't do a whole lot to protect you. It might warn you of bad certificates, but it won't block Javascript (although you can use the NoScript Extension) or cookies (although you can change the preferences) or strip out malicious headers (you gotta use Greasemonkey Extension for that).

• Install AdBlock Extension

If you haven't filtered this stuff out with Privoxy (or, if you have, and you want to be sure), you can block other stuff with these extensions:

• Install NoScript Extension
• Install GreaseMonkey Extension
• Install AdBlock Extension

The point is, the browser is a big gaping attack surface, and various extensions can be used to patch it. But generally you want the pre-browser layers to minimize (to ZERO you hope) the number of attacks that reach the browser.

That's why there are so many steps after this one.

The Content Filter

This is the role that Privoxy plays in the anonymous browsing chain.

A content filter is what things like AdBlock and NoScript do. They take the original version of a website (i.e., the original traffic), and modify it, by removing certain elements from the HTML - elements with ads in them, or elements with Javascript. They then return the modified version of the website (i.e., the filtered traffic).

With Privoxy, you basically run a lightweight, local proxy server, and that proxy server acts as an intermediary between you and the original version of a website. Privoxy filters contents based on various rules, with varying scrictness, and returns the filtered content to you. This all happens seamlessly and invisibly, until you start seeing how many elements on a page were blocked by Privoxy!

You'll be surprised, if you use the NoScript Extension, how pervasive cross-domain embedded Javascript is, and how many websites the scripts on a given page are communicating with.

Traffic Firewall

A traffic firewall is a wall between you and the outside world. It prevents unwanted traffic from getting in, and it prevents unwanted traffic from getting out.

For example, a firewall could be used to block port 22, so that even if you have an SSH server running on your computer for local network connections, no remote connections from outside could be made to port 22.

However, this can also prevent unwanted traffic from going out - for example, by blocking port 53, which is the port normally used for DNS queries, you prevent some idiotic program that has implemented its own DNS query engine from broadcasting your native MAC and IP address.

Firewall rules:

• Block all ports except port 9050
• Block all DNS resolving queries sent from your client to any DNS server
• Block DNS queries made by clients toward external IP addresses on UDP port 53
• Force DNS queries through Tor (port 9050)

Traffic Encryption

The Problem: Sniffable Traffic

Unfortunately, due to the lack of encryption available on many websites, there's virtually no way to guarantee that your traffic can't be sniffed. Even if you're using HTTPS, you're prone to sniffing attacks from Tor exit nodes.

That means, if a website DOES NOT offer HTTPS, you cannot make an encrypted connection with it, and your traffic WILL BE passed out of a Tor exit node in the clear and perfectly sniffable by the exit node operator.

The Tor browser bundle comes with HTTPS everywhere, but that just tries to use HTTPS everywhere. If a site doesn't offer a login menu with HTTPS (hint: a lot of sites), there's nothing you can do to hide that information.

And worse, these weaknesses are prone to happen on Tor exit nodes - and since operating an exit node requires peculiar resources, which requires money and/or power, this puts Tor exit nodes into particularly untrustable, grubby fat hands.

Which leaves you with very few options. How can you guarantee your traffic will be encrypted?

The Solution: Encrypted Connection

The solution is to bypass the Tor exit node sniffing by ensuring your traffic stays encrypted after it exits Tor. Any sniffer at an exit node would only see encrypted traffic. But, making an encrypted connection, by nature, requires a second entity on the other side, who can make an encrypted connection via your traffic exiting Tor.

How to make an encrypted connection to another entity? There are plenty of options.

Option 1: HTTPS Absolutely Everywhere

The HTTP Everywhere extension for Ffirefox allows you to use HTTPS where it is available. But you can also put it in a mode where it will ONLY make HTTPS connections. This will prevent any unencrypted traffic, and is a great feature if you are using a hostile network where you know traffic will be observed.

Option 2: HTTPS Via Proxy Server

Another option is to use a private proxy service (paid for with bitcoin, of course) to maintain encrypted connections over Tor. You can maintain an encrypted connection to the proxy server, which then makes all of your requests for you. While this doesn't do anything to protect the web requests made from that proxy server, it is a way of protecting your identity when making requests to that proxy server.

Option 3: Anonymous SSH + Socks

One method that utilizes a remote machine (one on a safer network or with less aggressive surveillance) involves an SSH tunnel to the remote machine. The traffic for that tunnel is encrypted on the local machine before it is ever on the network; it stays encrypted as it is passed to Tor, which sends it out on port 9050 to the Tor entry node, through the Tor bridge node, and through the Tor exit node, until it comes out the other side at the "safe" remote machine.

This SSH tunnel could be utilized to carry browser traffic and web requests - requests made locally are forwarded to a remote machine through SSH tunnel. This requires the use of a SOCKS proxy.

Anonymous SSH - covers how to create an anonymous SSH connection to a remote machine over Tor.

Anonymous SSH and Socks - covers how to use SOCKS to send web traffic over an anonymous SSH connection to a remote machine over Tor

Option 4: Anonymous Stunnel

A further twist on this method would be to wrap this SSH connection into an SSL layer using Stunnel, allowing you to pass the SSH connection through HTTPS port 443, just like any other regular web traffic, except that it's an SSH tunnel. In both cases, the encrypted connection beginning at your computer, before it enters Tor, and ending at the remote computer, after it exits Tor, are what make it possible to circumvent Tor exit node sniffing.

Anonymous Stunnel - covers how to create an anonymous SSL tunnel on port 443 to carry arbitrary traffic (SSH tunnels, etc) over Tor.

Maybe An Option: Anonymous Squid

Another (theoretically) good alternative is to forward HTTPS traffic from your computer to the remote computer by running a proxy server on the remote computer - something like Squid. With Squid, you could make a secure HTTPS connection to the remote machine, protecting your connection on potentially hostile networks (like Tor).An HTTPS connection to the remote machine would be unsniffable by Tor exit nodes, and would then be translated into a web request on the remote end, which the remote proxy server would perform.Encryption happens on the local machine, before it enters Tor, and at the remote machine, before the traffic is returned via Tor. This means a Tor exit node has no way to sniff the unencrypted traffic.

However, unfortunately, this Squid page says that there isn't much support for a secure browser-remote proxy connection feature to be added into browsers: http://wiki.squid-cache.org/Features/HTTPS

So the Stunnel and SSH methods above will have to suffice.

Summary

Think of it like this: you want to add extra hops to either end of your encryption "traceroute", so that it is longer than your Tor "traceroute".

Traffic fingerprinting and traffic correlation attacks in the case of HTTPS (either with Stunnel to carry an SSH connection, or with Squid proxy handling an HTTPS-HTTP request) would still be possible here, since a Tor exit node would be able to see the destination of the encrypted traffic. But it would appear like any other HTTPS traffic. You'd have to get much more sophisticated to conduct a Man-in-the-Middle attack against this type of connection.

Traffic Location Anonymization

Traffic location anonymization is what Tor gets you. Tor anonymizes the location of origin of your traffic, by passing it through three layers of obfuscation: the Tor entry node, the Tor bridge node, and the Tor exit node. Each connection, between each layer, is made randomly, and each connection obfuscates further the geographic origin of the traffic. While this slows down traffic significantly, it also bounces your traffic all over the place, rendering it untraceable.

(Assuming you don't do something stupid like log in to your Facebook account over Tor.)