Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
∞ take a peek at our legendary cryptostorm_is twitter feed if you're into that kind of thing ∞
Ξ we're rolling out voodoo network security across cryptostorm - big things happening, indeed! Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit GitHub Ξ

Why the entry IP is the same as the exit one

To stay ahead of new and evolving threats, cryptostorm has always looked out past standard network security tools. Here, we discuss and fine-tune our work in bringing newly-created capabilities and newly-discovered knowledge to bear as we keep cryptostorm in the forefront of tomorrow's network security landscape.

Topic Author
Guest

Why the entry IP is the same as the exit one

Postby Guest » Sun Jan 12, 2014 2:41 am

Hey guys, got the plan yesterday,
the impressions are fine, except a very old simple correlation attack.

It seems you use the same IP for the Iceland entry and exit.

Should I say why it's the worst possible scenario? Thought so.


P.S.,
You might not log anything and run your OpenVPN instances from RAM,
but one the adversary with enough power will send DataCell of BackBone.IS
a request, or even ask GCHQ (unless Iceland got independent already? 99% not)
to handle every IP that access target x.x.x.x from 79.134.255.93, and then ask all those ISPs
(Interpol can have a subpoena to do that) who accessed 79.134.255.93, the VPN is as good
as the people who were connected to the same server at the same time.
Which probably makes it worse than Tor.


Please comment.


Lignus
Posts: 33
Joined: Sat Nov 02, 2013 1:26 am

Re: Why the entry IP is the same as the exit one

Postby Lignus » Sun Jan 12, 2014 3:38 pm

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.

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.

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. All the computers in my LAN are behind a OpenVPN gateway. If my ISP looks at my connection logs, all they see is my router renewing the DHCP lease, performing a single DNS lookup, and opening up a OpenVPN session to cryptostorm. Time and activity correlation attacks will fail because there are always torrents running. I now generate 1TB+ of encrypted traffic every month, any spy agencies worst nightmare. The best part is, should they be collecting my traffic, they will be collecting almost entirely innocuous traffic. Even if they were to crack the encryption wide open in the future using quantum computers, all they would get for the resources wasted would be episodes of How I Met Your Mother and other current TV shows. I am not even someone that would be targeted, but that does not mean that I think the state should have the power or ability to do things that would land the average individual in jail. OK, maybe that statement would do it.

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: Why the entry IP is the same as the exit one

Postby Pattern_Juggled » Sun Jan 12, 2014 6:52 pm

Guest wrote:You might not log anything and run your OpenVPN instances from RAM,
but one the adversary with enough power will send DataCell of BackBone.IS
a request, or even ask GCHQ (unless Iceland got independent already? 99% not)
to handle every IP that access target x.x.x.x from 79.134.255.93, and then ask all those ISPs
(Interpol can have a subpoena to do that) who accessed 79.134.255.93, the VPN is as good
as the people who were connected to the same server at the same time.


I think there's a kernel of valid critique in what you're saying, but it's blurred by an error in statistical thinking.

As I understand it, you're suggesting that an APT-level attacker would go to every ISP in the world and demand of them logfiles to allow for ex ante creation of lists of people who have visited a given IP address in a certain timeframe - worldwide. Doing that by asking individual ISPs is, to be blunt, totally impossible: there's many, many hundreds of thousands of ISP & network access providers worldwide - a swirling, ever-shifting morass. Some are big and will gladly snitch their "customers" if asked... but many are smaller, ephemeral, speak a vast array of native languages, etc.

It's like saying that you know a bar of gold is hidden in the trunk of a car, somewhere in the world. So, solution is simple: search the trunk of every car, and you are guaranteed to find the bar of gold! But there's a heck of alot of cars, scattered over a very big world out there...

