Ξ 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 Ξ

Looking for a bit more than customer support, and want to learn more about what cryptostorm is , what we've been announcing lately, and how the cryptostorm network makes the magic? This is a great place to start, so make yourself at home!

Since our issuance of new server-side certificate materials after the 'heartbleed' vuln was publicly disclosed, there's occasions when members with old configuration files (or folks who find old materials archived or cached on third-party sites and attempt unknowingly to use these) occasionally need to find our "new" certificate materials in order to successfully connect to cryptostorm.

These materials are embedded in every current (rev. 1.3 or higher) "conf" file we provide, as well as in all current builds of our client widget. However, for convenience, we're posting that cert material here in the event folks have a need to access it without hassle:

You can use an web-based tool, or suitable command line utilities, to "unpack" the PEM-encoded certificate into human-readable form. This helps you understand the identification of the server that the certificate is vouching for, as well as some of the important cryptographic attributes of it that may (or may not) increase your confidence in the certificate.

If you're curious about what this block of gibberish is, and why it's part of connecting to cryptostorm, this short overview explains the procedural side of things. In a nutshell, this bit of text helps verify that the "server" to which you are connecting during a cryptostorm session is actually one controlled and managed by cryptostorm, and not an imposter posing as cryptostorm (these attacks are broadly known as "Man in the Middle" attacks; or MiTM). This text, via a cryptographically strong method, acts as a sort of 'fingerprint" of a private key held only on cryptostorm's servers and carefully protected from outside access (the risk such keys were accessed as a result of the 'heartbleed' bug mentioned above is why we re-issued new certificates - and new private keys - on all our servers earlier this year): only someone with the private key can prove that they have that key, and they need not do so by actually showing the key itself but rather by a process of "public key cryptography" that allows for this kind of "prove but don't publish" validation.

In this step of the process of connecting to cryptostorm and exchanging data securely, public key cryptography is actually not being used to encrypt any data. Rather, this is solely a means of validating server identity; it uses the same maths as public key crypto that encrypts data (actually, it encrypts transient symmetric keys that then, themselves, are used to encrypt data... but we digress), but instead is using that math to confirm the server is genuine. Here's a snippet from a well-written Mozilla foundation site explaining SSL, PKI, public key crypto, and how it all interconnects in both theory and practice:

"SSL requires a server SSL certificate, at a minimum. As part of the initial "handshake" process, the server presents its certificate to the client to authenticate the server's identity. The authentication process uses public-key encryption and digital signatures to confirm that the server is in fact the server it claims to be.

Cryptostom's use of PKI infrastructure during session initiation with members is different from that used in "default" openvpn installations. We have removed the elements relating to PKI verification of client identity. Those curious about why we feel this provides important security benefits for our network members will find a more detailed explanation of the analysis in our intro to token-based auth; this paper explores the assumptions implicit in naive, bidirectional PKI-based "VPN service" authentication models, and outlines why we feel these assumptions are counterproductive to member security in our production environment. Occasionally, members or outside observers conclude that we "don't understand cryptography" because we haven't blindly followed the instructions for default openvpn installations. We hope that a review of the token auth paper will dispel the sense that we've simply "not read the manual," although simply doing something different from default is not in and of itself an assurance that our approach is better. To make that conclusion, our analytic framework must hold up under both logical and practical scrutiny.

If there are any questions or requests for additional explanation, please do not hesitate to post them in this thread.

Cryptostom's use of PKI infrastructure during session initiation with members is different from that used in "default" openvpn installations. We have removed the elements relating to PKI verification of client identity....Occasionally, members or outside observers conclude that we "don't understand cryptography" because we haven't blindly followed the instructions for default openvpn installations. We hope that a review of the token auth paper will dispel the sense that we've simply "not read the manual," although simply doing something different from default is not in and of itself an assurance that our approach is better. To make that conclusion, our analytic framework must hold up under both logical and practical scrutiny.

That's because a lot of network members don't develop client<->server software. The old adage "never trust the client" will hold true until the Sun burns itself out.