{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.
- superfish & 'ssl kneecapping' - a summary of misadventure, and distilling what it means for cryptostorm
deepDNS.dk: our mesh-based system of recursive, blockchain-mapped, dnschain-enabled Domain Name System resolvers
Cthulu & the dark side of DNS - enumerating DNS mysteries, and what they mean for network security service overall
cleanVPN.org - searching for reliably 'clean' (opensource, no malware, no fakeware clients) VPN service providers, via community review
DNS hijacking, in the wild - an unexpectedly close to home demonstration of core weakness in DNS integrity
In search of curve 25519 - hardening torstorm.org via precise cryptographic parameter selection & deployment
browser privacy & fingerprinting 101 - the risks your browser poses to online security, & how to mitigate them
STUNnion - a demonstration of IP address exposure during Tor .onion site visits, via webRTC calls
webRTC leakblocks and cryptostorm - tactical notes from the front lines of a harbinger of problems to come
Decentralised Attestation - DA & the #CAfree future of network crypto
Hostname Assignment Framework - redundant, resilient, decentralised network resource administration
network access tokens - cryptostorm's approach to privacy-enabled secure network auth
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:
As HMA says in their reply to our criticism:
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."The PSK is for authentication, not encryption or decryption. It's used as an alternative to certificates."
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):
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...
tl;dr - authentication matters"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."
☯ ☯ ☯
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}
