
How HTTPS Handshake Happens - sudhakarrayav
http://sudhakar.online/programming/2015/08/09/https.html
======
ivanr
As others have already pointed out, this explanation focuses on the RSA key
exchange, which has been deprecated. It's not recommended for use with the
current line of protocols (TLS 1.2 and earlier) and it's been completely
removed from TLS 1.3 (work in progress, but close to being finished). The key
weakness of the RSA key exchange is that session encryption keys are
transported over the network encrypted with the server's public key. When the
server's private key is compromised in some way, the attacker can passively
decrypt all traffic, they can also "go back in time" to decrypt all previous
conversations they might have recorded and kept.

For a more secure handshake approach, consider the Diffie-Hellman key
exchange, which is a way for two parties to agree on a secret number (a very
large number when used for encryption, of course) that third party can't
discover from looking at the network traffic. It's a very simple and intuitive
algorithm; there's a great video that explains it here:
[https://www.youtube.com/watch?v=YEBfamv-
_do](https://www.youtube.com/watch?v=YEBfamv-_do) Today, we generally use the
ephemeral elliptic curve DH variant (ECDHE), which has better security
characteristics and works much faster.

However, DH is not sufficient, you must also authenticate the other party.
Otherwise you could be negotiating your key exchange with the attacker and not
the real recipient. This is where public cryptography comes in. After the key
exchange, both parties use their private keys to sign the transcripts of the
entire conversation up until that point. When this is verified you know that
(1) you're talking to the right person and (2) that you have a secret (session
keys) that you can use to efficiently protect the conversation.

Disclosure: I am the author of Bulletproof SSL and TLS, already mentioned in
another comment here. Feel free to ask me anything.

~~~
MyDogHasFleas
Ivan, I bought your book "Bulletproof SSL and TLS". It's excellent, and I
recommend it to those who are charged with building, deploying, or managing a
real world deployment that includes TLS.

~~~
schoen
I have yet to buy it, but I've recommended it to five or six people who said
they wanted to understand TLS, because I've never heard of someone being
disappointed by it!

I think I'll buy my own copy today. :-)

~~~
schoen
As an update, I've ordered a copy and look forward to reading it.

------
lowleveldesign
If you are interested in details of the TLS protocol, check out these two
books:

\- Implementing SSL / TLS Using Cryptography and PKI [1]

\- Bulletproof SSL and TLS: Understanding and Deploying SSL/TLS and PKI to
Secure Servers and Web Applications [2]

