What Is an SSL/TLS Handshake?
An SSL/TLS handshake is a negotiation between two parties on a network – such as a browser and web server – to establish the details of their connection. It determines what version of SSL/TLS will be used in the session, which cipher suite will encrypt communication, verifies the server (and sometimes also the client), and establishes that a secure connection is in place before transferring data.
This all happens in the background, thankfully – every time you direct your browser to a secure site a complex interaction takes place to make sure that your data is safe.
That’s the simple version. You might notice that any dozen descriptions will hew more or less to this format, while differing in detail a dozen different ways – sometimes confusingly so. Let’s throw a chart up that shows a broad model of how a TLS handshake works, shall we?
Obligatory SSL/TLS Handshake Graphic
All SSL/TLS-related sites have their own version of a handshake diagram – here’s ours! (Click to enbiggen.)
Let’s Clear Up Some Confusion, If We Can
Some confusion about how SSL/TLS handshakes work is due to the handshake being only the prelude to the actual, secured session itself. Let’s try to address some common points:
Asymmetric vs symmetric encryption
The handshake itself uses asymmetric encryption – two separate keys are used, one public and one private. Since asymmetric encryption systems have much higher overhead, they are not usable to provide full-time, real-world security. Thus, the public key is used for encryption and the private key for decryption during the handshake only, which allows the two parties to confidentially set up and exchange a newly-created “shared key”. The session itself uses this single shared key to perform symmetric encryption, and this is what makes a secure connection feasible in actual practice (the overhead is vastly lower). So the full and correct answer to “Is SSL/TLS encryption asymmetric or symmetric?” is “First one, then the other.”
What is a “cipher suite”?
The handshake itself has multiple stages, each managed according to different rules. The details can be found here, but the nut of it is that rather than a series of separate back and forth negotiations (about what keys to use, how to encrypt the handshake itself, how to authenticate the handshake and so forth) the parties can agree to use a “cipher suite” – a pre-existing selection or kit of agreed-upon components. (Remember that asymmetric encryption is costly time- and resource-wise – using the cipher suite as a shortcut speeds up the handshake itself.) TLS specifications allow for quite a number of cipher suites, and the client and server will almost always have access to one they can both employ.
Basic vs mutually-authenticated handshake
Another confusing point is that the basic model we described above lets the client verify the server, and the vast majority of sessions secured by TLS only require this. However, some cipher suites will require the client to also send a certificate and public key for mutual authentication of both parties. This two-way authentication will of course add overhead to the handshake – however, in some cases (for instance, where two banks are negotiating a secure connection for fund transfers) the cipher suite will insist upon it, and the extra security is deemed worth it.
Different sessions will have different security parameters
Each new handshake creates a new session, and the settings used in one can differ drastically from another depending on the cipher suite chosen. This is among the reasons so many different iterations of that darned handshake chart exist, and why we are giving a fairly broad overview here. Also know that sessions can set parameters that may not be exactly what you expect. Depending on the cipher suite, some steps may be added (like the requirement for two-way authentication) or absent. In fact, there are actually cipher suites that negotiate a session to use no encryption whatsoever. (Yeah, we know, an HTTPS connection over port 443 which decides to send data in the clear makes no sense to us either. SSL.com strongly recommends you not do this – just be aware that it’s in the realm of the possible.)
We hope this information helps you understand the TLS handshake process. Let us know if you have questions or comments – remember, SSL.com believes a safer internet is a better internet.”
