How SSL/TLS Works: Encryption, Certificates, and the HTTPS Connection

What Are SSL and TLS?

SSL (Secure Sockets Layer) was developed by Netscape in the mid-1990s to secure communications between web browsers and servers. It has since been deprecated due to significant vulnerabilities (including the POODLE and DROWN attacks), and all versions of SSL are now considered insecure. Its successor, TLS (Transport Layer Security), was first standardized in 1999 (TLS 1.0) and has gone through three major revisions, with TLS 1.3 — released in 2018 — being the current standard. Despite the technological succession, the term SSL is colloquially used to refer to what is technically TLS in most practical contexts.

TLS provides three fundamental security services: confidentiality (data is encrypted so eavesdroppers cannot read it), integrity (data cannot be tampered with in transit without detection), and authentication (the identity of the communicating parties is verified through digital certificates). These three properties together make HTTPS trustworthy for sensitive transactions.

Public Key Cryptography

TLS relies on asymmetric cryptography (public key cryptography) for authentication and key exchange. In asymmetric cryptography, each party has a mathematically related key pair: a public key, which can be freely shared, and a private key, which must be kept secret. Data encrypted with the public key can only be decrypted with the corresponding private key, and data signed with the private key can be verified with the public key.

The most common asymmetric algorithms used in TLS are RSA (which relies on the difficulty of factoring large integers) and ECDSA (Elliptic Curve Digital Signature Algorithm, which relies on the discrete logarithm problem over elliptic curves). ECDSA with 256-bit keys provides equivalent security to RSA with 3072-bit keys at a fraction of the computational cost, making it the preferred choice for modern TLS deployments.

Symmetric encryption (where the same key is used for both encryption and decryption) is far more computationally efficient than asymmetric encryption, but requires that both parties share the same secret key — a challenge when they have never communicated before. TLS uses asymmetric cryptography to establish a shared secret, then switches to symmetric encryption (AES in GCM or CCM mode in TLS 1.3) for the actual data transfer. This hybrid approach combines the security of asymmetric key exchange with the performance of symmetric encryption.

Digital Certificates and Certificate Authorities

A digital certificate (specifically an X.509 certificate) binds a public key to an identity. A web server's certificate asserts: this public key belongs to the entity that controls the domain example.com. Without certificates, a client connecting to a server has no way to verify whether they are talking to the legitimate server or a man-in-the-middle attacker who has substituted their own public key.

Trust in certificates is established through a hierarchical system of Certificate Authorities (CAs). A CA is an organization that verifies the identity of certificate applicants and digitally signs their certificates, vouching for the binding between their public key and identity. Operating system and browser vendors (such as Apple, Microsoft, Mozilla, and Google) maintain lists of trusted root CAs — those whose signatures they accept as authoritative. Root CAs typically sign intermediate CA certificates, which in turn sign end-entity certificates presented by web servers, creating a chain of trust.

Certificate validation involves three types of validation: Domain Validation (DV), the most basic, verifies only that the applicant controls the domain; Organization Validation (OV) additionally verifies the organization's legal existence; and Extended Validation (EV), the highest level, involves rigorous identity verification and historically displayed the organization's name in the browser's address bar (though modern browsers have moved away from prominent EV UI treatment).

The TLS Handshake

The TLS handshake is the process by which a client and server establish a secure connection. In TLS 1.3, the handshake has been significantly streamlined compared to earlier versions, requiring only one round trip (compared to two in TLS 1.2) before the client can send application data.

The handshake proceeds as follows: (1) The client sends a ClientHello message containing the TLS version, a random value, supported cipher suites, and key share data for the client's preferred key exchange groups. (2) The server responds with a ServerHello containing the chosen cipher suite and its own key share data, followed by its certificate and a certificate verify message, and a Finished message. (3) Using the exchanged key shares, both parties independently compute the same shared secret using the Diffie-Hellman key exchange mechanism. (4) From this shared secret, both parties derive symmetric session keys for encryption and message authentication. (5) The client sends its own Finished message, and encrypted application data flow begins.

TLS 1.3 mandates forward secrecy — each session uses ephemeral key pairs that are discarded after the session ends. This means that even if an attacker later compromises the server's private key, they cannot decrypt previously recorded sessions, since the session keys were derived from ephemeral key shares that no longer exist.

HTTPS and What It Actually Protects

HTTPS is simply HTTP transmitted over a TLS connection. The padlock icon in a browser's address bar indicates that the connection to the server is encrypted and that the server's certificate was issued by a trusted CA. What HTTPS protects: the confidentiality and integrity of data in transit between the browser and the server, and the authentication of the server's domain name.

What HTTPS does not protect: the content of DNS queries (which reveal the domain being visited to the ISP and DNS resolver, unless DNS-over-HTTPS or DNS-over-TLS is also used), the IP address of the server being connected to, the timing and size of data transfers, or the security of data once it reaches the server. HTTPS also does not guarantee that the website itself is trustworthy — phishing sites routinely use HTTPS to display the padlock while conducting fraud.

Certificate Pinning and Security Considerations

Certificate pinning is a technique used in mobile applications and some browsers to restrict which certificates are trusted for a particular domain, beyond the standard CA trust model. A pinned application associates a specific certificate or public key hash with a server, rejecting any certificate that does not match even if it is validly signed by a trusted CA. This protects against scenarios where a compromised or rogue CA issues a fraudulent certificate for the domain. However, pinning creates operational challenges when certificates are rotated and can cause application failures if pins are not updated in sync with certificate changes.

The Certificate Transparency (CT) system, now required by all major browsers, addresses the rogue CA problem differently by requiring that all publicly trusted certificates be logged in publicly auditable CT logs before browsers will accept them. This makes it impossible for a CA to issue a secret certificate — all certificates are discoverable, allowing domain owners and security researchers to detect unauthorized certificates quickly.