Namecoin, A Replacement For SSL
blog.mediocregopher.com
blog.mediocregopher.com
The TLS standard itself is almost agnostic to how certificates are validated, and there is more than one strategy for doing so. For instance, Chromium doesn't trust the entire TLS CA system; it bakes into the browser "pinned" certificates, and not only won't honor a Google Mail cert from Komodo or China or Trustwave, but will also alert the (large, enthusiastic) security team at Google that a CA issued a rogue certificate.
There's no reason the same system couldn't work for your site too; key pinning just needs to be made dynamic. And there's a standard for that: Moxie Marlinspike and Trevor Perrin's TACK, at http://tack.io. If you want to "fix" TLS, don't throw out the baby with the bathwater: you are vanishingly unlikely to do a better job of designing an encrypted channel than every cryptographer and protocol designer and software security person who has poured time into TLS. Instead, update the browser UX, which is the only thing leaving us hostages to the CA system.
This is only the case if you mean the browser UX as it relates to site owners and not site users. For users the only browser UX they should need to know about is the browser being able to tell them with confidence "this communication is [not] secure".
So why go through all this hackery to patch up the broken CA system vs just distributing the TLS keys through DNSSEC? That way you get a complete chain of trust all the way to the DNS root, validating both HTTP and the initial DNS response. Then you can really tell the user that the communication is tamper-proof without any gotchas about rogue CAs and certificate pinning.
The good news about DNSSEC is that it's never going to happen anyways.
Meanwhile, TACK strikes a balance between the convenience/stability of having a third-party trust anchor that can vouch for your identity, while at the same time putting site owners in control of how strong that voucher is, by allowing them to bind their identity directly with clients. You could in theory pin a self-signed certificate, if that was your thing.
We rely on DNS anyway so what can those world governments do with a DNSSEC PKI that they can't do with DNS as is? I mean if you can change the DNSSEC distributed certificate for google.com surely you can just redirect google.com and be done with it.
If the user is using a new browser or has an expired HSTS header, wouldn't it actually be trivial to do? Or are you also relying on TACK to say "never connect to mail.google.com without TLS" or on HTTP/2.0 to mandate TLS everywhere?
So, my assertion is correct then. Own DNS, own mail.google.com if the browser doesn't force TLS.
If we're doing that why do we need CA's at all? Just ship pins of self-signed certificates to all the browsers and trust Google with the integrity of the database.
Also, that way you could limit your trust to one entity per tld. Unlike today where any CA anywhere in the world can sign any certificate.
Yes, world governments can yank GOOGLE.COM so you can't reach it at all. But what they can't easily do is stand up a different MAIL.GOOGLE.COM and reliably collect people's mail.
However, if were were stupid enough to stick TLS certificates into the DNS...
So while TLS itself doesn't trust DNS at all, PKIX does! CAs may well have google.com on a blacklist, but if someone could "yank" matasano.com and point it at their own server, they could most likely get GoDaddy to issue them a cert based solely on their control over that server. GoDaddy's existing test for the legitimacy of a certificate issuance request is the ability to post a text file with specified contents on an HTTP server pointed to by the subject CN.
(For that matter, the attacker who took control of the matasano.com zone could then publish MX records allowing them to intercept any verification or confirmation e-mails to the whois contacts.)
Without pinning, keys in authenticated DNS (like with DANE) are strictly better than CA certificates, because the CA certificates are themselves issued on the basis of (even unauthenticated!) DNS data.
My understanding of pinning is that it could just as well be used in a namecoin based system, and could enhance the security of that scheme just as it does with the CA scheme. All of these ideas could work together, with namecoin as the external, third-party source of trust instead of the CAs.
So I guess a better title for the post would have been: "Namecoin, A Replacement For Certificate Authorities"
There are at least three proposals with a distributed cryptographic ledger to reform or replace the CA system: Namecoin, Sovereign Keys, and Certificate Transparency. Each of them has some security benefit relative to TACK alone in the case of a user-agent's first visit to a site.
In SK and CT the ledger is less distributed than a Bitcoin blockchain, although these systems have historical influence from discussions sparked by the existence of Bitcoin. Ben Laurie argues that proof of work is actually superfluous to the security model of these systems:
http://www.links.org/files/decentralised-currencies.pdf http://www.links.org/files/distributed-currency.pdf
Anyway, to refocus, a decentralized or distributed ledger does have the potential to help with the first-visit introduction problem, because you can have another place to turn for ground truth or at least for evidence that the certs you accept are publicly known. (There are also alternative techniques that don't rely on such a ledger, including Moxie's own Convergence.)
I'm ready right now to try either TACK or crypt.io. What should I do if I want results over the next 24 hours?
Also, and I mean this for both TACK and crypt.io, is there a self-contained, easy example someone can run and understand that shows if TACK and crypt.io work?
Alternately you could use arbitrary key signing which the original site presented up along with their cert.
It certainly seems preferable to the single-point-of-failure systems we have now.
I find your wording a bit strange here. Saying that you proposed the idea and yet half-acknowledging prior work, as if you're not aware of it.
You and Marco were at my senior project presentation where I talked this very issue (several weeks ago). Half of your blog post came out of my talk. Happy to see you were able to figure out the last slide was partly referring to Namecoin.[1]
This idea has also been discussed for some time on the Namecoin forums, and various security mailing lists and websites.
I'm glad more people are exploring this option. It would be nice if they were a bit more polite.
[1] http://cl.ly/image/153W3X3Q140y/Screen%20Shot%202013-11-23%2...
However, TACK only protects you after you've visited a site for the first time. If a person is targeted by any organization that can sign a fraudulent certificate before the first time they visit a site, then they are still vulnerable to MITM. Given that many countries have root CAs, many governments have this capability.
Namecoin does not suffer from that issue.
Namecoin and TACK solve different problems. One is an incremental improvement with backward capability; the other is a clean break that attempts to provide stronger guarantees.
"you are vanishingly unlikely to do a better job of designing an encrypted channel than every cryptographer and protocol designer and software security person who has poured time into TLS"
It pains me to see this kind of arrogant dismissal as the top comment so often.
The author said nothing about designing his own protocol. He simply explained the problems with the CA system and the way Namecoin (specifically the DotBIT proposal) might solve those problems. This would simply add new functionality: supporting .bit URLS where the clients looks up the certificate through the blockchain, without trusting the CAs. After that first step, the encrypted channel implementation can be the same. And the blockchain concept (and even Namecoin's specific implementation) is shared with Bitcoin, which has been battle-tested quite thoroughly at this point.
The idea that only members of the CABForum can run CAs is silly, especially when (a) many of those organizations are in fact beholden to governments and (b) some of them have actually sold root CA certs.
There is no technical reason the ACLU should not be able to run run its own trust store, certifying alternate CAs that it is confident aren't corrupted, and revoking CAs when certificate pin errors make it clear that they have been. The UI to make that happen is very simple as well.
My issue with things like distributed ledger verification is that TLS's problem isn't the crypto. The crypto should be kept boring; we're barely holding the crypto together as it stands.
The problem with the TLS security model is browser UX. We can and should leave the protocol alone.
Nobody, not in the article and not in the post you replied to, sad that the protocol needs to be replaced. In fact, both say the exact opposite.
I like your posts, and you clearly know what you are talking about, but this time it seems you don't discuss the article, but just hop in the discussion with random and not correlated, but true facts.
Well then, TACK changes "the protocol". As you know better than me it proposes changes to the TLS handshake and how CAs are verified.
If that's the case, then we may just have to dump TLS eventually anyway, since it was made as a patchwork to cover a very insecure Internet. We need an Internet where security is mandatory (in a cheap way, if possible), not just "optional".
With names we can at least claim them, remember historical claims about them, or prove that we apparently control them according to some naming system. With IP addresses we have deliberate churn in control so you might use a different address every week (and someone else might re-use your old address). What is a safe way to associate keys with IP addresses, given this?
I do wish that plan had worked out. On the other hand,given evidence that governments are sabotaging so much of our communications infrastructure, I guess I fear that active MITM will become common quickly unless there's some mechanism in place to at least detect, publicize, and investigate it.
And since a given IP address can be legitimately used by many different devices, human beings, or organizations in a short timeframe, it's hard to see what this would look like.
Maybe if we could go back in time, we could add a new field to the Internet Protocol that indicates a unique endpoint ID for IPsec purposes. Two hosts desiring to communicate would exchange endpoint IDs, and an encryption "session" would only apply to the IP+endpoint combination. That way it's still possible to implement UDP and TCP on top of IP, but it doesn't necessarily solve the case when different TCP or UDP ports on a single IP address correspond to a different machine and the port-based router should not be able to decrypt the traffic.
Given the overwhelming, repeated breakages in the SSL/TLS record protocol I'm really surprised you put the designers of it on such a high pedestal.
The researchers who broke SSL/TLS should certainly get that kudos, but the result of this is that a competent designer should be able to do a better job than TLS now if they merely choose to fully research the problem domain.
Which the current system already does. How would you upgrade the UX without exposing the complexities of security to the user?
Also, why isn't there room for two authentication systems? The internet was built around redundancy. Secure systems could utilise both when they want to absolutely sure.
On the one hand we have the experience of about 20 years of the web, >15 years of heavy internet usage, and so on. We've learned the various shortcomings of the systems that were originally put in place, and we've learned a lot of advanced techniques and technologies that can be brought to bear to build next generation versions of those systems.
On the other hand we are burdened with 20 years of backwards compatibility concerns and network effect, making replacement systems hard to deploy and gain traction. IPv6 perhaps being the poster child in that regard.
This concept may sound clever at first but gives you as the user no additional confidence compared to encrypting data on the server side upon arrival. Either way, you're trusting the host.
The threat model for server-side encryption is essentially:
1) the host has an unethical employee who wants to read your content.
2) the host's servers are insecure and get compromised.
3) someone successfully MITMs your connection to the host (possibly due to the SSL problems being discussed here).
4) the government compels the host to provide your data (i.e. what happened with Lavabit).
The threat model for browser-based client-side encryption is the same! In any of these cases, the attacker (or the host, in case of #1 or #4) simply sends JavaScript encryption code to your browser with a backdoor in it.
Cryptocat originally worked the same way: all chats were encrypted on the client side, but with JS code sent from the server, in which a backdoor could be inserted at any time. After much criticism, this is why Cryptocat is now a browser add-on, with discrete releases made available from a central source (Chrome Store/Mozilla addons site), which can be audited.
https://github.com/cryptic-io/web
We'll be releasing tools, like a browser-extension, that will help confirm that the code you've received on the site is the same as that in the repository.
And since the whole frontend is open-source and is only html/js/css, you can host it on your own box if necessary.
To address your points 1 and 4: Since all data is encrypted BEFORE leaving your browser (this was NOT the case with lavabit) even if our servers were compromised your data would still be secure.
https://github.com/cryptocat/cryptocat
That doesn't solve the problem. No one is going to manually view source and compare it every time they use the damn thing.
> To address your points 1 and 4: Since all data is encrypted BEFORE leaving your browser (this was NOT the case with lavabit) even if our servers were compromised your data would still be secure.
At rest. Yes, at rest it's fine, like I said, but if someone logs in while the server is compromised, it would be trivial to decrypt anything they post or access during that session. Same as Lavabit.
> We'll be releasing [..] a browser-extension, that will help confirm that the code you've received on the site is the same as that in the repository.
So it'll download two copies of the code, one from your servers and one from GitHub, and check that they match? Doesn't seem to me that that buys you much. And unless it's mandatory, you'll be leaving the users that don't install the extension unprotected.
See here for a long list of other reasons in-browser crypto is problematic: http://www.matasano.com/articles/javascript-cryptography/
The extension won't be able to mitigate an attack, but it will be able to alert you to one, which for someone who had the initiative to install it (which we will be heavily encouraging users to do) would be enough to inform them that something is amiss. And if something is amiss they can host the front-end themselves and use a local copy of the html/js/css so they can be sure they're getting a good copy of the site (something we will also be making easy to do).
You seem to suggest storing their hashed password in the browser, but if they change machines they won't have that hashed password around. How will you go from plaintext password to hashed password without having the salt used with PBKDF2?
You say user passwords are never sent over the wire (not even the hash)[1], but then say users have an object containing their hashed password (is the documentation here out of date?)
I wish you had an example of a custom application that uses your storage, so people can see how easy/hard it is to use and customize the frontend for their own applications. How would the browser plugin properly attest the frontend code hasn't been modified if an application dynamically generates custom frontend code per user?
Think of PGP, adding a new key toyour browser, creating a certificate, adding an exception... Always unintuitive CLI.
In terms of UI, I still don't get why for firefox a clear text password other an unencrypted connexion is not worse than a self signed certificate (it should be identically considered dangerous).
The only crypto UI I can use is ssh.
You're trying to explain how SSL is secure, that everyone implicitly trusts the root certificates and then there's this. I immediately lost complete interest in your explanation (because you probably don't understand it yourself) and hence in whatever product and/or solution you're trying to offer.
EDITED: Also, unless I'm wrong equivalently comparably small errors in code are what allows for security loop holes cough cough original buffer overflow.
The squatting is awful, though.
IIRC they used to have a ridiculously awful method for revoking a cert. Is that still the case?
I mean... your cost argument is weak, almost meaningless. Just focus on the trust angle, it's a reason enough against PKI/SSL.
Here we go again... Let me guess, these guys also figured out a way to disable the context menu from popping up to prevent you from copying anything from their page.
The rest of the article is pretty interesting.
Edit after finishing the last bits of the article: So why is this better than something like MonkeySphere or DNSSEC? Both already let you distribute your public key and don't require anything experimental.
This isn't at all comparable to disabling the context menu. Anything that runs client-side and is in opposition to the user is screwed as the user can get around it.
An attacker in this case would not have access to the client, an attacker in this case would be a MITM and would therefore not be able to mess with the encryption code (unless the encryption code itself is sent insecurely).
"The big drawback of the TACK mechanism is that, like other client-side key-pinning methods, it does not protect the user against a man-in-the-middle (MITM) attack during the very first connection attempt to the remote server."
https://lwn.net/Articles/499134/
So as far as I can tell even in a TLS+TACK world if your initial connection is to http://mail.mydomain.com anyone that controls the DNS has you and if you connect to https://mail.mydomain.com it's anyone that controls a rogue CA. This is exactly the same situation of TLS without TACK, no?
Meanwhile: the CAs are financially disincentivized from going rogue, because Mozilla and Google will remove them from the trust store if they do stupid things.
What dynamic pinning plus CAs buys you, on top of key continuity that corrupted CAs can't break, is surveillance: an entity that can get bogus certificates issued can't assume they can do it undetected, because those certs will almost immediately break on someone's pin.
Don't you think it's a reasonable assumption that the NSA controls at least one CA?
>the DNSSEC PKI is corrupt by design.
That's interesting, have any pointers as to why? With the current model any CA can vouch for any site (hence the need for pinning), with DNSSEC only the CA that controls .COM can issue fake certificates for EXAMPLE.COM. I don't understand how that doesn't make the potential attacks strictly less.
>What dynamic pinning plus CAs buys you, on top of key continuity that corrupted CAs can't break, is surveillance: an entity that can get bogus certificates issued can't assume they can do it undetected, because those certs will almost immediately break on someone's pin.
Right, and that's fine for mass attacks (which is important) and less than stellar for anything that's targeted. Plus there's nothing stopping you from implementing pinning+DNSSEC CA's, so that if the .COM CA starts issuing fake GOOGLE.COM certificates you catch him. At the same time RandomCAFromAntartica doesn't even get to try.
We can stop arguing about DNSSEC though, because it is never going to happen. It's a stability disaster, an enormous administrative pain to manage, cryptographically weak, and requires domains to publish all their hostnames (private or not); see NSEC3 for the ludicrous hack the working group came up with to (badly) mitigate that problem.
How could a government-run PKI possibly be better than a network of crappy private companies? At least the companies have to respond to incentives.
You: TLS connections have a high likelyhood of being secure but they will be MITM'd by some CAs some of the time. We put mechanisms in place (pinning of individual certificates) to in the long run detect most of those attempts are disable those CAs.
Me: TLS connections are known to be secure to the people in the trust chain. (I trust my registrar, who trusts .COM, who trusts the root). No other parties can breach that trust. We put mechanisms in place (pinning at all levels) to detect misplaced trust (the USG creating a new certificate for .COM) and make a fuss when that happens.
If you have enough trust in the democratic process being able to control the chain of trust you'd go for my solution, if not you'd go for yours. It sucks that we live in a world where that choice isn't clear.
> [the browser code] can also be verified against an open source repo with a browser extension
[1]: http://www.kickstarter.com/projects/cryptic-io/cryptic-encry...
I am making a US-based comparison since you used the word "federal."
Compared to the ~$15 a year a .com domain costs, paying 10x that amount for an SSL certificate seems a bit on the high side.
[1] - http://www.startssl.com/
Mainly that nobody is currently developing it and fixing its bugs.