HTTPS— In a Nutshell

The minimal number of concepts required for you to understand how HTTPS works

  1. Alice and Bob share a secret key.
  2. Alice can use the secret key to encrypt a file.
  3. Bob can decrypt that encrypted file with the same secret key to return the original message.
### Symmetric Encryption with GPG ###
### Adapted from
# create a random file
echo hi > symmetric-example.txt
# encrypt it with the phrase "mysecret"
gpg --batch
--output symmetric-example.txt.gpg
--passphrase mysecret
--symmetric symmetric-example.txt
# decrypt it with the phrase
gpg --batch
--output symmetric-example-out.txt
--passphrase mysecret
--decrypt symmetric-example.txt.gpg
# check the differences
diff symmetric-example.txt symmetric-example.out.txt

Asymmetric Encryption

A key pair includes a public and private key. The public key can encrypt messages decryptable only with its private key.

  1. Alice generates a public and private key pair.
  2. Alice shares her public key with Bob, which he uses to encrypt a message. Note: Bob cannot decrypt the message using the Alice’s public key.
  3. The encrypted message is decrypted back into the original message using Alice’s private key.
### Asymmetric Encryption with GPG ###
### Adapted from
# generate the key pair as a key-ring
gpg --batch --generate-key <<EOF
Key-Type: RSA
Key-Length: 3072
Subkey-Type: RSA
Subkey-Length: 3072
Name-Real: Alice
Name-Email: [email protected]
Passphrase: alicerocks
Expire-Date: 30
%pubring alicepubring.kbx
# Create a shareable public key, alicepubkey.gpg
gpg --keyring ./alicepubring.kbx
--output alicepubkey.gpg
# Import alice's pubkey into bob's keyring file
gpg --keyring ./bobpubring.kbx
--import alicepubkey.gpg
# Encrypt a file with alice's pubkey
echo "Hi Alice!" > alice.txt
gpg --keyring ./bobpubring.kbx 
--recipient "[email protected]" alice.txt
# Decrypt the file with alice's private key
gpg --keyring ./alicepubring.kbx
--passphrase "alicerocks"
--output alice-decrypted.txt
--decrypt alice.txt.gpg
# Compare the messages
diff -s alice.txt alice-decrypted.txt

Digital Certificates

A digital certificate is an identity file that a “trusted” third party issues (for HTTPS, this is an x.509 certificate). Digital certificates are like passports; they contain identity and certification information about an entity and have a way to verify that this information is correct through the certifying body.

In the case of a passport, the certifying body is a governmental institution (like the United States Department of State), and the entity is a person. The identity information within the passport includes the person’s first name, last name, date of birth, etc., which a customs and border officer can then verify with the institution.

For websites, the certifying body are organizations like Entrust, and the entity is a web server. The certificate includes information about the web server, like its common name (i.e. domain name), organization, country, etc., which a browser can verify.

Programmatically, a digital certificate follows an interface like this:

.public_key # attribute, webserver pubkey
.identity_information # attribute, webserver info
.issuing_CA # attribute, CA info
.verify(CA_public_key) # method, verify it's signed by CA

How Does HTTPS Work?

HTTPS uses the symmetric, asymmetric, and digital certificates to enable secure communication over a network. The following diagram details the data flow from when a web server wants to register with a CA (steps 1–4) to when the web server and browser (i.e. client) can securely transmit data to each other (steps 5–9):

HTTPS Communication
  1. The web server generates a certificate signing request (CSR) which includes identity information about the web server as and its private key. It sends the CSR to a CA.
  2. The CA, once it approves the CSR, signs the CSR, thereby converting it into a digital certificate.
  3. The CA sends the certificate back to the web server.
  4. Upon a GET request to the web server from a client, e.g., a web browser, the web server sends the digital certificate from step 3 to the browser.
  5. Upon receiving the certificate, the browser verifies that the certificate was signed by a known and trusted CA using the CA’s public key. Note: browsers have a database of CA public keys built into them.
  6. Once verified, the browser generates a symmetric session key for encrypted communication between the web server and the browser. This symmetric session key is encrypted using the web server’s public key from the certificate and sent back to the web server.
  7. The web server receives the message which includes the symmetric session key from the client, and decrypts the symmetric session key using its private key
  8. The web server can now symmetrically encrypt messages like HTML files, etc., and send the encrypted message over the internet.
  9. Once the client receives the encrypted message, it can decrypt it and view the message.


You may be wondering, why does HTTPS use both asymmetric and symmetric encryption when this whole process could be satisfied with just asymmetric encryption? That’s because symmetric encryption is fast relative to asymmetric encryption. Once verification between client and server completes, there’s no need for slow, back-and-forth asymmetric communication between client and server.

HTTPS— In a Nutshell was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

(Visited 1 times, 1 visits today)