Https

https://howhttps.works/the-handshake/

What is HTTPS?

HTTPS is the secured version of HTTP: HypterText Transfer Protocol. In other words, when the exchange of data is encrypted with SSL/TLS, then it's HTTPS (S is for SECURE).

What is HTTP?

HTTP is the protocol used by your browser and web servers to communicate and exchange information.

What is SSL/TLS?

SSL - Secure Sockets Layer

  • Protocol created by Netscape for secured encryption on the web

SSL was renamed to TLS - Transport Layer Security.

Why do we need HTTPS?

  1. Privacy

    • Nobody can see the messages sent between two individuals

  2. Integrity

    • Nobody can manipulate the messages sent between two individuals

  3. Identification

    • Confirm the identity of the receiver of the message

Encryption

Is how we achieve the 3 things above. There are two types of encryption algorithms.

Symmetric Key Algorithm

We have one key to encrypt and decrypt a message. People who do not have the key see the message as nonsense text.

  1. Before sending a message, the message is encrypted with the key

    • Put message in box and lock with key

      • Text is generated by encryption algorithm (text was scrambled through series of random steps)

      • Decrypt message - we just apply same steps in reverse order

      • Encryption key mixed with message, so even if you know encryption algorithm, message is still nonsense

  2. Only person that has copy of key can open box and read message

This key must be kept private (should not be shard in plain text, sent with the boxed message)

Problem: We have to be very careful about how we are distributing the key.

Asymmetric Keys

Two keys: public and private.

You can share your public key with anyone.

  1. Receiver sends their public key to sender

  2. Sender sends message back and encrypts it with the public key

  3. Receiver can open and read message ONLY with their private key.

The Handshake

This is the negotiation between a browser and a server.

Note: Step 1-4 is all open, nobody can spy on the communication because the pre-master key is encrypted using the asymmetric keys

  1. Left Clap (BROWSER)

    • Browser sends list of SSL/TLS versions and encryption algorithms that browser works with (this list is cipher suite)

  2. Right clap (SERVER)

    • Server chooses the best SSL/TLS versions and encryption algorithms based on server preferences

    • Then, server replies with certificate (which includes server's public key), so browser can verify who the server is

  3. Vertical Shaka (CLIENT KEY EXCHANGE)

    • Browser checks server's certificate to make sure it's legit

    • Browser generates 'pre-master key' so browser and server can use it later when generating a unique key

    • Browser encrypts pre-master key with server's public key, and sends it to the server

  4. Shaka horizontal rotation (CHANGE CIPHER SPEC)

    • Server uses its private key to decrypt the pre-master key

    • Browser and server generates the same "shared secret" that they are going to use as a symmetric key

  5. Tickles (EVERYTHING IS SECURED NOW)

    • Now, all data going back and forth between browser and server is secured for the rest of the session

Certificate Authorities (CA)

A third-party organization with 3 objectives:

  1. Issuing certificates

  2. Confirming identity of certificate owner

  3. Providing proof that certificate is valid

Root store

A database of trusted CAs.

Apples, Windows, and Mozilla run their own root stores that they pre-install in your device.

Types of Certificates

  1. Domain validated

    • Verifies domain name (nothing else) - probably need this one

  2. Organization validated

    • Requires validation and manual verification of organization behind certificate

  3. Extended validation

    • Requires exhaustive verification of the business

How Certificates are validated (Chain of Trust)

CA signs certificate with root certificate pre-installed in root store

  • Usually an intermediate certificate signed with root

    • If root certificate is compromised, easier to revoke the intermediate certificates since root certs are installed on the device

  • Browser connects to a site via HTTPS

  • Browser downloads certificate (not the root certificate)

  • Browser downloads certificate used to sign the certificate on the site (intermediate one) - still not the root certificate

  • Browser looks up certificate that signed intermediate certificate - found the root certificate!

    • If we searched all certificates and non are the root, the chain is untrusted

  • Entire certificate chain is trusted, so site certificate is trusted too

Last updated