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

cryptostorm: our replies to TorrentFreak's VPN hype

Freewheeling spot to chew the fat on anything cryptostorm-related that doesn't fit elsewhere (i.e. support, howto, &c.). Criticism & praise & brainstorming & requests for explanation... this is where it goes when it's hot & ready for action! :-)
User avatar

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

cryptostorm: our replies to TorrentFreak's VPN hype

Postby cryptostorm_team » Thu Oct 10, 2013 1:34 pm

Posted in reply to this nicely-done survey of the "VPN service" landscape:

Nicely done - a pleasure to read something written about the "VPN industry" that isn't littered with affiliate marketing linkspam intended solely to generate commissions for the author.

On a technical note, the ability of a VPN-based secure networking service to protect against MiTM is directly related to the cryptographic framework and implementation specifics of that particular service. For example, counting on a PPTP-based VPN to limit MiTM is worse than useless since it actually gives a false sense of security to nontechnical folks who assume that "encryption" means "reliable, not-broken encryption." (PPTP has been known-broken, at the protocol level, for more than a decade)

Finally, the issue of leaky VPN-based "privacy services" is one that is finally getting some wider attention now that the NSA's attacks on Tor (the torsploit/Freedom Hosting attack in August, and the Silk Road attack in October) are acting as a warning shot. Leaked packets can be fatal in quite a few common use-scenarios for "consumer VPN services," and leaks are very, very common. We've done our own wireshark testing on a good-sized handful of proprietary, closed-source VPN client applications distributed by "VPN services" that are aggressive marketers: each and every one leaks like a sieve... and not just DNS leaks, either. Most of this results from a poor understanding of local routing table mechanics, as well as sloppy implementation decisions with respect to tunnel parameter selection.

Someday, an independent researcher is going to wireshark a couple dozen "VPN services" and publish the results: it'll be quite a surprise to anyone who assumes that companies good at stuffing Google with SEO tricks & bribing shady "VPN review" websites into posting fake positive comments about them are actually, you know, technically competent. Many aren't - they're marketing machines grafted onto dodgy technical foundations.

We were recently made aware (via one of our staffers, and the folks at Baneki Privacy Labs) of a "VPN company" that has been slagging "HTTPS" and bragging about how their "perfectly secure" VPN service is far, far better than any protocol like that. Which is funny, really funny. In a dark, tragic sort of way.

Tor has stood up well against NSA-level attacks because the Tor Project is staffed with strong, experienced, talented technologists. They're not perfect, but as a team they've got a hell of a knowledge base - and they're not doing it just to earn enough money to pay their mortgage on a McMansion in Las Vegas, and the debts they owe their sports bookies. This is a very, very different picture than in the "VPN industry" as it currently stands. Quick: name one leading technological thinker in the "VPN industry" (by nickname, or RL name - whichever is preferred for OpSec reasons) who routinely interacts with the rest of the leading-edge minds of the privacy tech community worldwide. Not counting our team (just to be fair).

Yeah, not a very long list, is it? Given the total absence of leading technologists from the vast majority of "VPN services" (i.e. not-us), is it reasonable to assume that the technical foundations of these cobbled-together, for-profit, marketing-driven calamities is strong, reliable, and battle-tested? Hardly.

In due course, there will be a shakeout. Only those teams with genuine technical competence - and a genuine engagement with the larger privacy tech community worldwide - will have any credibility in the market. The rest will be categorized as useless hypeware... the equivalent of bloatware antivirus software that, nowadays, is functionally equivalent to a virus itself.

In the meantime, many customers of these broken "VPN services" are assuming they're safe and secure online - when, in point of fact, they're anything but. Just as the NSA's attacks on Tor didn't become visible until, after years of behind-the-curtain work, they chose to 'out' themselves and take down some big players (which leads to more takedowns afterwards, in a tragic cascade reaction), so you can rest assured LEO is holding fire on these crapware "VPN services" until they've archived enough malfeasance (plaintext) that they're ready to pop the bubble.

Once it becomes public that this "protection" hasn't been real, it'll be too late for folks to go back and retroactively change their behaviour. Something to think on...
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: support@cryptostorm.is
live chat support: #cryptostorm

User avatar

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

DHE, ECDHE, PFS, and OpenVPN

