Hello,

Linux Mint Rebecca, Everything up to date, just bought a new token (hashed from the cryptostorm.is tool), certificate ca2.crt from the Ubuntu Connection guide forum post. Unable to connect to any server with this set up:

Dec 24 16:21:07 xx NetworkManager[866]: <info> Starting VPN service 'openvpn'...
Dec 24 16:21:07 xx NetworkManager[866]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 12143
Dec 24 16:21:07 xx NetworkManager[866]: <info> VPN service 'openvpn' appeared; activating connections
Dec 24 16:21:07 xx NetworkManager[866]: <info> VPN plugin state changed: init (1)
Dec 24 16:21:07 xx NetworkManager[866]: <info> VPN plugin state changed: starting (3)
Dec 24 16:21:07 xx NetworkManager[866]: <info> VPN connection 'cryptostorm_client_raw-iceland1_3' (Connect) reply received.
Dec 24 16:21:07 xx nm-openvpn[12148]: OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014
Dec 24 16:21:07 xx nm-openvpn[12148]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Dec 24 16:21:07 xx nm-openvpn[12148]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 24 16:21:07 xx nm-openvpn[12148]: UDPv4 link local: [undef]
Dec 24 16:21:07 xx nm-openvpn[12148]: UDPv4 link remote: [AF_INET]79.134.235.132:443
Dec 24 16:21:09 xx nm-openvpn[12148]: VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=CA, ST=QC, L=Montreal, O=Katana Holdings Limite / cryptostorm_darknet, OU=Tech Ops, CN=cryptostorm_is, [email protected]
Dec 24 16:21:09 xx nm-openvpn[12148]: TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Dec 24 16:21:09 xx nm-openvpn[12148]: TLS Error: TLS object -> incoming plaintext read error
Dec 24 16:21:09 xx nm-openvpn[12148]: TLS Error: TLS handshake failed
Dec 24 16:21:09 xx nm-openvpn[12148]: SIGUSR1[soft,tls-error] received, process restarting

Please help!

Could you copy/paste into a reply the exact certificate materials that are included in the configuration file you are using to connect? I strongly suspect that there's a problem relating to the pre- versus post-heartbleed certificate matching that's going on here. For details and likely a quick solution as well, here's the post with the cert information.

Let us know if that doesn't get a solution straightaway, in which case we'll work with you to get to the bottom of things!

Thanks,

cryptostorm_support

Ubuntu,

You're connecting with ca2, which is post heartbleed, to 79.134.235.132, which is a pre heartbleed node. Please connect with the ca2 certificate to one of the post heartbleed nodes.

/Fermi

Heylo,

The cert is the cert from the link you posted Support - I copy and pasted it exactly, made sure there were no spaces. I am using the .conf files from the Current Conf files page.

Re: Fermi, I have seen some peeps with node lists in their signatures, but I'm not sure how to update my node. I thought the conf file was supposed to handle that. Maybe it's cached in my computer?

Thanks for your collective help!

@Ubuntu

