How Does SSL Work?

A quick review of sockets

Sockets are widely known in computer science, and the methods for sockets are named similarly in almost all programming languages — usually bind(), listen(), connect(), accept(), send(), and recv().

When I use the term “server” in this post, I only mean the computer that called listen() on a socket. It does not have to be a web server or HTTP server.

TLS can also be used to secure other protocols, such as SSH. In fact, any protocol can theoretically be encrypted with TLS, since it only involves signed certificates.

Standards and you

SSL is the old version and TLS is the new version. No SSL version has been supported since 2015, but “the name ‘SSL’ is commonly used to refer to TLS.” In this post, SSL refers to the original version.

For public-key cryptography there’s an entire class of standards collectively called PKCS:

• PKCS#1 — RSA public and private keys used in SSL/TLS.
• PKCS#3 — Diffie-Hellman key exchange.
• PKCS#7 — describes the binary syntax that certificates are encoded into.
• PKCS#8 — describes the private key format, in PEM format:

-----BEGIN PRIVATE KEY-----
MIIBVgIBADANBgkqhkiG9w0BAQEFAASCAUAwggE8AgEAAkEAq7BFUpkGp3+LQmlQ
Yx2eqzDV+xeG8kx/sQFV18S5JhzGeIJNA72wSeukEPojtqUyX2J0CciPBh7eqclQ
2zpAswIDAQABAkAgisq4+zRdrzkwH1ITV1vpytnkO/NiHcnePQiOW0VUybPyHoGM
/jf75C5xET7ZQpBe5kx5VHsPZj0CBb3b+wSRAiEA2mPWCBytosIU/ODRfq6EiV04
lt6waE7I2uSPqIC20LcCIQDJQYIHQII+3YaPqyhGgqMexuuuGx+lDKD6/Fu/JwPb
5QIhAKthiYcYKlL9h8bjDsQhZDUACPasjzdsDEdq8inDyLOFAiEAmCr/tZwA3qeA
ZoBzI10DGPIuoKXBd3nk/eBxPkaxlEECIQCNymjsoI7GldtujVnr1qT+3yedLfHK
srDVjIT3LsvTqw==
-----END PRIVATE KEY-----

A password-protected private key looks similar, but with the ENCRYPTED PRIVATE KEY label instead. A PEM file always starts with -----BEGIN followed by a label and -----, then a base64-encoded message, then -----END, the same label, and -----. The label could denote a public key, a private key, a certificate, or another cryptographic object.

• PKCS#10 — defines the message you send to a CA to request a certificate.
• PKCS#12 — describes how to bundle a private key, certificate, and other security resources into a file called a SafeBag, with a .p12 or .pfx extension.

Certificates

Certificates are electronic documents used to improve the security of SSL/TLS by proving you own the public key inside the certificate. Certificates are transmitted in a chain — the parent certificate is transmitted after the child, and so on, until a root certificate ends the chain.

Root certificates sit at the top of the chain and are unquestionably trusted; some are built into browsers by default.

Every certificate has an associated key pair — a public key and a private key. “A key pair proves that you are really the person who you claim to be,” which is stronger than a password, since passwords a dozen characters long are increasingly easy to brute force. Keys are fixed-length, long, garbled byte sequences.

Each certificate in the chain is in the X.509 file format, containing:

• Version Number
• Serial Number
• Signature Algorithm ID
• Issuer Name
• Validity period (Not Before / Not After)
• Subject name
• Subject Public Key Info (algorithm + public key)
• Extensions (Certificate Key Usage, Certificate Policy, Basic Constraints, etc.)

…followed by the certificate signature algorithm and the signature itself.

How certificates are managed

A certification authority (CA) issues (signs) certificates. CAs are grouped into a public key infrastructure (PKI) — usually one per company, unless that company has the right to issue certificates to third parties.

A CA revokes certificates if their private keys are compromised. The X.509 format has a certificate revocation list (CRL) — a blacklist of revoked certificates. Certificates also typically carry a certificate policy (CP), describing the conventions the PKI follows when issuing or managing them.

The handshake

When two computers connect (usually after one calls accept() on a socket the other is listen()ing to), they run a standard handshake procedure, taking a few hundred milliseconds:

1. The client sends a ClientHello — the TLS version to use, the supported cipher suites, and a random byte string called the client random.
2. The server sends a ServerHello — its TLS certificate, a cipher suite chosen from the client’s list, and its own random string, the server random.
3. The client checks whether the certificate can be trusted, using its list of trusted root certificates’ public keys.
4. The client gets the server’s public key from the certificate, creates a premaster key, and encrypts it with the server’s public key — only decryptable with the server’s private key. Once decrypted, both sides have the premaster key.
5. Both sides generate the same session key from the client random, server random, and premaster key. If the generated keys differ, the session has likely been intercepted. Session keys encrypt and decrypt data sent via send()/recv(), and are only valid for the lifetime of the connection.
6. The client sends a finished message encrypted with the session key; the server does the same.

If any step fails — including certificate validation — the connection must not be considered secure, and browsers typically abort it.

From this point, transmitted data is combined with the session key using a hashing algorithm to generate a message authentication code (MAC), ensuring data integrity — if the MACs generated by each side don’t match, the data has been tampered with.

Certificate validation algorithm

1. Check the public key algorithm.
2. Test the current date/time against the certificate’s validity period.
3. Check revocation status via a certificate revocation list.
4. Check that the issuer name matches the subject name on the higher certificate (if any).
5. Check that the subject name is within the permitted subtrees (and not the excluded subtrees) of all higher certificates.
6. Check that all of the certificate’s policies are within the permitted policies of the higher certificate.
7. Confirm the certificate’s policies are used properly — only make SSL connections with certificates carrying the SSL policy.
8. Check the certificate’s path length against any maximum specified in this or a higher certificate.
9. Check the key usage extension allows signing certificates.
10. Validate any other extensions.
11. Repeat all of the above for each higher certificate in the chain until reaching a root certificate, which is automatically trusted.

Viewing HTTPS certificates in your browser

In Chrome, Firefox, or most other browsers, click the padlock icon in the address bar, then “More Information” or “Certificate” to see the details.

How to get certificates

• Domain Validated (DV) — proves you control the domain, typically via a WHOIS lookup. The only type that can be issued and installed automatically.
• Organization Validated (OV) — proves you’re a legal organization that owns the domain, requiring legal documents and a manual check. Not available to individuals.
• Extended Validation (EV) — proves you’re a real person or organization that owns the domain, requiring legal documents, a manual check, and proof of physical location.

To request a certificate, you fill in a certificate signing request (CSR), generate a key pair for it, and sign it with the private key. Each CA also has a certification practice statement (CPS) describing its issuing and management procedures.

If you just need a TLS certificate for your website, you can get a free DV certificate from Let’s Encrypt or Cloudflare. You can also self-sign a certificate with openssl, but this isn’t recommended — major browsers will warn users that the site isn’t trustworthy.

Quick acronym roundup

Acronym	Full word
CA	Certificate Authority
PKI	Public Key Infrastructure
CRL	Certificate Revocation List
CP	Certificate Policy
MAC	Message Authentication Code
DV	Domain Validation
OV	Organization Validation
EV	Extended Validation
CSR	Certificate Signing Request
CSP	Certification Signing Process