
SSL And The Future Of Authenticity - gnosis
http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/
======
NickNameNick
I completely agree with moxie marlinspike but...

This article is two years old, and the effort behind the convergence project
(<http://convergence.io>) seems to have moved on to tack (<http://tack.io>)

~~~
pi18n
It's pretty clear and well-written, so I think its going to be worth reading
to explain why the system is wrong for as long as our system is a list of
permanently trusted CA's. There's no reason I should be trusting _all_ those
CA's to sign for _anything_ on the internet forever.

~~~
kijin
No CA is _permanently_ trusted. CA certificates expire like any other SSL
certificate, and most of the CA certificates that my browser trusts will
expire in about 10 years. In addition, browser vendors like Mozilla routinely
make decisions to add and delete CA certificates.

~~~
AnthonyMouse
I think _literally forever_ is an exaggeration (as it pretty much always is).
But the point is that you have to trust them for longer than you would like
to, because once they've signed the certificates for a huge chunk of the
internet, you can't take them back out without breaking a ton of stuff.
Meanwhile as long as they remain trusted they can keep signing new
certificates and making it that much harder to ever remove them.

The ones that get permanently removed are generally because they've already
gone out of business.

------
acabal
I've been wondering lately why SSL ties both _encryption between two parties_
and _the identies of those two parties_ together. A genuine question borne of
genuine ignorance on my part: why are these two concepts tied to the the same
protocol?

Why can't we have two separate systems? One to ensure two parties communicate
secretly with each other, and another to somehow verify the real-life
identities of those two parties? Why did those to seemingly separate concepts
evolve as one?

If we could separate them, it seems we could solve a lot of low-level security
problems online: sites could have cost-free, CA-free self-signed certs to
ensure _only_ that packets between the client and server are secure/private;
then separately, there could be a different system to ensure that the client
is _really, truly_ communicating with the Bank of Their Nation, Inc., and not
a scammer from Nigeria.

How did identity and privacy become conflated, and how can we separate those
to provide monetary-cost-free eavesdropping protection in the future?

~~~
kaoD
Because encryption's purpose is completely defeated if you don't know who you
are talking to.

A man in the middle could easily reproduce your data to the other party (and
viceversa) if you are not sure you are talking to the correct party.

How could you be sure you're doing

    
    
      A -(encrypted)-> B
    

and not

    
    
      A -(encrypted)-> MITM -(encrypted)-> B
    

?

You can't, so you'd better ditch the encryption and just talk plaintext.

Encryption relies on the fact that you have a signature from B who says "hey,
I'm REALLY B, you're talking to me directly, here's my public key so you can
talk only to me and nobody else can read the data inbetween".

That's where CAs come into play: they're the authorities that certify that B's
signature/public key is actually tied to the domain you think you're talking
to.

> CA-free self-signed certs to ensure only that packets between the client and
> server are secure/private

What's the difference of a self-signed certificate from www.gmail.com and a
self-signed certificate from RandomHacker who says he's www.gmail.com ?

They look the same.

So... both concepts are actually separate already (e.g. did you ever trust a
certificate manually in your browser?), but it's pretty pointless when you
ignore CAs and therefore don't know if the certificate is real or crafted.

~~~
acabal
So forgive my denseness here, but that can still be broken down into two
separate protocols, right? 1) I wish to communicate with foo.com privately,
regardless of whether foo.com is _really_ who foo.com claims to be; that is,
one time foo.com might be 192.168.0.0, and the next time it might be
192.168.0.1; but either way, regardless of who I'm _truly_ communicating with,
I can _at least_ be sure that nobody but the recipient can decode the packets.
Then, 2) I can guarantee everything in (1), plus that my the packets I
exchange with foo.com are _truly_ the foo.com that resides at 123 Main St.,
USA.

An analogy might be: 1) I seal a letter in an envelope, and the postal service
guarantees that it will arrive at the address I specify, regardless of the
human that opens the letter at that address; and 2) I seal a letter in an
envelope, and the postal service guarantees that not only will the letter
arrive at the address I specify, but that it will only be opened by the human
I specify, who is identified by his postal-service-issued ID number.

~~~
kaoD
It's already separate (check the bottom part of my parent comment).

