Namecoin, A Replacement For SSL

http://blog.mediocregopher.com/namecoind-ssl.html

by mediocregopher • 13 years ago

159 93 13 years ago

blog.mediocregopher.com

At cryptic.io we are creating a client-side, in-browser encryption system

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.

jstanley• 13 years ago

I haven't read the article, but...

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).

tptacek19• 13 years ago

For whatever it's worth, DNSSEC is a disaster too.

pedrocr13• 13 years ago

Why is that? What should we use instead? DNSCurve?

timmclean• 13 years ago

From their Kickstarter page[1]:

[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...

aferreira• 13 years ago

These root certificates are managed by a small number of companies designated by some agency who decides on these things

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.

devhinton3• 13 years ago

Second paragraph, "One", not "On". Not trying to be a jerk but that is a bit sloppy :)

EDITED: Also, unless I'm wrong equivalently comparably small errors in code are what allows for security loop holes cough cough original buffer overflow.

tptacek19• 13 years ago

The problems this author lists with SSL/TLS are not in fact problems with SSL/TLS, but rather with the browser vendors.

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.

pedrocr13• 13 years ago

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.

tptacek19• 13 years ago

DNSSEC is just another PKI, but this time controlled by world governments. I'm baffled by how anyone could think that DNSSEC is a superior alternative to the CA system.

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.

mediocregopher5• 13 years ago

The idea I've proposed (although I'm sure I'm not the first to have done it) would leave most of TLS untouched. The only portion of the handshake and subsequent steps which would be different is that which verifies the server's certificate. Everything else would be the same.

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"

tptacek19• 13 years ago

Once we have dynamic pinning, we don't need an elaborate distributed cryptographic ledger to solve this problem.

itistoday2• 13 years ago

The idea I've proposed (although I'm sure I'm not the first to have done it)

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

dcposch• 13 years ago

TACK is a nice improvement to TLS that keeps compatibility with the existing CA system.

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.

tptacek19• 13 years ago

TACK is a baby step towards a design idea Marlinspike called "Convergence", and I just call "updating the 1995 browser trust store UI to the standards of 2005".

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.

_delirium• 13 years ago

Is there any movement on TACK recently? It seemed promising when it was proposed, for the reasons you mention, but I haven't seen any real movement towards implementing it by any of the major browser vendors. The IETF proposed draft also seems to have stalled: http://datatracker.ietf.org/doc/draft-perrin-tls-tack/. Do people have objections to it, or is it simply inertia keeping movement slow?

salient• 13 years ago

I do think "fixing" TLS is ultimately a pointless exercise that would only serve for the transitional period until we can build an Internet that's encrypted by default at the IP or Tranport layer.

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".

schoen5• 13 years ago

Right now, I'm not sure we know how to handle key management for universal encryption at the IP layer.

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?

ctz• 13 years ago

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

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.

ENGNR• 13 years ago

The browser UX should only show either of: Green - The channel is secure, Red - Security error

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.

InclinedPlane2• 13 years ago

It's seems like we're in an interesting position at the moment.

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.

scovetta• 13 years ago

If you're paying $200 for an SSL certificate, you're doing it wrong. But I don't think any of the points of the article change for cost > $0.

devhinton3• 13 years ago

Maybe I'm ignorant but $200 a year is not that much money. Considering a software engineer is usually paid 70k a year and you have four engineers you are looking at this being .071428571 % of total cost. So ummmmm maybe minimize your costs elsewhere :p

_mvuc• 13 years ago

Some of us live under the federal poverty level, where any sum of double digits or more is significant.

michaelt• 13 years ago

Obviously $200 is cheap compared to a skyscraper or a space station.

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.

glazskunrukitis• 13 years ago

Yeah, I had the same exact reaction. You can purchase SSL certificates really cheap nowadays, and even business ones costs under $100, e.g., here - https://getssl.me/en/ssl-certificates.

joeblau• 13 years ago

You can get Class 1 certificates for free[1].

[1] http://www.startssl.com/

nwh• 13 years ago

Nice idea, but the project is pretty much dread. All the domains are squatted and up until a month or two ago you could steal anyone's domain and make it your own, it took a public full disclosure to rouse the developers enough to get it fixed.

fragsworth• 13 years ago

Eh, they think it's fixed now.

The squatting is awful, though.

julie1• 13 years ago

Cryptography achileus heel is the UI.

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.

blahbl4hblahtoo• 13 years ago

You know, you're right. SSH has about the most sane crypto ui out of everything. That's a really sad state of affairs. I also agree with your point about self signed certificates...you it seems like sites should be able to identify you by that. It's probably easier to keep the certificate store on your machine safe than it is to actually follow the best practices that I've seen regarding password selection and usage.

graue2• 13 years ago

we are creating a client-side, in-browser encryption system where a user can upload their already encrypted content to our storage system and be 100% confident that their data can never be decrypted by anyone but them.

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.

mediocregopher5• 13 years ago

One of cryptic's features is that the front-end is completely open-source. You can see the source for the current prototype here:

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.

graue2• 13 years ago

Cryptocat was and is open source too:

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/

read3• 13 years ago

The browser extension is the missing link. That's what makes it impossible for malicious code in a frontend's source code to go unnoticed.

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?

eps2• 13 years ago

It's rather disingenious to say that an SSL cert is $200, when in reality a domain-verified cert goes for about $20. Hardly anyone interested in Namecoin would be needing EV certs.

mediocregopher5• 13 years ago

A wildcard cert, which you would likely want/need if you're running a business, does indeed go for about $200 (that's the minimum I've seen it, if you have a cheaper source it would make me very happy :))

mnkypete• 13 years ago

http://www.startssl.com/

eps2• 13 years ago

I would want wildcard cert if I have over 10 public facing domain names. And if I have that many, $200 is not an issue.

I mean... your cost argument is weak, almost meaningless. Just focus on the trust angle, it's a reason enough against PKI/SSL.

stormbrew• 13 years ago

This seems to propose that the namecoin block chain could be used as an alternative to root certificates, but without the client needing to participate in the block chain. But this means you have to trust a third party service (and your connection to it) to serve you correct information from the block chain. How exactly does that work?

mediocregopher5• 13 years ago

For that case you're right, the scheme suffers from the same concerns as the CA scheme. The difference is that there is room to move forward, in that you can host the namecoin chain yourself and be sure of its accuracy. I think we could even have browsers have it built-in that they host a copy of the chain (the whole chain doesn't have to be downloaded, nor does all that's been downloaded need to be in memory).

runn1ng• 13 years ago

I think there were some problems with namecoin.

Mainly that nobody is currently developing it and fixing its bugs.

Namecoin, A Replacement For SSL

Related Stories