Postby cryptostorm_team » Wed Oct 23, 2013 2:10 pm

A recent comment from a Torrenfreak article sadly light on understanding of basic cryptographic concepts:

The mechanics of provisioning forward secrecy within OpenVPN are nontrivial.

OpenVPN doesn't use any ciphers itself. Rather, it replies on the available OpenSSL (or, less commonly, PolarSSL) suites. OpenVPN defaults to certain ciphers unless it is told explicitly to use others (and only if those others are supported by the OpenSSL framework on the machine it calls home - as well as client-side, of course). IPsec can use just about any cipher out there, but it's hideously complex to implement (we now have strong evidence this complexity was intentionally encouraged by NSA "plants" during the lengthy standards review process).

Unfortunately, Yonan has touted "perfect forward secrecy" as an intrinsic attribute of OpenVPN itself and that's not perhaps a clearcut statement. Yes, default is for (control channel) session re-keying every hour... but defaults also enable massive overlap of earlier keys during this process. Indeed, in many real-world implementations the "overlap" period is longer than the rekey duration itself! That's not PFS, obviously. It's... something rather odd.

Then there's TLS session management itself which - as numerous cryptography researchers have repeatedly reminded the rest of us - can and will break all attempts at PFS if not adjusted in production settings. If there's a "VPN service" that has done so, they've managed to keep that expertise very, very secret - which suggests otherwise.

In the OpenVPN security model, there's also the intial TLS session created to "bootstrap" the control channel instantiation itself... and that early session relies on the "shared keys" which are part of the default configuration of the package. Those keys (both public and private), and their corresponding certificates, are so badly mismanaged by so many "VPN companies" as to be almost a form of satire. Unfortunately, those keys are the essential core of the integrity of the initial TLS "bootstrap" session itself - if the asymmetric handshake underlying that early session is implemented inaccurately due to sloppy production engineering decisions (or just total misunderstandings of public key/asymmetric cryptographic primitives on the part of nearly every "VPN company" selling service), then the roll-forward control-channel TLS session is functionally plaintext - whatever cipher suites are used.

Think of it this way: if I call you on the phone and start talking to you, but we agree to hang up every 20 minutes and call each other on entirely new phone lines... this should help keep us secure, right? Well, if someone's eavesdropping on that original call, they can just listen for the numbers we're going to use for the next 20 minutes, then listen in on that call, then roll to the next call, and so on. Thus does "perfect" forward secrecy break.

With a broken bootstrap session, then all the ephemeral whiz-bangery of future key cycling is useless: the whole thing is broken.

Which, in turn requires good selection of nonces, IVs, HMAC methodology, and other routine crypto engineering issues to ensure that initial bootstrap isn't weak. OpenVPN does none of this right by default - it can do it, but it need proper setup. Which includes compiling with custom flags, and manual editing of source to ensure correct integration with current OpenSSL libraries.

None of this is rocket science - but how many "VPN companies" out there bragging about "100% protection" have the slightest idea how to do this, and not screw it up when trying? Use one hand to count, you'll have most all fingers left when done.

Also, regarding discussions of DHE/ECDHE, they're not hard to find when it comes to serious network security providers:

viewtopic.php?f=32&t=3443
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: support@cryptostorm.is
live chat support: #cryptostorm

User avatar

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

Re: When the house of cards comes crashing down...

Postby cryptostorm_team » Wed Oct 23, 2013 8:36 pm

Comment posted in reply to some not-very-impressive reporting on the part of TorrentFreak... sadly, a not-uncommon situation as time goes by:

The bad news comes when one loads those "secure" VPN session pcap's into wireshark & the truth cannot be ignored. As they say, truth hurts.

We've considered scripting up a (simpler) version of Moxie's SSL cracking tools & doing a realtime demo of how pathetically easy it is to break these flawed crypto deployments... but there's two problems. One, it's quite a bit of work and in the end only crypto geeks tend to care (see below). Two, we're just not as charismatic as Moxie - even dreads wouldn't get us in the ballpark! :-)

A big chunk of purchase decisions nowadays are driven by "VPN review" websites - and nearly all of them are straight-up linkfarm scams. They gin up pages of fake "reviews" that inevitably point to the "VPN company" that pays out the highest affiliate sign-up commissions. Why bother pointing out how badly broken so many of these services are, when in the end the scammers running "VPN companies" that are good at SEO cramming & linkfarm bribery are largely immune from criticism that, you know, their crypto deployments suck?