When you accept an unknown certificate, you're communicating with whoever is
on the other side regardless of their identity.

You have to settle the identity of the other side at least once when you
stablish communication[1]. Actually, you're not settling the identity, just a
public key with which you encrypt the communication (which in turn is settling
the identity as a desirable side-effect). You still need their public key
because, well, that's how encryption works: you send a message encrypted with
a certain public key, which can only be decrypted with the corresponding
private key.

Fortunately, web browsers alert you not to do this because it's pointless. You
see both encryption and authentication as a single step because web browsers
abstract the process for you. Otherwise, why am I encrypting the connection in
the first place? If someone's listening and you're not checking certificates,
sending plaintext or encrypted is actually the same thing and offer ZERO
encryption. I'd be able to read anything you say without effort.

[1]
[http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exch...](http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange)

------
kijin
> _total ripoff and also insecure_

I pay less for SSL certificates per year than I do for the domains I use them
on. You can get a free certificate from StartSSL if you're just playing, or an
$8 certificate from Comodo if you're more serious. Some registrars (cough
Gandi cough) even include a free SSL certificate with every domain.

So the "total ripoff" thing has been all but solved by market competition
(unless you prefer to splurge on a $800 certificate that doesn't do anything a
$8 certificate can't do). It's really just the "insecure" part that needs to
be addressed.

~~~
pzb
In what way is a StartSSL certificate any different from a Comodo certificate?
What makes StartSSL only usable for "playing"?

~~~
kijin
StartSSL is recognized by OS X 10.5 or later, and Windows 7 or later. Older
OSes might not recognize it if the user has missed any updates.

I'm OK with showing IE6/7 users a polite suggestion to upgrade, but a
certificate error looks unprofessional. In addition, Chrome on XP is also
affected (if the user has missed the CA update) because Chrome doesn't carry
its own list of trusted CAs.

~~~
caf
If someone's browsing the internet with unpatched XP then they've got bigger
problems than some certificate warnings appearing.

~~~
kijin
That's their problem, not yours. Remember, we're talking about Chrome here,
not IE6/7.

------
anologwintermut
Trust authority only works if users are willing to actually make trust
decisions. Since they are not, whatever trust authorities chrome, firefox, and
IE ship with will end up being a default single point of failure, target for
compromise, and point of corruption.

Pinning certificates or using something like Namecoin to maintain a key to
human identifier mapping seems like a better idea.

------
wyager
Seems to me like Namecoin is a practical, secure method of distributed
identification and verification. It's basically a secure P2P key:value store
based off of Bitcoin's method of operation. Its original intent was to replace
DNS (the website name is the key, the IP address is the value), but I see no
reason why we couldn't also use it to host public keys.

~~~
twoodfin
How does it stop me from saying "Bank of America's public key is <my public
key>"?

~~~
Dylan16807
Nothing. The same way you can go buy iamthebankofamerica.com for a couple
bucks and put all the keys you like on it. But once you go to the _actual_
Bank of America domain record you'll get back the real certificates.

------
teeja
A great time to raise these questions. What reason have we ever had to trust
any of these "authorities" (let alone the deteriorating state of the field,
e.g. the recent Turkish fiasco)? Without a firm answer for that question, SSL
is reduced to magic thinking.

~~~
ashkav
I'm no expert at cryptography and all that stuff, but i find the model of the
httpsy link quite interesting. You include the identity of the site you're
linking to in an extended httpsy address, so that you can be sure that you
land on the site you linked to.

The beauty of the Idea is that it democratizes the trust domain. It creates a
web where ordinary people decide whom they trust simply by putting down
httpsy-Links.

------
7952
Require people to submit a public key and two factor serial number during
domain purchase, then use that key to sign individual server certificates. If
you loose the key or two factor device you loose SSL on the domain, no
exceptions. When I go to google.com all I really care is that it is the same
site that I visited yesterday. The current SSL scheme gives no such assurance.

------
sebcat
What if confidentiality and authenticity would be handled by IPSec/DNSSEC
instead of using solutions at the transport layer? This is not my idea, or
new, but it makes more sense to me. Why do we move towards implementing
security measures higher up in the abstraction layers when it should be a core
part in any system?

~~~
nextstep
It's too bad you didn't read the article. He answers your exact question.

