Beyond VPN: the new cryptostorm secure network
Some of us, on the cryptostorm core team, have been around the "VPN industry" since 2006 - when it was born. The first VPN service was built with PPTP, a VPN protocol that was already back then insecure and all but useless as a security tool. But the idea of a network privacy service that used cryptography to protect data-in-transit from prying eyes was... a damned good one, and long overdue. Shortly thereafter, we (in an earlier incarnation) first introduced OpenVPN-based service to the consumer market - along with innovations like the first "no-logging" policy, the first custom-hardened cryptographic parameters, the first filesharing-friendly network, and so on.
Since then, it's been a wild ride. Today, there's hundreds of "VPN services" hyping their wares. A few aren't bad... and then there's all the rest. Some installers come loaded with malware, infecting customer computers with keyloggers and trojans. Some services skip the annoyingly complex details of cipher selection by defaulting to plaintext. Most all use insecure VPS instances as "servers," and are thus essentially all hype and no security. A few are fronts for massive, state-sponsored botnets. And so on, and so forth. Quite a ride, indeed.
Throughout, our little passionate and uncompromising team has grown and shrank, rebooted, rediscovered itself, retrenched in the face of heavy opposition, rebounded with alacrity, and revolutionized the "VPN industry" over and over. We rebuilt the network ground-up after Snowden's revelations in 2013, realizing (correctly) that many of the civilian world's past assumptions about what the big intelligence agencies could (and would) do were vastly wrong. We introduced token-based authentication, removing financial information completely from the network itself.
Its been good work, and we're proud of that work. It matters; it's kept countless tens of thousands of members safe from all sorts of serious threats. As individuals and as a team, we've grown. We've learned. We've - some of us - struggled and fallen and gotten back up to struggle again. Our work, and the community that has grown organically around this project, has become much greater than any one of us - or even our entire team. Some founding team members have moved on to new projects and new challenges in life, though their brilliance and compassion and greatness of spirit live on in the work they gifted us with here.
Our network runs well: it's fast, it's got solid cryptographic foundations, it's been hardened in 10,000 ways big and small - from kernel tweaks and network stack tuning through our deepDNS resolver framework and TrackerSmacker anti-adware functionality. It's the best "VPN service" out there - by a long distance. Sure, we may be accused of bias... but by any metric we can think of that matters, cryptostorm is the best of the best - and has been all along.
Do we sit back on our heels, now, and let the good times roll? Maybe that's the smart way to do things, in business terms. Put the energy and passion and creativity of our team into clever marketing promotions (instead of our long-running #WeSuckAtMarketing campaign ;-) ), finally get our affiliate program in place, streamline the token resales market, and so on. After all, the network itself runs great - add new nodes as growth occurs, replace those that drop, tune a little bit here and there... it's not quite "runs-itself" status, but not far off from that either.
(a little trivia note: cryptostorm hasn't ever had, and doesn't have today, anyone who does marketing full-time on our team - it's just never come together, though we've benefitted from contributions by many smart marketing minds, over the years)
That's one option. The other option is to, once again, revolutionize the "VPN industry" and do something that, not only has nobody ever done before... but something nobody's ever even thought of previously. Something so vastly better than how we do things now that it's not even really a "VPN service" anymore - it'd have to be called... beyond VPN. Or something like that :-P
We're doing that.
We're moving Beyond VPN.
And here's what we've done...
~ ~ ~ ~ ~
This isn't a technical essay, and we're going to avoid technical details in favor of a broader view (the technical details will, as usual, appear in our member forum where they can be discussed, dissected, and debated in detail).
To begin, let's look at how a "VPN network" works, at the most general level:
Members connect their computer (or, increasingly, their smartphone) to a "VPN network" by making an encrypted, direct line to a server that is run by the VPN service. Information coming and going from the internet to their computer now runs through the VPN service's server, and then gets to (or heads out from) them. If they choose a different server (we call them "nodes"), they can change the IP address that, to the world out there, appears to be their physical location. There's a selection of really good "how VPNs work" diagrams and essays and so forth out there - we'll not belabor the issue here, save for two critical things to recall:
- the connection between member computer and the "VPN network" is essentially point-to-point - a direct line back and forth, as it were.
- the servers themselves do two jobs, for the network service: they encrypt/decrypt packets as they come and go, and they handle the routing of packets into and out of the connection to the customer computer.
This one-layer topology has the benefit of being non-complex, and therefore easy to build as well as easy to manage. Unfortunately, it also has lots of drawbacks when we consider it from a security perspective. Traffic analysis attacks - which don't need to decrypt traffic but instead look for patterns in traffic coming and going from individual servers - are effective and have moved from theoretical to well-established in the real world. Worse, having the server that handles encryption/decryption be "visible" - in terms of it's IP addresses - to the internet means that it is expose to attacks, DMCA-style harassment, and more. It is the buffer between the customer and the internet-at-large, but the double-duty it does - routing and encryption - means it's vulnerable on two fronts.
There's better ways to do network security - Tor is one obvious example. Rather than having one layer between the customer and the internet resource being accessed, Tor adds multiple layers of intermediate routing (and encryption), which does a great deal to protect the privacy and anonymity of the customer on the other end of that multi-segment link between her and the internet. And layered network topology, such as Tor, adds an exponentially-increasing level of challenge and complexity to network management and design - pretty obvious why that's the case. In general (though not as a law of physics), that complexity tends to make layered networks like Tor slower - in terms of throughput, and in terms of bandwidth capability. It's seen as a trade-off: more layers, less speed.
In addition to Tor, there's quite a few "VPN services" that market and advertise "multi-hop" VPN connections. These, they claim, take traffic from a customer and run through two (or more) VPN servers before they are decrypted and sent onto the internet itself. It's a neat idea - it sounds good, in any case. Sadly, in essentially every case we've researched over the years, these "multi-hop" connections don't actually do what they say (testing is done with routing and pcap analysis of packet traffic). Most are, simply put, a great way to get extra money from gullible customers - who don't know how to check and see if what they're getting is what they're paying for. If there's a legitimate "multi-hop" VPN service out there, we've yet to find it... maybe it exists, but it's certainly in a very small minority. (note: lack of comprehensible technical explanation of exactly how "multi-hop" is implemented is a red flag that it's not actually implemented)
In addition to significant - and, increasingly, impossible-to-ignore - security benefits that come with a layered network topology, there's other tangible benefits when it's done right. First, network sessions can be intelligently routed across the network, rather than being mere single-shot straight lines from the customer to the server. This allows, for example, a close-in node to act as "entry node" (we call them "jump nodes," because it sounds cool - and we liked Frogger alot way back when), collecting member traffic together physically closer to members so their sessions aren't as easily visible to traffic correlation attackers. Close-in entry nodes get member traffic into the network faster, in other words - and that's better.
On the way out of the network, things are even more interesting. If we are able to have dedicated "exit nodes" (we call them "exit nodes"... because we couldn't think of a cooler name), then we can put those in specific places where exit IP (which is to say: publicly-visible IP) needs to be geographically precise in order to access specific content. So, speaking hypothetically (and looking in your direction, Netflix...), let's say someone wants to access content that's geo-locked to a specific country. Having an exit node in that country is mandatory, to access that material. Once we split exit nodes off separately from the rest, in a layered network model, we can put them all over the place - and not need to have customers sending long, exposed individual network connections back and forth to each and every one.
Ok so great: layered network models are cool. But they're complex, and no "VPN service" in existence today actually implements one in any meaningful way. What does that have to do with "Beyond VPN" network service, and with the future of cryptostorm?
Turns out, quite alot. Because: voodoo networking.
~ ~ ~ ~ ~
Last fall, we announced alpha testing phase for what we called "voodoo networking." This new function allows us to split off the encryption/decryption tasks of a node from the routing/exit-transit task, by way of some clever use of existing bits and pieces of opensource network technology. When we opened up the alpha voodoo test, we weren't at all sure how to think about what we'd created. So, rather than sit and try to puzzle it out ourselves, we asked the community to help us kick the tires, go for a test drive, and work with us to get a feel for what we could do with this new thing that would make life better for cryptostorm's members.
After a winter of hands-on experience with voodoo, we faced a choice: keep this new capability as something limited, expensive, and premium - separate from "standard" cryptostorm. Or... roll it out everywhere? Sure, there's middle-ground compromises - but we wanted to look at the edge-cases and see if there was an answer sitting right there.
There was.
Once we are able to do voodoo, there's actually no reason not to do it across the whole network. The benefits are obvious (even if the "how we are able to make it work" part is... a challenge to explain in nontechnical terms). The deciding factor turns out to be decoupling the routing workload from the crypto workload, for exitnodes and what we're calling "supernodes," respectively. As we experimented with alpha voodoo supernodes, we saw we could provision, deploy, and administer them in subtly - but powerfully - different ways than we needed to do if they were old-style dual-function nodes. We could add lots of IP addresses to them, and not worry they'd get blacklisted by this or that website... since nobody ever sees these IP addresses as exit IP address of customer traffic! And, since exitnodes don't do crypto work, we could comfortably put them in places we'd not trust a conventional dual-purpose node (note: exitnodes also never see the physical IP of customer computers - so even if they're seized or taken over, they have no sensitive knowledge on them... including token hashes, or anything else)
...oh, they can also be VPS servers - since they don't do crypto, and don't carry crypto keys or credentials - which means we can vastly expand the range of exitnode geoIP locations, in the voodoo-everywhere model. Which is very nice, indeed.
The decision, in the end, was easy: it's not that we're deploying voodoo as a new feature for cryptostorm... it's that voodoo and cryptostorm become the next iteration of the cryptostorm network itself.
~ ~ ~ ~ ~
In practical terms, things aren't nearly so complex as they might appear when reading through the technical materials on voodoo - and even when reading this nontechnical overview. That's important, as a feature that's so complex to use as to be overwhelmingly intimidating is basically useless to members themselves. So we have worked through the mechanics of how we'll make the voodoo capabilities available to members in a way that's not complicated, annoying, or prone to frustrating misunderstanding.
Here's how that works:
Existing "anchor nodes" in various countries around the world are shifting to a role as voodoo "supernodes." Customers will connect to them directly. If they want to also exit from that same geographic location, they will default to an exitnode in the same place that routes their traffic in and out, from there. (some exitnodes will be full, dedicated machines and some will be streamlined VPS servers, depending on local market conditions)
In addition, however, customers using the new widget3 will be able to choose their exitnode, as separate from their initial connecting supernode. That exitnode can be anywhere in the world, and will be the place from which their internet traffic appears to originate. So, for example, a member connecting through our in-provisioning Bucharest supernode ("Balaur") wants, she can choose as exitnode one in Mongolia (yes, that's in-process, as well)... or anywhere in the world, really, where demand is enough to justify an exitnode or three. To the internet, Balaur doesn't exist - only the exitnode IPs are visible. But, to the member herself, she knows her traffic routes first to the supernode, and then to whatever exitnode she has chosen.
From a user interface perspective, node selection goes from one list to two lists: supernode, and exitnode. We'll have, in the widget, defaults so that someone not interested in fiddling with exitnode selection simply defaults to nearest-exitnode selection for a given supernode. Yes, there's more work for us to do, behind the scenes, to keep all this cleverness straight and well-organised... but for members, no extra drama comes with the voodoo'ing of cryptostorm.
Finally, there will be some performance-tuning of the new, multi-layered cryptostorm network topology. Based on alpha voodoo results thus far, we don't see an showstopper performance issues - the specific technology we use for voodoo functionality is well-matured and doesn't represent an intrinsic bottleneck to speed (throughput or pingtimes). But, we might need to do a bit of polishing here and there as we see broader usage of multi-layer voodoo cryptostorm sessions. In some cases, we know performance results will be better, since packets won't be left to the vagaries of bareback routing so long as they're inside a cryptostorm/voodoo tunnel. Though, of course, choosing a supernode that's half-a-world away from the selected exitnode will introduce pingtime lags because... well, because the speed of light! :-) That's not a bug, really, so much as a feature - of the universe we call home.
- - -
There's no longer any separate "voodoo network" feature that sits outside of cryptostorm. The two are in process of merging.
In deciding that, we also have decided that this multi-layer capability isn't something we'll charge extra for, or add as a "premium" service to cryptostorm's existing network access tokens. It's just not how we prefer to do things - tiered service like that - so we've decided against doing it. Holders of existing alpha testing voodoo tokens, having helped enormously to bring this new capability to the network overall, will be showered with praise, honour, and bounteous streams of jewels... or anyway we'll make sure good things happen, to recompense them for their generous support of voodoo at a critical time.
At this point, the ball is in our court.
We'll start pushing out supernode-exitnode "voodoo" options in the existing 'Narwhal' windows widget, as we provision the needed network infrastructure. When the 'Black Dolphin" widget releases to full beta testing, it'll have the two-menu supernode-exitnode setup, as described above. For Linux folks... we'll work with the community to figure out how to generate .conf files to make use of voodoo functionality in an efficient, elegant manner. And, yes, we'll need to considerably upgrade our old procedures for announcing new nodes (of whatever type), and when old nodes have gone down (but, fortunately, we won't be losing supernodes - which are shielded from public view - as we've so often lost nodes in the past, and scrambled to continuously replace them on a rolling basis); exactly how we do this announcement of available network nodes and resources is... an evolving process.
Everyone who holds - or purchases - cryptostorm tokens will have, as it deploys, full access to all this new, multi-tiered network security goodness... because that's how we roll!
Ahem.
"Beyond VPN" is a good way to describe what cryptostorm has become, we think. Since voodoo/multi-layer functionality relies only in part on actual "Virtual Private Network" tools to make it work (it needs considerably more than merely installation of a VPN server package, and some parameters plugged in, for a start), it seems silly to keep calling it a "VPN service." Because it's not. It's a secure, private network. Or something :-P Maybe someone smart in the community will help us stick the perfect name on what we've created... that's never been our strong suit, in-house, tbh.
- - -
Ten years it's been, since the clever idea of using VPN tools - themselves made so that remote office workers could log in from home, and do work on the office network - went from a fringe concept to a globally-embraced necessity for a significant percentage of people using the internet today. That's a good run, given the tool being used was never intended to protect against heavy attackers... much less global intelligence agencies and military spying machines of unprecedented scale and capability. But, it's only possible to stretch a good idea so far before it becomes flabby and thin. That's happened, with "VPN service" - most of which are, frankly, pathetic.
We've been there throughout that decade: innovating, challenging, heckling (let's be honest, eh?), cajoling, celebrating, bemoaning, exhorting, shaming, arguing, creating, destroying, and working our respective butts off to keep the 99.9% safe from the depredations of the 0.1% when it comes to online life. We knew, a decade ago, that bareback internet use was not going to cut it - and we helped make "VPN service" a credible, and much improved, option.
Now we're moving into the next decade, beyond "VPN service." We run, at cryptostorm, a secure private network. And our multi-tier, voodoo-rooted, globally-meshed new network topology is... the future of network security, in a word (ok, actually five words - but still). That's not hype; well, ok it's not only hype. It's also true.
(see: look at us do marketing - we're marketers, now! ;-) )
This is great stuff, it really is. And: we're excited to run with it, to work with our community here to expand it, improve it, extend it, and in general see what other good things we can do with it. For, it's surely a work in process... as any genuinely new technological approach must be. We can't say we know the total of what all will come of it - but we know it's going in a good direction, and has the potential to further tip the balance between the people and the powerful back in the direction of the people, in the long-range struggle between internet oppression and internet freedom.
And that, friends, is work worth doing.
With respect,
~ cryptostorm's core team
﷽๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎test ﷽๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎asdf﷽๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎ (h/t @NO_BOOT_DEVICE)