HTTPS is the web communication protocol for secure communications allowing for authentication and privacy while communicating over the World Wide Web. Unbeknownst to many, it is a foundational layer in almost every request you make on the internet! Whether logging into your bank or chatting on Facebook via a mobile app, HTTPS has been involved.

In canonical terms you can think of communication over the internet as sending a letter through a giant series of pipes. On one end of the pipes is you, the user sending the letter, on the other a web server. These pipes are not owned or their path predetermined by you or the web server so before secure communication can take place you must ensure the web server at the end of the pipes is who they say they are. You must ensure a third party hasn’t intercepted the letter somewhere along the series of pipes and is responding, pretending to be the web server (man-in-the-middle attack). Conversely the web server may need to ensure you are who you are, such as in a banking application. This is what HTTPS was built to solve. It involves a “handshake” process whereby the user and the web server send their credentials to verify they are who they say they are and if so send further communication. This is all without having to trust the medium over which it is being transmitted. Whether you know it or not this occurs on many of the web sites you visit everyday!

Before I walk through the steps involved in the HTTPS handshake, I want to go over a few concepts required to understand it - hashing, what public and private keys are, how symmetric and asymmetric key cryptography works, and a brief explanation of web certificates.

Hashing

Hashing is a mathematical function that maps data of an arbitrary size to that of a fixed size, which is needed for generating keys and ensuring data integrity (digital signatures). There are many functions commonly used, all being deterministic with a relatively uniform distribution of mappings. Those with an exact 1-to-1 mapping of inputs to outputs are deemed ‘perfect’. A common use of hashing, digital signatures, uses hashing to prove a message has not been tampered with. This works because if a message is altered whatsoever the input to the hashing function is different and results in a different hash being outputted.

Symmetric Cryptography

Symmetric cryptography involves a single hash called a private key used for both the encryption and decryption of the message. Encryption here means applying the private hash against the message to turn it into a jumble of words that only the receiver with the same key can decrypt into the original message.

Asymmetric Cryptography

Public key (or asymmetric) cryptography involves a pair of keys, one private and one public. The private key is kept secret, only known to the owner. The public key is widely exposed. Messages are encrypted using the public key, but can only be decrypted with the private key. Think of a math function that you can add input to and easily form a result, but is extremely difficult to reverse engineer and use the result to determine the input. This form of encryption depends on the computational difficulty of deriving a private key given a public key by utilizing mathematical functions with no efficient solution to solving.

Web Certificates

Web certificates (X.509) are used for authentication of a web server or client, similar to one’s drivers license. A trusted source called a certificate authority (CA) issues certificates, binding a public key to it and allowing anyone to validate with it that whomever has the certificate is who they say they are. Using the driver’s license analogy, the CA would be akin to the Department of Motor Vehicles issuing someone an ID. Modern browsers come pre-installed with a list of said certificate authorities that they trust, just as the legal system only considers certain forms of identification valid. Client certificates are also prevalent; just as a server needs a web certificate to tell users they are who they say they are, users may require client certificates to provide a server their identity. There is more here, such as revocation lists and CA’s besides root authorities, but we’ll keep it simple.

With that under our belt, let’s walk through the HTTPS handshake process:

The HTTPS Handshake

1. Since there are multiple versions of the SSL/TLS standard, first the client sends its SSL settings to the server
2. The server will be setup to only accept certain modern SSL/TLS standards and so it sends those SSL settings and its web certificate to the client
3. The client then verifies the server’s certificate by checking various properties of it:
   1. Is today’s date within the certificate’s validity period?
   2. Is the issuing certificate authority trusted?
   3. Does the issuing certificate authority’s public key validate the certificates digital signature?
      1. As referred to above, the digital signature is created by creating a one way unique hash of the data being sent and then encrypting it with a private key. This allows the recipient to also generate a one way hash of the data and compare it to the decrypted payload, ensuring the data has not been tampered with.
   4. Does the servers name match that in the certificates?
4. If the web certificate checks out, a secret is generated by the client, encrypted using the server’s public key, and sent to the server, along with a client certificate. Since the message was encrypted with the server’s public key only the server with it’s private key can decrypt the message and read the secret.
5. Now the server verifies the client certificate:
   1. Does the client’s public key validate the user’s digital signature?
   2. Is today’s date within the certificate’s validity period?
   3. Is the issuing certificate authority trusted?
   4. Does the issuing certificate authority’s public key validate the certificates digital signature?
   5. Is the now authenticated user authorized to access this resource?
   6. If the client certificate checks out, the server will decrypt the message using its private key
6. A secure connection can now be established.

Once the handshake is complete both the server and the client have the secret that they use to generate the session key. The session key being symmetric without the computational complexity is significantly faster to apply to messages and is thus used for the continuing session communications. Prior to the handshake, there was no way to use symmetric encryption as there was no secure way to transmit a common key to the recipient. Essentially the handshake process is a way of securely sending a “key to your letter” to whom you’re trying to communicate with. If someone intercepts the letter only the sender and the designated recipient can open it.

Please feel free to email me with any thoughts, comments, or questions! Follow me on Twitter and continue visiting my blog - AustinCorso.com for follow-up posts.