And no, asking "VPN companies" to self-report whether they log or not is not equivalent to real journalism. Sadly, there's a huge gap where credible, trusted, tech-competent journalists should be winnowing out the crap from the few genuine contenders in this service space. Pre-Snowden, that might'be been largely of academic interest (or so they scammers claimed, back then). But now..?

Mostly we don't even bother sending press releases to this whole sordid mess - it's become a caricature of credibility. Sad, but true. The real tragedy will come when the first rollup of people falsely promised "100% protection" against anything but "alien technology" (seriously... wtf - there was an _article_ written here including that kind of specious claim... from a big, lucrative advertiser, not surprisingly) kicks off: we're used to being able to say "we told you so," and we're used to feeling nothing but disgust when obvious predictions like this end up coming true.

Disgust that we haven't been able to do more in providing enough information for folks to make good security choices, that is.

In the meantime, the NSA is slurping up all those lame-ass "super sekure, aliens-proof, 100% protection" VPN sessions, decrypting them on the fly, and storing them in Bluffdale for future use. Tragic.

So, yeah, that's the bad news.
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: support@cryptostorm.is
live chat support: #cryptostorm

User avatar

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

more security theatre...

Postby cryptostorm_team » Fri Oct 25, 2013 4:38 am

Posted in reply to yet another Torrentfreak hypeware "our advertisers get to lie to our readers, and we're happy to play along" article:

These are the "security experts" TorrentFreak found to discuss encryption? Wow. Torguard states "“It is also important to point out that there is no known method that even comes close to breaking 128bit Blowfish encryption."

Orly?

Schneier recommends using Twofish instead... back in 2008 (he wrote Blowfish, so he might be a good person to consult - https://www.schneier.com/paper-blowfish-fse.html):

https://www.computerworld.com.au/articl ... hful/?pp=3

(Blowfish is more or less fine, but the risk of weak key selection and resulting drastically reduced difficulty in mounting a successful chosen-plaintext attack - quite relevant in the context of a "VPN service," lest we forget - encourages anyone with competent cryptographic expertise to use newer algorithms not subject to this historical flaw. As Schneier himself recommends.)

Not that it matters, given Torguard's aggressively cooperative stance with respect to cops and "informal" disclosures of "private" customer data on request. To their credit, they don't try to hide this - it's right in their own ToS and Privacy Policy language:
viewtopic.php?f=17&t=2378

As to PIA, well their slippery understanding of basic cryptographic concepts is sort of legendary:
viewtopic.php?f=17&t=3545

Of course, all of these "VPN services" are deploying OpenVPN naively with server-generated "private" client keys sent plaintext to their customers. So the cipher suites chosen - which all rely on that "private" client key to initiate secure sessions - are pretty much irrelevant. It's broken from the handshake forward.

Oh well..

This is great for the NSA, because the hypeware misinformation encourages people to trust these "VPN services" and say/do things they shouldn't. It all goes into the Bluffdale repository, for use when needed in the future. Not so good for people who pay actual money for "security" to these lucrative little companies. Not so good, at all.

None of this is difficult to understand, identify, or document. Indeed, one might think journalists would be interested in doing so. Given advertising policies, alas, one would be wrong.

Yah, and just sending OpenVPN traffic over :443 is hardly stealth, ffs. Bluecoat can protocol-print OpenVPN from the headers - no DPI - and has been able to do so for many years. They aren't the only ones. Narus, naturally, has the ability for a long time. It's possible to protocol obfuscate (we're working on a Dust implementation, for example)... but not one of these "privacy" services can be bothered to care - why should they, when they can spout nonsense publicly and see their words published as if they were credible?

For folks interested in the mere appearance of "security," these crypto disasters might serve a useful purpose... perhaps. But for people who actually need to know their stuff isn't leaking left and right, these are no better nowadays than back in 2009 when iPredator was blathering on about how "strong" PPTP was. Lol.

Some things don't change...
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: support@cryptostorm.is
live chat support: #cryptostorm


Return to “general chat, suggestions, industry news”

Who is online

Users browsing this forum: No registered users and 19 guests

Login