
Namecoin, A Replacement For SSL - mediocregopher
http://blog.mediocregopher.com/namecoind-ssl.html
======
tptacek
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](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.

~~~
mediocregopher
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"

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

~~~
schoen
Maybe, but it could nonetheless help with the first-visit problem.

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/decentralised-currencies.pdf)
[http://www.links.org/files/distributed-
currency.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.)

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

~~~
mediocregopher
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](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.

~~~
graue
Cryptocat was and is open source too:

[https://github.com/cryptocat/cryptocat](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/](http://www.matasano.com/articles/javascript-cryptography/)

~~~
mediocregopher
When you create an account with cryptic.io, a private key is generated in
browser and encrypted with the hash of your password. This encrypted private
key is what we keep server-side. All files you upload, and all of your user-
data, is encrypted using that private key. In short, all encrypting/decrypting
of ANY sort happens inside your browser. So someone logging onto the server
and viewing data as it is uploaded is still seeing encrypted data. Short of
compromising a user's computer there is no way for them to see it. Our
encryption scheme is nothing like the scheme that lavabit used.

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

~~~
teod
I have thought about a similar service but was dissuaded by various sources
warning against the idea of using javascript with cryptography, e.g.
[http://www.matasano.com/articles/javascript-
cryptography/](http://www.matasano.com/articles/javascript-cryptography/).
That's not to say a reasonable solution cannot be found, but there are a good
number of issues that need to be addressed. The one that seems crippling to me
is that the strength of javascript crypto libraries is questionable at best -
nevermind the various other javscript attack vectors. A browser plugin could
address some issues, but then that limits users to browsers with the plugin
installed. Might as well have a native application where the quality of the
cryptographic algorithms are more thoroughly tested at that point. Still, I
like the idea and wish you the best of luck.

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

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

------
stormbrew
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?

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

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

------
nwh
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
Eh, they think it's fixed now.

The squatting is awful, though.

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

~~~
mediocregopher
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
[http://www.startssl.com/](http://www.startssl.com/)

~~~
serge2k
is that actually accepted by browsers now?

IIRC they used to have a ridiculously awful method for revoking a cert. Is
that still the case?

~~~
hsivonen
StartSSL's certs are accepted by browsers and revoking a free cert costs
$24.90.

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

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

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

~~~
tptacek
DNSCurve is fine, but we can also just continue assuming the DNS is insecure
and pushing security out to the endpoints, where the End To End Argument says
it belongs anyways.

~~~
pedrocr
So, how do I connect securely to a new website if I can't trust the DNS
response?

~~~
tptacek
TLS.

~~~
pedrocr
You seem to have a clear idea of how TLS+TACK solves this issue but you're not
articulating it, just giving laconic answers. As far as I can tell TACK
doesn't solve the first connection problem:

"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/](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](http://mail.mydomain.com) anyone that controls
the DNS has you and if you connect to
[https://mail.mydomain.com](https://mail.mydomain.com) it's anyone that
controls a rogue CA. This is exactly the same situation of TLS without TACK,
no?

~~~
tptacek
TLS+TACK _doesn 't_ solve the first connection problem if you stipulate a
corrupted CA PKI. But the difference between the CA PKI and the DNSSEC PKI is
that you have to _stipulate_ that the CAs are corrupt; the DNSSEC PKI is
corrupt _by design_.

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.

~~~
pedrocr
>TLS+TACK doesn't solve the first connection problem if you stipulate a
corrupted CA PKI.

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.

~~~
tptacek
The USG owns the DNS roots. Or did you not notice the pirate sites with their
logos replaced by the DOJ seal? They don't have to "corrupt" the DNS; it's
already theirs to control.

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.

~~~
pedrocr
You're postulating that the DNS is compromised. So you've already given up on
the first connection and are relying on pinning only to raise red flags if
someone does too broad an attack. With DNSSEC CAs only the .COM CA (USG
compromised you say) gets to try to MITM. With the current system all CAs
(compromised by USG and others I say) get to try to MITM. Pinning+DNSSEC seems
strictly better than Pinning+ExistingCAs.

~~~
tptacek
I am again baffled. If a CA issues a rogue certificate and, as is likely, is
rapidly caught because 10 million people have an already-loaded pin for the
real certificate, Google can nuke the CA from orbit. Google cannot nuke .COM.

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.

~~~
pedrocr
Ok, now we're getting somewhere. Our proposed end-states for security are
different:

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.

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

~~~
devhinton
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

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

~~~
yeukhon
$200 certificate for a personal website? That's not necessary. What we need is
to stop charging a SSL/TLS certificate so much to get the recommended level of
cipher used.

------
runn1ng
I think there were some problems with namecoin.

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

