1) Run the HTTP server in a guest VM to reduce likelihood of hardware identifier leakage (hardware MACs, HD serials, DMI data, CPUID, etc.)
2) Physically separate HTTP server and Tor client, and restrict communication between them to a simple packetized high-speed serial interface.
2a) Consider an inline filter on this link that watches for private keys, etc. and kills communication upon detection, and adds random latency to packets to reduce bandwidth of timing channels.
2b) Physically isolate these systems as much as possible: power line filters, electro-optical couplers for the comm link, etc.
3) Stub out all Tor crypto operations to an HSM; keep the onion key and do all operations on the onion key on that HSM.
4) Make friends in the criminal underground, becasue you're probably going to prison eventually, anyway ;).
But yes, it reminds me of the hilarity of FBI's characterization of PLA Unit 61398 as some super-scary 'master hackers': real 'master hackers' don't get caught.
Associating with other criminals is a great way to get ratted out. It is also a great way to put yourself on the radar of law enforcement in the first place, so even if you don't hint to your new 'friends' that you are up to something it is still risky.
Here is a better idea: keep it as white collar as possible (no hitmen) and pray for minimum security.
Historically, someone who murders a stranger (ie, serial killers) is nearly always caught because one victim gets away and tells the police. http://www.wired.com/2011/04/mf_billjames/all/ Otherwise, the cops are generally stuck with their habits of sniffing around friends and acquaintances of the victim (which by definition are doing the non-stranger murders).
"Petty criminals break the law. Bigger criminals skirt the law. The big bosses ignore the law. And the biggest criminals of all - they write the law."
There's actually a "better" method. Hash every packet, and add latency not only randomly, but also, for each field in the packet, add latency based on the hash of that field. (In actuality you want a random salt, so, HMAC or similar)
That way, assuming they cannot figure out the salt, you actually actively prevent a large chunk of timing attacks. You're adding deterministic variation that hopefully swamps the server-side variation, deterministic being the key word. You cannot get around it by repeating measurements, as the delay stays the same.
(Alternatively, keep each packet so that exactly 100ms or whatever has passed between getting the packet in and sending the response, silently discarding any packets that take >100ms to process.)
A system can only reveal information it knows, so to defend against this "attack vector" when building a secure system, you must ensure that the software knows as little about the system as possible.
There are various ways that don't require NAT, it's more a matter of ensuring the software doesn't need the information it shouldn't know. And both FreeBSD and Linux have tools to lock down a process so it can't find these out (Capsicum and/or SELinux).
What do you folks think?