As the recent FBI compromise of the hidden service playpen has once again demonstrated, we cannot rely on counter traffic analysis while lacking application layer security. There can be no doubt that the counter traffic analysis game has largely been won due to Tor, as the federal police time and time against resort to hacking through application security in furtherance of compromising their targets.

This mildly alarming trend of the police to by pass anonymizers is not unexpected, but it must be dealt with immediately and decisively; the application layer is not there for the federal police to cut through, we will resist and we will prevail.

Let's go over the basics of what is happening here.

Tor is an anonymity network which routes users packets through three different nodes from a large volunteer network, layer encrypted up to the link before the destination (to clearnet). Although the federal police have had on rare occasions the luck to compromise the security of Tor in itself (always with external sources of intelligence), they largely fail to use traffic analysis to deanonymize Tor users. They have gotten around this by hacking exposed application layer attack surface area.

To protect from this, we utilize the three schools of classical computer security, isolation, correctness, obscurity/randomization.

Isolation

Isolation is the practice of layering applications (and/or hardware) such that the compromise of one application does not immediately threaten the other applications, rather in order to spread from compromised to non-compromised applications, the attacker must compromise the layers of isolation between them. Additional layers of isolation result in additional zero days that the attacker must have access to. The FBI has only been identified using non-zero-day exploits for single layers of applications (browsers).

multiple layers of isolation can be stacked

Correctness

Correctness simply means that if there are no exploitable vulnerabilities in a layer of isolation, there is no need to isolate further seeing as the attacker will be incapable of penetrating through the correctly implemented layer of isolation. Layering vulnerable isolation is still useful as the attacker may only be aware of some vulnerabilities at a given time (despite needing all vulnerabilities to break out of all of the isolation layers), but a single layer of correct isolation (without vulnerabilities) is better than ten layers of isolation with vulnerabilities.

It should be noted that physical isolation of Tor from network facing applications is very close to correct isolation, seeing as if only Tor is exposed, an attacker who compromises firefox must compromise the secondary system via Tor in order to gain direct access to the internet. However, in reality the network stack of the secondary system is also exposed, etc. SEL4 is a formally verified microkernel that offers a similar extremely correct degree of isolation implemented in code (rather than physical configuration, though it is therefore vulnerable to physical layer attacks such as row hammer).

In order to increase correctness, we can decrease complexity, because incorrectness and complexity very frequently positively correlate. Decreasing complexity certainly entails disabling javascript in Tor Browser, you absolutely should not go to sensitive sites with javascript enabled nor should you trust sensitive sites that require javascript to be enabled. Indeed, you should consider disabling everything that you don't absolutely need. If your threat model doesn't involve loading images, perhaps you should disable images in firefox, or CSS in firefox. Everything like this that you disable reduces exploitable attack surface area that can cut through layers of isolation on the way back to you. The same is true for your virtual machine, don't enable any guest additions as these all increase complexity that can assist an attacker in breaking through that layer of isolation.

It should be noted though with firefox that disabling features results in you having a more unique browser fingerprint which could be used to link your movements from site to site, though not to trace you through Tor. Consider if unlinkability from site to site is important for your threat model. Someone who goes exclusively to websites that are illegal to go to may not care about linkability from site to site, particularly if they use the same pseudonym at each site (in which case they are linkable by pseudonym in any case).

Obscurity / Randomization

If everyone else is using firefox, but you are using a browser that you implemented yourself, an attacker who targets everyone going to a site with a firefox vulnerability is not likely going to compromise you. Additionally, they are not likely to have any attack that can compromise you, because they are not even aware of your browser. This is security via obscurity.

It should be noted that security via obscurity is controversial, and it can only really be thought of as offering much protection from dragnet attacks that don't actually specifically target you.

Perhaps a safer way to obtain security via obscurity is to use a trusted yet obscure operating system such as one of the *BSD family rather than Linux. In the attack against users of Freedom Hosting sites, the FBI only had a payload for compromising Windows. We aren't yet sure how many sorts of operating systems they targeted in the case of the playpen compromise, but even if they included Windows and Linux payloads this time, they may not have included *BSD payloads. The less people using the same OS etc as you, the less likely that an attacker is to attempt to compromise it in the first place when it comes to dragnet attacks.

Final Thoughts

I believe that what is ultimately required is a formally verified or otherwise highly secure remote desktop viewing application which can be spread via a virus or similar. Compromise a random system via Tor, covertly run a low resource virtual machine on it with linux and tor, and access it remotely via a highly secure remote desktop viewer (that allows for viewing the Linux desktop from the infected host environment, while hiding the Linux desktop from the actual user of the infected system, how to implement this requires some thought, though using blue pill [from Qubes creator, not blue pill in our terminology] to trap the user in a virtual machine, while running the remote desktop server outside of the virtual machine, and another linux virtual machine also outside of it, seems like it should work.)

A perfectly secure remote desktop viewer should stop all application layer traces from getting from the remote environment to the local environment, so coupled with Tor + an infected computer to control, this should offer application layer untraceability. I'm currently working on the design and implementation of such a remote desktop viewer, in furtherance of knocking the FBI on their asses where they belong, the internet belongs to those who support freedom so please fuck off :).