That said, we know the NSA (and perhaps others) has indeed been doing its best to create a database of all IP sessions and all packet traffic, worldwide. They do this by bulk-tapping massive fibre cables, punchdown facilities, and other such enormous infrastructure chokepoints globally. They've managed to built a decent percentage database of such traffic, from what we know thanks to Snowden. Of course, in theory it's only to catch those evil "terrerists" and whatnot... but we also know, thanks to Snowden, that they've been dipping into it for all sorts of additional fun.

These are, to be clear, nation-state level APT attack vectors - worth studying and worth building tools to defend against, but certainly not the nuts-and-bolts threats faced by most folks online... not even most folks who are very serious about security.

Which probably makes it worse than Tor.


Well, no.

Our model is qualitatively different than that of Tor, in several key respects. In practical terms, you couldn't pay us enough to trust a browser (Firefox, ffs! :wtf: :shifty: :o ) to "enforce security" of network traffic. Ever. In a million years. Browsers are buggy, insecure, heap-spraying, leaky, crash-ridden bloatware. Which is no big criticism: they're only browsers! They're not designed to be hardened against serious security threats. So, building a "secure" network on top of Firefox is just... astonishingly non-intuitive. And, yes, stats are that 95%+ of Tor users are using the "Tor Browser Bundle" to access the network - which makes all of them vulnerable to Firefox's ever-expanding sweep of known bugs. That's not counting the Vupen-style, genuine 0days out there... and there's plenty.

(yes, cool tools like Whonix can remove Firefox as a critical element of Tor connectivity - and they're wonderful tools; sadly, not many folks use them so, again in practical terms, "Tor connectivity" tends to mean "Tor Browser Bundle" in most all cases)

Which gives you Torsploit and all the related NSA-driven, browser-targeted attacks on Tor. Successful attacks, we might add - attacks that have put dozens of people in prison so far... and likely many, many more to follow.

Second, we choose to retain tight control of exitnodes. Tor makes exitnode administration available to anyone. And we've seen that "evil exit node" problems are endemic to Tor. They come up over, and over, and over. It is structural: traffic needs to exit someplace, and if someone nasty has /root on that machine, there's some unpleasant issues that come to the surface. We take a different approach, structurally. Better, or worse? Different, I'd say.

Third, and this is sort of an extension of #2, our model allows us to provision the fuck out of exitnodes. Goal being network connectivity that's Fast As Fuck (tm). So members can use it all day, every day, for all traffic all the time. Nobody can do that with Tor, nor will they ever be able to do that - it's donated capacity, and the more they get the more is demanded (a free service, after all). That's structural, too. It cannot be "fixed." So that's a real issue, in terms of real use-case scenarios.

Tor kicks ass, and the Tor project team kicks ass - seriously. We watch them closely, learn from their expertise, and support their work. Our choices in deploying network security are not homomorphic to theirs - that doesn't mean one is "right" and one is "wrong," necessarily. It could simply mean we're targeting orthogonal use-case scenarios.

There's a great deal more technical analysis of Tor versus cryptostorm's model of network security in this existing thread, if you're curious.
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: Why the entry IP is the same as the exit one

Postby Pattern_Juggled » Sun Jan 12, 2014 7:16 pm

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.
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

parityboy
Site Admin
Posts: 1096
Joined: Wed Feb 05, 2014 3:47 am

Re: Why the entry IP is the same as the exit one

Postby parityboy » Thu Apr 07, 2016 6:44 am

@PJ

I read this thread a while back, then though of a question, then forgot the question. :P Now that I've remembered the question, I'll ask it.

Each CS node has Windows and raw instances. Each instance sits on its own IP address, through which it funnels both entry and exit packets. The question is: why not funnel both Windows and raw exit packets through a third (and common) IP address, thereby increasing the visible exit traffic? Or is there no value in doing this?


Last bumped by Anonymous on Thu Apr 07, 2016 6:44 am.


Return to “cryptostorm reborn: voodoo networking, stormtokens, PostVPN exotic netsecurity”

Who is online

Users browsing this forum: Yahoo [Bot] and 5 guests

Login