A few weeks back, we shared (via a post on the cryptohaven blog) a pre-release glimpse of what we were calling at the time "haven tokens." Specifically, this is the section discussing this new thing we'd created...
Shortly thereafter, df published a high-level technical summary in the repository we created to support code and configuration publication. In part, he noted that...Today, we're proud to say that we've begun "alpha" testing of this new capability... even though we don't really have a name for it yet ("network.wtf" has been floated by one team member around here... most folks who know us can likely guess who that is, too).
But we know what it does, and that's something close to magical.
All the data coming and going from these new cryptostorm secure sessions will have metadata that don't match up to a full-scale cryptostorm server (a "dedicated node"), but rather look as if they come from a transient, disposable "sub-node" that can be located geographically anywhere in the world. The cryptostorm server still does all the actual cryptographic work - the part that requires heavy security for the computer doing it - but to the outside world, the data come and go from these temporary sub-nodes... and those sub-nodes, in turn, come and go as often was want to create, use, and delete them.
With this new capability, an attacker trying to make sense of what is coming and going from cryptostorm faces a kaleidescope of ever-changing addresses, routes, and servers... none of which are our actual physical servers. It's sort of like we're able to "chaff" our metadata with whatever we want - without doing anything to limit the transit of member traffic along the way.
At around the same time, we settled on "voodoo networking" as a name for this new thing we've created... or just 'voodoo' for short. We think that, as the impact of voodoo networking becomes clear over time it will also become obvious that the term "voodoo" was perfect for this particular networking magic....CS only uses dedicated servers for our exit nodes. The unmetered dedicated servers we prefer can be very expensive in some locations. That's the main reason CS has such few IPs.
A lot of VPN providers will run an OpenVPN server on a VPS because a VPS is dirt cheap compared to a dedicated server. However, it's impossible to secure the OpenVPN process on a VPS since it's just a VM guest, and the server that's the VM host can monitor anything going on in the VM guest (or mount the VPS' hard drive image file somewhere and grab the private OpenVPN keys and use them to decrypt client traffic).
That's the reason CS has never used a VPS for running an OpenVPN server.
With this setup, we can use a VPS as the exiting point for VPN traffic without any of the aforementioned VPS security issues applying.
Alpha 'voodoo tokens'
In order to test, refine, and improve the voodoo capability, we decided to release a small batch of tokens for use with the initial voodoo-enabled components of our network. These tokens, to be clear, do not enable access to cryptostorm overall (that's why we've included conventional six-month cstorm tokens in the alpha packages created). Instead, they are tied specifically to the voodoo infrastructure. This allows us maximize what we learn from the test, without setting this strange new capability loose on the entire cryptostorm network until we're fully prepared to do so.
Having made that decision, we went ahead and wippped up a 'buy button' enabling the purchase of alpha voodoo tokens. For $56 (plus, enigmatically, a "shipping charge" of $3.50 that nobody can explain... but seems appropriately mysterious for the voodoo deploy), members receive a dedicated voodoo token for the alpha testing, plus a six-month (conventional) cryptostorm token...
After a week or so of internal discussions and brainstorming, we're good to go.
Voodoo: The Brass Tacks
When a cryptostorm member initiates a voodoo session with our network, there's no longer a linear path through which each packet comes and goes. Instead, outbound packets take a "detour" to a voodoo node (a VPS instance that can be anywhere in the world), although they remain encrypted during this side trip. When they hit that voodoo node, their header metadata updates: in particular, source IP address for the packet is set as the voodoo node IP address. However, the packets then return to the core node - a full-bore, dedicated cryptostorm server - are, decrypted by openvpn, and transit out onto the internet.
The voodoo is that the packet retains the source IP address of the voodoo node, from that detour it took in mid-session. Normally that source IP would be listed as the exitnode (what we're calling a "core node" here, since exiting becomes a multi-step process in the voodoo model). So, when you visit sites or run an "IP test," they show that voodoo node as your physical IP address.
It's kind of simple, but at the same time totally contrary to many assumptions we all have regarding IP networking. But it works, it's "legit" in terms of internet standards, it's not faking or "spoofing" anything.
For the alpha test, we've set up two resolvers to which alpha token holders will connect:
- windows.voodoo.network
linux.voodoo.network
Each of these, in turn, we'll be directing at various voodoo topologies: different exitnode/"core node" locations, different voodoo node side-trip detours, etc. That's why we're doing this as an alpha test. Some of this will be a bit "on the fly" and fluid as we make use of the traffic from alpha testers to get a feel for things like bandwidth requirements, performance tuning, latency management, and so on. Nobody's ever done voodoo networking before, so we can't go to the literature to get a feel for any of these questions. We're breaking new ground, and the alpha test helps us do that in a more systematic way.
It's likely we'll spin up additional voodoo resolver mappings during the alpha test, to allow for specific voodoo trajectories through the network. But the main windows/linux resolvers will always point to live voodoo nodes during the alpha test.
There's a few minor tweaks to our version 1.4 configuration files, that are needed to enable voodoo functionality. We've posted the test-phase versions of these configs in the voodoo githhub repository and we'll likely be revising and fine-tuning those as we go, as well.
That's that, in terms of voodoo cstorm connections.
Alpha Voodoos: Gathering & Integrating Feedback
Rather than rushing voodoo into full production and putting on a big marketing push, we've chosen to take a stepwise, test-heavy approach. In addition to what we've said above, we find it absolutely imperative that we have a strong confidence in the security profile of voodoo sessions.
To be clear, in theoretical terms there's nothing here that changes the core cryptographic model of our network. However, lots of things that seem fine in theory break down in reality. Since voodoo truly is new, we're going to make sure we have a good sense of how it plays in security terms, before we put our stamp of confidence on it and make it avaliable to the membership overall.
So let's put this one in bold letters, just to be clear (we don't do this often, but when we do it's for good reasons):
- Voodoo sessions during the alpha testing phase are a work in progress. Do not trust your life or safety to them until we've completed the alpha test and published results. This would be a very reckless thing to do. While we don't expect security issues in voodoo sessions, we're also quite paranoid enough to be cautious until the hard data come back to confirm things are all working as expected. This is an alpha test, not meant for life-and-death network security scenarios.
We'll be glad to accept feedback from alpha voodoo testers via any channel that works for them. Perferred, however, is a thread in this subforum (we'll be opening a dedicated alpha test feedback thread shortly) or 'issue' reports posted to the github repository. Anyone who purchases an alpha voodoo is welcome to join the repo and participate in its management; if you've not done that before and would like to learn how, post a reply in this thread and we'll get you connected with someone experienced in github-fu.
Finally, we've created a dedicated email distribution address - alpha@voodoo.network - that sends copies of inbound correspondence to the tech team members working directly on the voodoo project, as well as our support desk. So if you've got questions or an issue or just want to get ahold of someone voodoo-aware on our team, that's the quickest way to do so.
In terms of communications, we'll be posting the usual updates and commentary on the voodoo test in our main @cryptostorm_is feed, of course. However, since that can be a bit heavy in volume and tone for some folks, we're also cross-posting all #voodoonet-tagged tweets to the human-friendly @cryptohaven twitter feed, as well. So if you want to get your voodoo updates with minimal chatter, that's the place to go.
In Conclusion...
In conclusion, we've no doubt that there will be additional issues that we've neglected to add into this tutorial on alpha voodoos. As they arise, we'll edit this first post in the thread, to keep it current. If it's a notable addition, we'll post a reply with details on the edit. And, of course, input and questions and most anything else contributed by the member community is most welcome in this thread.
Voodoo networking is, by definition, a work in process. Rather than pretend otherwise, we've embraced that and are seeking to use that fact to improve and acccelerate the voodoo revolution itself. It'll be a bit chaotic sometimes, and messy in the way all organic things can be messy... but we think that's healthy, especially in a security-focussed context like this.
Kick the tires, test it out, collect data on your voodoo sessions and post them here. Ask questions, challenge our assumptions, suggest ways we can use voodoo to make even more secure network systems in the future. Voodoo isn't "owned" by cryptostorm - we've already published the baseline techniques that make it work, and we'll keep publishing details as they settle into stable form - but rather is a technique that is freely available for use by anyone, in any context. Let's get things rolling on a good foot, so this new tool in counter-surveillance technology has the best start on a revolutionary future.
Oh right, one more thing: how long will the alpha voodoo tokens be valid for, and how long will the alpha test run? We don't know test duration in advance, because testing is always an emergent process. In general terms, we expect to spend a month or so in alpha phase, before rolling forward to a much more broadly available beta test. The beta test will likely run until the new 'Black Dolphin' widget version releases, at which point voodoo functionality will be seamlessly integrated into the cryptostorm network overall. That's an early/mid-fall target, for the release of Black Dolphin.
Folks who purchase alpha voodoo tokens will also, of course, have full access to beta voodoo functionality. Once voodoo is fully integrated into the new widget release, and is no longer a standalone/separate sub-network within cryptostorm, we'll be spinning down the separate voodoo tokens entirely.
When we do that, we'll provide to our alpha voodoo testers newly-issued "tokens(2)" ECC-based, c-25519 keypairs of duration 169 days. Because, yes, we are deploying a completely revised and upgraded, cryptographically enhanced token model as part of the Black Dolplin deployment this fall. We've putting details on tokens(2) in a separate thread, here... but if you've wondered why voodoo tokens are a bit weird compared to "normal" tokens, that's why: they're a first iterations of tokens(2).
Derp, almost forgot: YourNickHere@voodoo.network
Everyone who picks up an alpha voodoo token gets a {whateveryouwant}@voodoo.network email account... that is soon to transition to an SMTP/POP#/bitmessage gateway via our bitmessag.es comms gateway. Which might come in handy for this and that... who knows?
Tally ho,
~ cryptostorm
