Lignus wrote:Correlation attack is pretty low on the list of threats when using a service such as this. Something like Cryptostorm should be one of multiple hops when performing any activity you would rather not have tied to you personally. If Cryptostorm is your first and last hop, you are probably doing other things that will sooner compromise your identity than a simple correlation attack. Additionally, single entry and exit point IPs in this scenario is probably a good thing. This way, customers can be aware of the possibility of a correlation attack and think twice about their actions. Having separate entry and exit point IPs is false security. If I know that CS has, say, 10 exitnodes and 10 entry nodes in Iceland, I am just going to correlate all of them.
This may seem simplistic, but our heavy cipher choices actually mitigate naive timing attacks considerably. Because the overhead for re-packetising at the exitnode is nontrivial - in particular, SHA512 HMAC validation of every packet, coming and going
- there's some inherent stochasticity in packet ordering when you look at traffic on the wire. It's not massive stochasticity, but it's far from zero. Someone could code up a tool to deal with such flux, but it's a far cry from just doing a simple "packet in, packet out" style timing attack.
We also considerably tweak our TX/RX, ring, TCP, NIC, and OSI 5/6 layer buffer settings. Intentionally so. Because if you make a few interconnected pools of packets inbound and outbound, and shovel packets in and out... good luck doing a simple "this packet goes in, this packet goes out" analysis. Plus there's HMAC overhead. Plus de-packetizing/re-packetizing actually shifts around payload substantially for streaming data (note MTU stuff we do - that's part of it). It's not "one packet in, one packet out" - it's "200 packets came in via encrypted UDP in non-ordered fashion... and 374 packets came out, some TCP and some UDP, in various sessions and protocols and port mappings." Now, do traffic analysis.
Oh, and our exitnodes - not clusters, but exitnodes
push daily traffic that we measure in terabits per day. Multiple terabits, for most nodes. Finding a particular TCP session in that is quite truly a needle in a large and fluid haystack: totally possible to pull out with some high-horsepower Narus snooping tools installed onsite in the DC, for example - but how many attackers have such tools, and the ability to stick then on a wire locally? And, yes, it does have to be local - as close to pcap's as possible, really.
Again, technically possible - but far from trivial.
There is a way to, if not defeat, make much harder correlation attacks on CS. They could implement a global-balancer.cryptostorm.org that creates, for example, a Montreal entry point and randomly picks Frankfurt, Montreal, or Iceland as the exit point. This creates significant infrastructure requirements as well as complicating things significantly. I would not be enthusiastic about being able to design this network in a way that provides privacy protections on the same level as the current setup.
This is actually a decent sketch of our 3.0 "mesh" model for the growth of cryptostorm: enabling cluster-to-cluster stochastic routing of network sessions... as well as decoupling protocols from within a given member's session and striping protocols out to different exitnode clusters, dynamically. It's nontrivial, but not as bad as it seems with some OO-style encapsulation of routing logic. And yes, it'll be quite an authoritative rebuke to any and all traffic analysis based attack vectors.
Also: Dust. We're pulling Dust into the model, hopefully in a 2.x version. Had we more Haskell-savvy team members, it'd be sooner... but we're coming up to speed, slowly but surely...
I should also note that security in numbers plays an important role for diminishing the value of correlation attacks. If there are 1000 users on a node, that is 1000 possible distinct legal jurisdictions to investigate and certainly not enough to establish anything more than your name on a watchlist unless you repeatedly login to the same VPN and the attacks always come from that VPN when you log on. Once again, this is the user being stupid, not the VPN being at fault. This is why it is important to just say fuck it and encrypt EVERYTHING you do.
LEO-driven attacks start within the network, and seek to "reach back" to physical IP of targets. That's their model, tried and true. When they bump up against an over-engineered, technically robust layer such as cryptostorm, it's a strong disincentive to bang their head on that particular brick wall. It's a game theoretic dynamic, really. Low hanging fruit, and all that. We get very, very feelers for "assistance" with such efforts... because, frankly, it's no secret that we're modeled to be retained-data-free and, at a philosophical level, strongly averse to being co-opted as part of law enforcement duties. Not our job, as we tend to say.
There's tons of "I can sit at a table and imagine an attack that might possibly work" thinking that goes on - often pushed by some "VPN service" hyping a particular vaporware "feature" they claim to have (and usually don't, in truth) as a marketing gimmick. Take "multi-hop VPNs
" - classic example. Please... take them. We sure as fuck wouldn't touch them with a 50-meter pole. Charlatans with no technical competence, selling snake oil to desperate and largely technically undereducated victims.
In contrast, thanks to Snowden and other forensic researchers, we pretty much know exactly what sorts of real
attacks are being deployed out there, right now. We don't need to come up with imaginary, just-so-story, fantastical attacks that could conceivably happen - but really won't. Everyone knew about the risk of a brower-based 'splot against Tor, long before Torsploit happened: the Tor folks warned about it repeatedly and consistently. No surprise. Indeed, much of the stuff in XKEYSCORE
is unsurprising to those of us on the front lines out here: it's what we always sort of secretly (or not so secretly) assumed/predicted/feared. Yep, it was happening all along. There you go.
Bruce Schneier defines "security theatre" as doing stuff that gives the appearance of making you "more secure," but in brass-tacks functional term is doing nothing of the sort. It's the sort of feel-good, marketing-friendly, tell-them-what-they-want-to-hear bullshit that's endemic in the "VPN industry."
Like, well... PIA bragging about
"alien-technology proof" VPN service - and Torrentfreak carrying it as a story
, ffs - that's classic security theatre. Totally useless against actual, in-the-wild threat vectors.
We don't do that shit. We don't go for gimmicks that might sort of vaguely seem "cool," but actually do nothing to protect our members. We protect our members, period. If 99% of folks - and maybe 90% of our members - have very little idea about the 10,000 little things we do to harden our attack surfaces, day to day, against real attacks... that's fine. Because, in the end, that's our job - we're entrusted with it by most members, who have judged us competent and decided to rely on us to deploy something that's not full of shit.
It might now make us as "cool" as alien-proof PIA - or get us glowing, dick-sucking "reviews" by TorrentFreak... but fuck it. It actually protects our members, and that's what counts. The rest is a waste of life.