The way we do things, it's important for clients (i.e. network members) to ensure that they're connecting to our actual mesh of exitnode servers. If that's not assured, there's a risk of "man in the middle" (MiTM) attacks where someone pretends to be cryptostorm and tricks a client into connecting to their fake "secure" network. This is a bad thing, and we work hard to protect against this thread vector.
A big piece of this is done via the tools known as "public key infrastructure" (PKI). There's some mathematical cleverness underlying the whole model, but leaving that aside it's pretty simple to follow:
- We make available a fingerprint (called "ca.crt") that is generated from a private, secret key we never disclose to anyone. The fingerprint can only match up to our private key - it's really hard to fake that match-up (in mathematical terms, it's intended to be "computationally intractable"). With that fingerprint, which we can and do publish publicly and share with anyone who wants it, anyone can confirm that a server claiming to be cryptostorm is, in fact, cryptostorm. Someone pretending isn't going to be able to do the 'secret handshake' with that fingerprint, and validate their identity.
The attached file is our current "ca.crt" - the fingerprint we publish, for anyone to confirm that network sessions intended for our secure exitnodes are in fact connecting to our exitnodes, and not to someone pretending to be us. This fingerprint is required for all
network sessions with cryptostorm. Without it, we don't allow someone to connect.
Why do we care? Because if someone connects without going through the cryptographic process of confirming that fingerprint matches our and only our secret key
, they are at real risk of being MItM'd. That's a security risk for our members, and therefore we enforce against it by preventing network connections without that fingerprint-confirm step. This has nothing to do with verifying the identity of network members themselves - not at all. It's a validation of the network
If you're doing raw/direct access to our network (using, of course your network access token
to show you're entitled to network usage), you'll need to save this "ca.crt" file into your local openvpn directory (which varies based on your operating system). It's the only file you need. We're going to be "inlining" this in the client-side configuration files
, in the future. For now, we're keeping it separate to help clarify what it is, why it matters, and how it fits into the whole security model.
Again, this isn't a secret file - it's intended to be public! It's not a "private key" and it doesn't "decrypt" anything. Indeed, it's not used at all for any encryption of data. Rather, it helps confirm that our servers are actually our servers. That's all - it's very important, but it's also a very limited function it serves.
Down the road, we're going to be experimenting with forward-looking PKI architectures such as Moxie Marlinspike's "Convergence" system. They're really compelling, and add some real additional security. Right now, we're actively NOT
using the traditional "certificate authority" based system seen in the HTTPS framework commonly. That system is badly, badly broken
- horrifically so! Instead, we "self-sign" our ca.crt file. That's not a bug, and it's not because we're lazy. Rather, it's because (until we integrate with Convergence, per above) this is the most reliably secure way to do this part of our security model. Having Comodo or some other lame-assed CA "validate" who we are is a terrible plan - and we're not doing it.
Also, the reason this file looks like "gibberish" is because it is! This is a result of the mathematical relationship between this "public key" and the "private key" which is kept secret on our servers. If this file looked nonrandom - if it had a bunch of 111111s in a row, or whatever - that would be a really bad sign that something was wrong.
[EDIT: changed download and code immediately below to reflect post-hearbleed certs
Code: Select all