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

Current client-side certificate materials ("ca.crt")

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!
User avatar

Topic Author
cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

Current client-side certificate materials ("ca.crt")

Postby cryptostorm_team » Sat Dec 06, 2014 4:41 pm

{direct link: cert.cryptostorm.org}

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:

Code: Select all

-----BEGIN CERTIFICATE-----
MIIFHjCCBAagAwIBAgIJAKekpGXxXvhbMA0GCSqGSIb3DQEBCwUAMIG6MQswCQYD
VQQGEwJDQTELMAkGA1UECBMCUUMxETAPBgNVBAcTCE1vbnRyZWFsMTYwNAYDVQQK
FC1LYXRhbmEgSG9sZGluZ3MgTGltaXRlIC8gIGNyeXB0b3N0b3JtX2RhcmtuZXQx
ETAPBgNVBAsTCFRlY2ggT3BzMRcwFQYDVQQDFA5jcnlwdG9zdG9ybV9pczEnMCUG
CSqGSIb3DQEJARYYY2VydGFkbWluQGNyeXB0b3N0b3JtLmlzMB4XDTE0MDQyNTE3
MTAxNVoXDTE3MTIyMjE3MTAxNVowgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJR
QzERMA8GA1UEBxMITW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBM
aW1pdGUgLyAgY3J5cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMx
FzAVBgNVBAMUDmNyeXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRt
aW5AY3J5cHRvc3Rvcm0uaXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDJaOSYIX/sm+4/OkCgyAPYB/VPjDo9YBc+zznKGxd1F8fAkeqcuPpGNCxMBLOu
mLsBdxLdR2sppK8cu9kYx6g+fBUQtShoOj84Q6+n6F4DqbjsHlLwUy0ulkeQWk1v
vKKkpBViGVFsZ5ODdZ6caJ2UY2C41OACTQdblCqaebsLQvp/VGKTWdh9UsGQ3LaS
Tcxt0PskqpGiWEUeOGG3mKE0KWyvxt6Ox9is9QbDXJOYdklQaPX9yUuII03Gj3xm
+vi6q2vzD5VymOeTMyky7Geatbd2U459Lwzu/g+8V6EQl8qvWrXESX/ZXZvNG8QA
cOXU4ktNBOoZtws6TzknpQF3AgMBAAGjggEjMIIBHzAdBgNVHQ4EFgQUOFjh918z
L4vR8x1q3vkp6npwUSUwge8GA1UdIwSB5zCB5IAUOFjh918zL4vR8x1q3vkp6npw
USWhgcCkgb0wgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJRQzERMA8GA1UEBxMI
TW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBMaW1pdGUgLyAgY3J5
cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMxFzAVBgNVBAMUDmNy
eXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRtaW5AY3J5cHRvc3Rv
cm0uaXOCCQCnpKRl8V74WzAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IB
AQAK6B7AOEqbaYjXoyhXeWK1NjpcCLCuRcwhMSvf+gVfrcMsJ5ySTHg5iR1/LFay
IEGFsOFEpoNkY4H5UqLnBByzFp55nYwqJUmLqa/nfIc0vfiXL5rFZLao0npLrTr/
inF/hecIghLGVDeVcC24uIdgfMr3Z/EXSpUxvFLGE7ELlsnmpYBxm0rf7s9S9wtH
o6PjBpb9iurF7KxDjoXsIgHmYAEnI4+rrArQqn7ny4vgvXE1xfAkFPWR8Ty1ZlxZ
gEyypTkIWhphdHLSdifoOqo83snmCObHgyHG2zo4njXGExQhxS1ywPvZJRt7fhjn
X03mQP3ssBs2YRNR5hR5cMdC
-----END CERTIFICATE-----


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.

Thanks,

cryptostorm_team

User avatar

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

Re: Current client-side certificate materials ("ca.crt")

Postby parityboy » Sat Dec 06, 2014 6:36 pm

@cryptostorm_team

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. :D

User avatar

jlg
Posts: 92
Joined: Mon May 05, 2014 2:44 am

Re: Current client-side certificate materials ("ca.crt")

Postby jlg » Sat Dec 20, 2014 5:38 pm

This is kind of essential if using a connection manager software within Linux/BSD.


Return to “cryptostorm in-depth: announcements, how it works, what it is”

Who is online

Users browsing this forum: No registered users and 9 guests

Login