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

HideMyAss & L2TP & MS-CHAP1/2 (sub-post)

Encouraging best practices in the VPN industry via independent, community-certified verification of clean installers and clean basic service operations. Let's reward the good, and make the bad a little bit less tempting 〰 github repo#cleanVPN
User avatar

Topic Author
Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

HideMyAss & L2TP & MS-CHAP1/2 (sub-post)

Postby Pattern_Juggled » Sat Mar 21, 2015 6:02 pm

{direct link cryptostorm.org/HMAl2p}
{this segment of a longer thread regarding our DA-auth framework is being released here, prior to the full thread's publication, as there's ongoing pre-publication editing taking place with the full thread that's run longer than expected & we felt this information is best shared earlier ~ admin}


Yesterday, I made use of the opportunity to lay out some of the ground-level work we as a team have been doing since last fall, via a post at our crypto.cricket blog. As I was "volunteered" for this duty by the rest of the team, I wrote long... as I tend to do. For some, that sort of writing is painfully boring to read. I concur, for the most part. However, our decision as a team was to allow my worst long-form impulses to assert themselves, in order to provide some framework for the real heart of the story.

The heart of the story is delivering network security - real, reliable, consistent, comprehensive network security - to our members. So, today, my job is to share that part of our work in as concise a form as I can. To make that possible, here's several citations of previous items published by our team, on topics related to this; those who want to know why we're doing what we're doing are encouraged to start with these. Those who prefer to 'cut to the chase' and see the plan as it turns tangible, can simply continue forth from here.


Yesterday, in Part 1 of this piece, I laid out a series of flexibly-connected, global-scale, complex, systems-level threats that, when seen in full perspective, constitute an ontological thread to the security of cryptostorm's network and its members. Actually, I left quite a few pieces out - hardware-based attacks, client-side rootkits, side-channel weakness ubiquity, and so on - as the laundry list can start to seem overwhelming in full roar. But I hope the point has been made: big issues are relevant and require attention.

Today, we're tactical. And a tactical example helps set the stage for what can go really wrong in the "think local" side of things. This little vignette begins with an exchange that took place recently on twitter:

HMAoops.png


We at cryptostorm - and I personally - aren't interested in overstating this issue, but there's no nicer way to say this than: this is what happens when bad crypto meets low external review. I promised to stay short with this reply, and despite the temptation to veer astray, I'll stick it out. Besides. Moxie's essay on this topic is, in a word, brilliant - there's nothing I can say that'd improve on his explanation and it's best I just point those curious for the deeper details over there.

As HMA says in their reply to our criticism:
"The PSK is for authentication, not encryption or decryption. It's used as an alternative to certificates."


it sounds reasonable to say that the "pre-shared-key" is only for authentication, not for actual encryption... and in that case, if we don't care about that weirdly abstract authentication nonsense, we can just cut to the chase and do the encrypting that counts. And actually, it is possible to do that... but only if you basically do authentication but call it something else - same difference. Or, of course, you can use pre-shared-keys... which must remain private and secure to be of any use.

In this case, HideMyAss is doing neither. They've published their PSK on the internet, so anyone can find it. It's so low-entropy in any case that a ten year old could guess it in a few minutes. That means, for the specific underlying protocol on which they have based this "encryption" service, MS-Chap is what's available (2... as well as 1, the latter being beyond broken and into satire):

HMA-MSchap.png


Long story short, these network sessions are functionally plaintext for anyone who goes to the trouble of gathering them up - or storing them for later review. And while it seems like authentication can be carved off from crypto, in reality that's not how things work.

Incidentally, if there's any question regarding the decrypt we'd gladly receive captured traffic on a session or two, and we'll turn around plaintext from them. This is not a challenge, given that Moxie did automate the entire process (much of that automation exists to figure out the PSK or equivalent passphrase - which isn't needed here, since it's published). This really is as simple a case of useless crypto as can be imagined. Or as Moxie put it a few years ago...

"In many cases, larger enterprises have opted to use IPSEC-PSK over PPTP. While PPTP is now clearly broken, IPSEC-PSK is arguably worse than PPTP ever was for a dictionary-based attack vector. PPTP at least requires an attacker to obtain an active network capture in order to employ an offline dictionary attack, while IPSEC-PSK VPNs in aggressive mode will actually hand out hashes to any connecting attacker."


tl;dr - authentication matters

☯ ☯ ☯

Which is something of a problem, because authentication for effectively all network cryptography in the civilian world is structurally crippled. That's the bad news.

The good news is that the underlying mathematics - the cryptographic primitives - underlying real auth models that work across untrusted network pathways work just fine. I'd say they're genuine marvels, these asymmetric key exchange algorithms - close on to magic. The failure (intentional or not) lies in the way it's put into practice, out in the world.

Out in the world, authentication hinges on chains of trust - only, these chains aren't trust like most of us would use the term. Instead, they're rigidly hierarchical - anyone at "root" trust level can vouch for anyone else in the entire system, including themselves. This is a parody of rigid hierarchy, and unsurprisingly it shows all the failures such rigid models are known to produce.

In practical terms, when you decide you want to create a secure communications channel with a particular news website, for example, the way you know the website you're visiting is really the website you want to visit is that you are implicitly trusting the entire, broken, dysfunctional edifice of Certification Authority-based session verification to make sure you're pointed right. Further, the same question of knowing who you're connecting to is at the root of protecting against Man-in-The-Middle attacks - so that's a fail, as well.

There's a whole giant edifice that's grown up around this admittedly broken way of making sure our network traffic is secure. And there's enormous effort expended by smart, talented, motivated folks to fix the CA system so we can make the internet secure again. It's all a hopeless waste, and worse it's all completely unnecessary.

Cryptostorm has found a path out of this mess doesn't require "fixing" an un-fixable mess. Nor does it envision throwing that entire system out and starting, tabula rasa with some idealised new system of perfection, whole-cloth. Instead, we've gone through the convoluted inner workings of the existing CA model, highlighted the bits that actually do a decent job of their tasks, pushed aside the unnecessary complexity and baroque filigree of silly absurdity, stayed firmly based on proven cryptographic primitives, and sought out iterative steps to deploy instead of big-bang, all-at-once pipe dreams.

We call it Decentralised Attestation. And it works.

We'll show you, right now.

☯ ☯ ☯

{continued in full post, upon completion of edit process this weekend ~admin}
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

Return to “#cleanVPN ∴ encouraging transparency & clean code in network privacy service”

Who is online

Users browsing this forum: No registered users and 1 guest

cron

Login