That node list has been truncated to only reflect Windows instances - that nodelist is actually used by the Windows widget. Below is the complete list of "raw" (Linux/Android/iOS-compatible instances:

Sweet, thanks parity!

I replaced all the cluster urls with that IP in the gateway and it worked! Though I am curious as to why a single IP address can replace 4 different URLs I'll have to read up on this.

Thanks again for your help!

Ubuntu wrote:I replaced all the cluster urls with that IP in the gateway and it worked! Though I am curious as to why a single IP address can replace 4 different URLs I'll have to read up on this.

Eek

While we don't prevent direct-IP network connections, the reason you see the four hostnames in our standard config files is to ensure resilience and durability against some forms of denial-of-service attacks on our network as a whole. This isn't something that would lower security levels for an individual session - which is why we make no effort to actively block dirrect-IP member connections - but overall it makes the network more vulnerable to attackers seeking to prevent successful network sessions.

If you're curious as to how this works in practice, I've rambled a bit on the topic in a cryptofree subforum thread; the underlying logic is identical, either way. For a shorter explanation here's a post from earlier this year, as we were still consolidating this element of our network.

Finally, if you're curious as to the full structural underpinnings of that system, which we refer to as our Hostname Assignment Framework, you can read the full HAF whitepaper.

Cheers,

~ pj

Hey PJ,

Thanks for the links. I skimmed through the longer ones and selectively read this thread: viewtopic.php?f=32&t=6028&p=8081#p8081 - so my understanding is that the issue I'm facing is because I'm using Network Manager on a Ubuntu-derivative and it has issues interpreting multiple server addresses with an encrypted login.

Short form (again) is that "compression + encryption = asking for security fail" - and that's a general rule I have seen play out true enough times over the years to take as nearly axiomatic.

Later in the thread the CS team state that they've updated the .conf files to handle linux NetworkManager connections, and then some peeps say that it's been fixed for them. But as this was in January of this year things have been switched over because of Heartbleed (that was this year right?) and so the servers have been updated. But it seems that now the *official* conf files posted no longer work with the *official* post-heartbleed cert file, or at least they don't for me using Linux Mint (Network Manager). And while I seem to be one of the few non-programmer types using CS and linux that I've now ended up with a direct IP workaround (which, from what you've posted, is not the end of the world but I will have to come back here to check anytime the server IP gets changed (nbd)), it seems like I should make a formal request (herein) to have the CS_Support team to update the .conf files to work with the post-heartbleed certs on Ubuntu & derivatives. So that my client-experience would be standard with other platforms (windows, etc.) Not that either way of connecting affects me profusely, I'm just happy that it works now.

Apologies if I'm misinterpreted the situation.
Thank you,
U

Ubuntu wrote:Later in the thread the CS team state that they've updated the .conf files to handle linux NetworkManager connections, and then some peeps say that it's been fixed for them. But as this was in January of this year things have been switched over because of Heartbleed (that was this year right?) and so the servers have been updated. But it seems that now the *official* conf files posted no longer work with the *official* post-heartbleed cert file, or at least they don't for me using Linux Mint (Network Manager). And while I seem to be one of the few non-programmer types using CS and linux that I've now ended up with a direct IP workaround (which, from what you've posted, is not the end of the world but I will have to come back here to check anytime the server IP gets changed (nbd)), it seems like I should make a formal request (herein) to have the CS_Support team to update the .conf files to work with the post-heartbleed certs on Ubuntu & derivatives. So that my client-experience would be standard with other platforms (windows, etc.) Not that either way of connecting affects me profusely, I'm just happy that it works now. U

The official conf files are, to be blunt, something of a mess right now.

This is mostly the result of our decision to bridge the heartbleed gap with pre- and post-heartbleed instances on servers. That decision reflected an understanding of how important backwards compatability is for many of our members: think of folks who have "baked-in" settings to gadgets such as routers or other hard-to-update devices. If we just shut off all pre-hb instances, they'd see sessions drop immediately and that is simply not the right security choice. In those contexts, members were deploying upgrades in a scheduled, tested manner along the lines of IT operations procedures.

Anyway, blah blah... point is, we found ourselves with a bit of a mess in the confs due to the heartbleed reaction and our slow-but-steady move to full HAF compliance. This has been a tedious, time-intensive, high-stakes process that has gone on behind the scenes for months. We are now - finally - starting to roll out configuration files with the new (HAF-compliant) 1.4 settings in them.

Once those 1.4's are all complete - a project coming very close to fruition this week, with the addition of our HAF-compliant central US exitnode cluster - we will go through and ruthlessly prune all old conf's from the forum. That transition also shuts down the final remaining pre-hb instances, as we've worked most all members through the instance upgrade process and thus can finally spin them down entirely.

Net result is that the config files, from 1.4 forward, will be vastly less complex, contradictory, and likely to need major updates to retain full functionality moving forward.

The best we can do is apologise for the ugly little mess that's been present, meanwhile, when it comes to conf's. Windows folks mostly just use our widget to connect, and thus are shielded from all this by our updates of onboard widget conf's with each build. Linux (and OSX) folks get the full brunt of the conf messiness, and the best we can do is apologise for that and continue to work hard towards the completion of the 1.4 upgrade.

I'm also comfortable sharing that we've had a good bit of healthy team debate about many of the issues relating to the 1.4 upgrade, HAF, pre/post-hb procedures, and so forth. Each one of these topics, interestingly enough, tends to dig into deeper, more long-range questions and that's allowed us to really refine our goals as a team for 2015 and beyond. It hasn't helped get the 1.4 deploy finished, to be honest... but it's really helped the project overall, even so.

In the event, apologies for the hassle - the cause is us, not you. We're working fast - but carefully - to get to a place in 1.4 where these issues are only fading memories.

Cheers,

~ pj

ps: there's also an interesting self-selection bias at work here, in that many/most folks posting here in the forum seem to be technically minded and often are Linux users. Thus, one might conclude that most cryptostorm members fit that profile - which I'd say is almost certainly not true (can't say for sure, as we know next to nothing about nearly all our members, due to the token model). Rather, the silent majority of cryptostorm members using the widget to connect simply never come to the forum, let alone post with questions or problems to resolve. Thus, their silent voices don't balance out us geeks clicking away endlessly on our keyboards in here

Hah, no doubt. I've used the widget on Windows before and it worked seamlessly for me, but I decided to go full linux this summer when I had some computer troubles and didn't want to pay the Microsoft Tax. People don't engage in politics, tech forums, communities, when things are going their way. (Hence why we get the Tyranny of the Minority in many contexts). I would think that the CS user base is reflective of the general OS user base, mostly windows, some mac, less linux, rising Android and iOS usage. (You might be able to measure by looking at the accessing broswer data on the cryptostorm website (this would be a very rough guide).) Anyways, Linux users are used to figuring out work-arounds, it keeps me fresh on tech anyways.

Understandable about the slow transition considering the embedded devices, this is something I hadn't considered before. Happy to hear about the impending 1.4 release. And please don't take my previous comments as a complaint, though I do appreciate the clarification. I quite enjoy the community model and rapid response from an engaged group. I'm just using it mainly for trips and cafe/public wifi security, nothing mission critical on my end.

Thanks for your help PJ,
U

P.S.: this is probably out of context to what you were referencing re: future tech planning but whenever a group mentions strategic planning I'm bound to mention my quasi-fanaticism for coop's. If you are long term structural planning may I suggest a team organization based on a worker co-op style? http://www.canadianworker.coop/worker-co-op (probably not relevant for CS's current size, but a decade out it's a good model for a sustainable workforce)