In the first one the author implements the protocol (RSA/DH) from scratch
(without even using any crypto library). The second one is a classic and
contains a lot of interesting scripts (the chapter on using OpenSSL and
creating your own PKI is available for free:
[https://www.feistyduck.com/books/openssl-
cookbook/](https://www.feistyduck.com/books/openssl-cookbook/)).

I spent some time studying TLS and wrote two blog posts [3][4], in which I
decrypt the network traces of the TLS sessions. Maybe someone will find them
interesting too.

[1] [https://www.amazon.com/Implementing-SSL-TLS-Using-
Cryptograp...](https://www.amazon.com/Implementing-SSL-TLS-Using-
Cryptography/dp/0470920416)

[2]
[https://www.amazon.com/gp/product/1907117040](https://www.amazon.com/gp/product/1907117040)

[3] [https://lowleveldesign.org/2016/03/09/manually-decrypting-
ht...](https://lowleveldesign.org/2016/03/09/manually-decrypting-https-
request/)

[4] [https://lowleveldesign.org/2016/05/10/tls-1-2-aes-gcm-and-
ne...](https://lowleveldesign.org/2016/05/10/tls-1-2-aes-gcm-and-net-network-
trace/)

~~~
dotancohen
I haven't read the books, and I'm sure that they are fascinating, but I am
wary of any attempt to home-brew crypto. I'm specifically worried that some
corner-cutters might use the Implementing SSL book's code or ideas in
production.

~~~
marklgr
What's the alternative, lock all books related to cryptography lest someone
might do something in production? Educating is fine, and people reading
relatively advanced technical books like this one should be considered as
responsible, I think.

~~~
pampa
Not only reasonable, but it is a must. I think the "don't roll your own
crypto" phrase is widely misunderstood. A better phrase would be - learn as
much about crypto as you possibly can, to clearly understand why it is a bad
idea to roll your own in production. This also means that after you learn it,
you will have a much better idea which library, cypher or mode to pick for a
particular task, and not just think "oh, crypto is complicated, i will just
wrap everything in TLS and won't bother to check the certs"

~~~
djsumdog
People who are wanting to get into complex cryptography today have to start
somewhere. Showing working models, with huge disclaimers, in blog posts and on
github is a great way to lean, if you invite others to show you flaws and
break your implementation.

~~~
tptacek
If you want to build complex cryptography, you must either obtain formal
training, or learn how to break complex cryptography.

What you can't do is read a book or two about cryptography, the way you would
a new programming language, and then bootstrap your own expertise from that.
Cryptography is _a lot_ trickier than most other topics in computer science.

~~~
kasey_junk
> Cryptography is a lot trickier than most other topics in computer science.

Is that actually true? Or is it that most software development isn't really
about topics in computer science. Like if you wanted to design your own
distributed database wouldn't most of what you said above also apply?

Isn't this really a case where "hard topic is hard"?

~~~
tptacek
I thought about that when I wrote that comment and my conclusion is, no:
distributed systems protocols are notoriously hard, but they don't have
_adversaries_. Crypto protocol flaws are marginally more complicated than
distributed systems flaws, but also, a distributed system with a byzantine
fault can be survivable, and a cryptosystem with a subtle flaw won't be.

~~~
kasey_junk
I'd buy that having adversaries is what makes crypto different than other
topics. Thats probably a better way to pitch your message as well.

------
mrkurt
There are some really cool "tricks" for avoiding the round trip — round trips
are why everyone should be using a global load balancer for SSL. Clients have
to send 2 packets across the world and wait for a reply, which can add >100ms
before any actual work happens.

http2 helps because you can multiplex a bunch of requests into a single
connection, less waiting on new connections to be established.

TLS 1.2 with session resumption lets clients reuse existing sessions after the
first connection.

TLS 1.3 has a 0rtt handshake, which is pretty baller. It's just not widely
deployed.

~~~
bogomipz
>"There are some really cool "tricks" for avoiding the round trip — round
trips are why everyone should be using a global load balancer for SSL. Clients
have to send 2 packets across the world and wait for a reply, which can add
>100ms before any actual work happens."

What is a "global load balancer"? A load balancer doesn't avoid any round
trips. The "work" of TLS begins as soon as the client sends a ClientHello
which is during the second round trip. On a new connection the total round
trips is 4 if you include the GET request. It's 3 round trips if you only
consider the TCP hand shake and the TLS handshake. This is true whether there
is a load balancer or not.

~~~
TheSwordsman
I assume a load balancing / caching solution that is available on an anycast
IP address. The TLS termination happens at the (ideally) closest point of
presence (PoP). The idea is to reduce the RTT from client to its termination
point.

Think CloudFlare CDN or the Google Cloud Load Balancer.

 _Edit_ Mistyped RTT as TTL.

~~~
bogomipz
Sure, you can reduce the RTT by moving the edge closer to the eyeballs but
that's not the same as avoiding an RTT as the OP stated. That's what all I was
commenting on. There are mechanisms however to do that such as sessions
tickets/resumption but that's not something specific to load balancers.

~~~
kelnos
The OP didn't claim using a "global" LB would eliminate round-trips, just that
you should use one _because_ of the round trips.

~~~
bogomipz
The OP stated:

>"There are some really cool "tricks" for avoiding the round trip — round
trips are why everyone should be using a global load balancer for SSL."

"Avoiding" means not incurring them, so yes they did claim a "global" LB would
eliminate round trips.

~~~
mrkurt
That actually wasn't what I meant to claim, but it's too late to edit! It was
an awkward sentence for sure.

The simpler sentence is: minimize round trip cost by getting close to users.
Also avoid round trips if you can. :)

~~~
bogomipz
If you are terminating TLS on an edge network then you are likely caching the
content there as well so as not to incur the latency in fetching it from
origin. This is called a CDN not a load balancer.

~~~
mrkurt
There are a bunch of relatively pure global load balancer services available
out there. Google Cloud's load balancer, for example. It works pretty well to
terminate SSL close to visitors then maintain connections from load balancers
back to app instances.

------
calebbrown
Doesn't cover perfect forward secrecy (PFS).

Without PFS if the server's private key was stolen (e.g. by hacking the
server) then all traffic sniffed in the past could be decrypted.

See:
[https://en.wikipedia.org/wiki/Forward_secrecy](https://en.wikipedia.org/wiki/Forward_secrecy)

------
cabaalis
Genuinely curious, as HTTPS is something I do not fully understand even with
this simplification:

If the browser's symmetric key is encrypted with icicibank's public key, why
can't a sniffer unlock it by also requesting icicibank's public key and
decrypting the key sharing message?

~~~
usmannk
The payload is encrypted with the bank's public key but it can only be
decrypted with their private key. This is the basis of public key cryptography
[1].

[1] [https://en.wikipedia.org/wiki/Public-
key_cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography)

~~~
theEXTORTCIST
When talking HTTPS it's important to note that the protocol uses both
asymmetric and symmetric key encryption.

Asymmetric key exchange for secure session setup / authentication

Symmetric key for secure session data encryption

[https://tools.ietf.org/html/rfc4346#section-1](https://tools.ietf.org/html/rfc4346#section-1)

------
the_arun
Similar articles for reference:

1\. [https://www.ssl.com/article/ssl-tls-handshake-
overview/](https://www.ssl.com/article/ssl-tls-handshake-overview/) 2\.
[https://msdn.microsoft.com/en-
us/library/windows/desktop/aa3...](https://msdn.microsoft.com/en-
us/library/windows/desktop/aa380513\(v=vs.85\).aspx) 3\.
[https://hpbn.co/transport-layer-security-tls/](https://hpbn.co/transport-
layer-security-tls/)

Also note the delay created by each step in (3).

------
BrandoElFollito
I did not see it in the comments, so here is a great article on how the
handshake happens : [http://www.moserware.com/2009/06/first-few-milliseconds-
of-h...](http://www.moserware.com/2009/06/first-few-milliseconds-of-
https.html)

------
skyisblue
Even with TLS 1.3 the fastest handshake for an initial connection is one round
trip. That's around 250ms for someone connecting to a server in New York from
Sydney Australia. Is there any other way to reduce this handshake time for
visitors located geographically far from the server with end to end
encryption?

~~~
3pt14159
Under what circumstances would the _initial_ connection need to be faster than
250ms for arbitrary HTTPS access? I can think of maybe it mattering to people
that work with financial data, but outside of that I can't really see it
mattering.

~~~
hueving
Loading a bunch of assets from different servers in a serial or semi-serial
(e.g. 6 at a time) gets really impacted by that.

~~~
GRiMe2D
Loading bunch of assets from different servers to enter a site is a very bad
idea.

------
nishs
Can someone explain what "any of my trusted keys" in the graphic is referring
to? (on the browser)

~~~
sdevlin
It's impossible to bootstrap a secure connection without some preexisting
trusted relationship. Otherwise, you'd always be vulnerable to middle-person
attacks.

Browsers solve this problem by bundling a number of trusted root certificates.
(This is what they mean by "my trusted keys".)

When you connect to some web site, the server sends you their certificate
along with a chain of signing certificates up to some root of trust. Assuming
the root certificate is among those your browser trusts, you can verify the
signature chain and establish a trusted connection.

------
crisp
Little ironic the blog isn't under a valid SSL cert

~~~
beefhash
If you actually look at the details, that seems to be related to the blog
being hosted on GitHub Pages. GitHub Pages does not support TLS for custom
domains.

See also:
[https://gist.github.com/coolaj86/e07d42f5961c68fc1fc8](https://gist.github.com/coolaj86/e07d42f5961c68fc1fc8)
("Please petition Github to support HTTPS on github pages") and comments

------
had2makeanacct
[http://sudhakar.online/visualization/2011/10/11/wedding-
invi...](http://sudhakar.online/visualization/2011/10/11/wedding-invite.html)

Found this on this site, parallax.js wedding invitation. This is cool, how
hard is it to learn how to do this?

~~~
apathetic
Curious how you ended up asking on this thread.

~~~
uhhfcuvv
If you read his past comments, he's either 15, Indian, or both.

~~~
had2makeanacct
So fucking what. I can't ask questions?

