

How does SSL work? - lucb1e
http://security.stackexchange.com/questions/20803/how-does-ssl-work/20833

======
tptacek
Roughly:

1\. C & S exchange messages to agree on versions, ciphersuites, and nonces.

2\. S->C certificate, which includes an RSA public key.

3\. C verifies certificate against its local cache of CA roots.

4\. C->S random secret encrypted under the RSA key (the "pre-master secret").

5\. C & S derive (the same) set of MAC keys, crypto keys, and crypto
parameters.

6\. C & S verify every message of the handshake with the MAC keys.

Other useful things to know:

* SSL/TLS operates over a "record layer" of TLV-style messages. The TLS record layer itself supports fragmentation, which is a little crazy.

* The server can ask the client to send a certificate too; this is common on backend connections and unfortunately not common with browsers, because the UI is terrible.

* Less commonly, C & S can opt for a "DHE" (ephemeral Diffie-Hellman) key exchange, in which the RSA key from the certificate is used to sign a DH key exchange (DH allows both sides to use random public keys instead of long-term fixed keys, but suffers from exposure to MITM attacks --- the RSA key from the cert "breaks the tie" in a MITM situation, making the exchange secure). This has the advantage of ensuring that even if an attacker has been recording all your traffic for years, she can't compromise a server's private key and then decrypt older connections. This is called "forward secrecy".

* The two common cipher suites used on most connections are AES in CBC mode and RC4. AES-CBC chunks plaintext into 16 byte blocks, padding the last block if there are insufficient bytes to fill it. Until TLS 1.1, TLS ran CBC in a continuous stream over the whole connection, using the last block of the most recent message as the IV for the next, which gave rise to the BEAST flaw. RC4 is a stream cipher that encrypts byte-at-a-time --- but nobody trusts RC4 much.

* TLS 1.2 (IIRC) introduces AES-CTR, which runs AES as a stream cipher.

~~~
zanny
I've always wondered if / what is stopping someone from eves dropping or
duping the initial handshakes before the communications are encrypted. If you
get the cipher and understand the schema used you should be able to decode the
otherwise secure traffic.

~~~
cheald
This video explains it in very easy-to-grasp terms:

<http://www.youtube.com/watch?v=3QnD2c4Xovk>

~~~
TazeTSchnitzel
I prefer this one by the Royal Institution:

<https://www.youtube.com/watch?v=U62S8SchxX4>

------
mitchellh
I just finished reading this book: "SSL and TLS: Designing and Building Secure
Systems"[1] and I now have a _much_ better understanding of how SSL works,
what security it provides, how it provides it, and when and where to use it.

It is a thorough read and not the easiest, but you can always pick and choose
what chapters you're interested in. I highly recommend it. You can buy it from
Amazon here (not an affiliate link):

<http://www.amazon.com/gp/product/0201615983/>

[1]: <http://www.amazon.com/gp/product/0201615983/>

~~~
philhippus
>(not an affiliate link)

Heaven forbid anyone but Amazon gains financially from your recommendation.

~~~
k-mcgrady
People like to point this out to make it clear they are actually recommending
the product because it is useful and not for financial gain.

------
AndrewNCarr
It doesn't, according to Moxie Marlinspike and others.

[http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysi...](http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysis/)

If you haven't seen any of Marlinspikes presentations, you are missing out on
some fascinating stuff.

Moxie @ Defcon 19: <http://www.youtube.com/watch?v=xIiklPyS8MU>

~~~
tptacek
That's a misstatement of Moxie's position, which is unfortunate because
Moxie's position is important, probably correct, and needs all the credibility
it can get.

What's broken about SSL/TLS is the current CA model. Since SSL/TLS was
introduced, we've been running with almost exactly the same trust "UX": a
hidden browser config panel listing a series of complicated-sounding trusted
root CAs, each with the authority to sell or transfer their business to some
other entity, or even to delegate the authority to sign certificates to other
organizations.

That's absurd; it's a security model that clearly can't work in the real world
--- and, more, demonstrably hasn't worked. SSL CA's have been caught red-
handing selling their authority for dubious reasons. For instance, Trustwave
sold a CA=YES certificate to an undisclosed third-party corporation solely for
the purpose of making it easier (not "possible" but merely easier) for that
corporation to monitor their own users.

We need a radical rethinking of the UI/UX and trust model behind SSL/TLS, and
Moxie's idea of decentralizing that trust --- so that, say, the ACLU could
operate a sort of CA root that would vouch for Verisign's signatures on core
ecommerce sites but not accept a crazy delegation from Iran.

The protocol, on the other hand, is for all its warts the best-tested crypto
protocol in possibly the history of computing. Baby & bathwater, and all that.

~~~
StavrosK
I remember seeing an interview where someone asked a Chrome team member if
they had plans to support Moxie's idea. They said, roughly, that if Chrome
supported it, Google would have to run some notary servers, and people would
rest assured that Google is running them and not be bothered to run their own,
leaving Google with having to support this for the entire internet.

It's too bad, it sounds like a very good idea.

~~~
tptacek
Thankfully, the world does not depend on Google to move decentralized trust
for TLS forward; since it's mostly a UX change, and it's confined to a very
small part of the TLS stack (the verification of server certificates), it can
be retrofit over existing infrastructure with neither changes in server
software nor major changes to browsers. We can probably do it via plugins.

~~~
stanleydrew
What can those of us who like this decentralized CA whitelist idea do to help
it gain adoption? Can I start telling Chrome right now to use a whitelist
maintained by an external source? Should I just pick someone's whitelist (e.g.
ACLU, EFF, yours) and trim my browser and OS whitelists to only use those?

Also how does this affect SSL certificiate "pinning" as implemented in Chrome?
I guess it doesn't since even if you have a pinned cert for a specific domain
Chrome will still verify the trustworthiness of the CA that signed it?

~~~
tptacek
Sorry, I should also have mentioned TACK, Moxie and Trevor Perrin's proposed
system of allowing servers to dynamically update certificate pins. As many
people here know, Chrome already has a system of pinned keys, which mean that
as far as Chrome is concerned, Chrome is the final arbiter of GMail's public
key, not Trustwave or any other CA. TACK allows browsers to keep a cached list
of pins in somewhat similar fashion to HSTS, which caches a list of servers
that must use TLS.

TACK is just a proposed standard right now; I have no idea where it's going.
But it's a good band-aid on the existing CA system.

------
ryanwhitney
Aza Raskin posted this on twitter a while back:

The private-public key encryption concept explained through mixing paint:
<http://www.youtube.com/watch?v=6NcDVERzMGw#t=147s> (Starts at about 2:20.)

------
ta12121
I will never understand why random articles describing well documented
commonplace things make it to the front page.

~~~
mgummelt
Well documented -\\-> Easily understandable. I'd rather read this than an RFC.
Can you point me to a better summary of SSL?

------
lucb1e
Thanks by the way, HN moderators, for expanding the short URL generated by the
site to share. Now it didn't keep track of how many people visited the URL,
and I missed the Announcer badge. May I ask why?

~~~
madsushi
Because the purpose of linking something on HN should be to share it, not to
personally gain from it.

~~~
autocracy
If it's all about sharing, why do we attribute anything here? Might as well
make the submission and all the comments anonymous here as well.

Reputation is mark of making _good_ contributions, and is something that every
site has utility for, including HN.

