How HTTPS Secures Your Data: A Beginner’s Guide to TLS, Encryption, and Certificates

This article, based on personal study and understanding, explains the conceptual aspects of how HTTPS ensures security, without delving into hardcore encryption algorithm analysis or packet capture data.

To understand how HTTPS protects us, you first need to grasp three prerequisite concepts.

Why Do We Need HTTPS?

Because the HTTP protocol is insecure.

HTTP is a clear‑text protocol; the entire transmission is transparent, allowing anyone on the network to intercept, modify, or forge request and response messages, making data completely untrustworthy. Browsers now flag HTTP sites as "Not Secure" and may even block them by default.

Therefore we need a protocol that can guarantee security—HTTPS.

What Is HTTPS?

HTTPS stands for HyperText Transfer Protocol Secure; the "S" represents SSL/TLS.

SSL (Secure Sockets Layer) is the original security layer, later replaced by TLS (Transport Layer Security). TLS 1.0 is essentially SSL v3.1. As of 2023, TLS 1.3 is the newest version, but TLS 1.2 remains the mainstream; older versions are considered unsafe.

What Is Security?

Security is typically defined by four properties: confidentiality, integrity, authentication, and non‑repudiation.

Confidentiality (Secrecy/Confidentiality): Data is kept secret and visible only to trusted parties.

Integrity (Integrity): Data is not altered during transmission.

Authentication (Authentication): The identity of the communicating parties is verified.

Non‑repudiation (Non‑repudiation/Undeniable): Parties cannot deny actions they have performed.

Meeting the first three properties solves most security communication problems; lacking non‑repudiation means transactions cannot be reliably proven.

A story of three characters illustrates these properties: without confidentiality, an eavesdropper hears a private conversation; without integrity, a message is altered; without authentication, a forged note causes confusion; without non‑repudiation, a party can deny having sent something.

In summary, all four properties must be present for true security.

Confidentiality is most commonly achieved through encryption . Encrypted ciphertext can only be read with the correct key , and the encryption algorithm is public and subject to peer review.

Encryption algorithms fall into two categories based on key usage: symmetric encryption and asymmetric encryption.

Symmetric Encryption

Encryption and decryption use the same key.

TLS offers many symmetric algorithms such as RC4, DES, 3DES, AES, ChaCha20, etc. The first three are now considered insecure; AES and ChaCha20 are the widely used ones.

AES (Advanced Encryption Standard) supports 128‑, 192‑, or 256‑bit keys, offers high security and performance, and is the most popular symmetric algorithm.

Asymmetric Encryption

Symmetric encryption faces the "key exchange" problem: how to share the secret key securely.

Asymmetric encryption solves this with a pair of keys: a public key (publicly distributable) and a private key (kept secret).

The public key can encrypt data that only the private key can decrypt, and vice‑versa.

This allows secure key exchange: a server keeps its private key secret and distributes its public key; a client encrypts data with the public key, and only the server can decrypt it.

RSA is the most famous asymmetric algorithm, based on the difficulty of factoring large integers. Historically 1024‑bit keys were common, but today at least 2048‑bit keys are recommended.

Hybrid Encryption

Pure asymmetric encryption is too slow (RSA is orders of magnitude slower than AES), so TLS combines both methods.

During the handshake, the client obtains the server’s public key, generates a short session key, encrypts it with the public key, and sends it to the server. The server decrypts the session key with its private key, and thereafter both sides use symmetric encryption (e.g., AES) for data transfer.

The client obtains the server’s public key.

The client generates a random session key and encrypts it with the public key.

The server decrypts the session key with its private key.

Both client and server use the session key for symmetric encryption.

At this point confidentiality is solved, but integrity is still needed because an attacker could capture ciphertext, modify it, and replay it.

To guarantee integrity, TLS uses digest (hash) algorithms such as MD5, SHA‑1, SHA‑2. Modern TLS prefers SHA‑2 (e.g., SHA‑256) because the older algorithms are considered weak.

A hash function compresses arbitrary data into a fixed‑length, unique "digest" that acts like a digital fingerprint. It is one‑way: you cannot reconstruct the original data from the digest.

When a message is sent, the sender computes the digest and includes it. If any byte is altered, the digest changes, allowing the receiver to detect tampering.

Since a digest alone provides no confidentiality, it is usually combined with a secret key to form an HMAC (Hash‑based Message Authentication Code).

With confidentiality and integrity addressed, the next challenge is authentication of the communicating parties.

Digital signatures solve this: the sender hashes the message, then encrypts the hash with its private key. Anyone can verify the signature using the sender’s public key, confirming both identity and non‑repudiation.

However, public keys must be trusted. A malicious actor could publish a forged public key. Trust is established through Certificate Authorities (CAs), which sign digital certificates containing the public key, its owner’s identity, serial number, validity period, and other metadata.

Well‑known CAs (e.g., DigiCert, VeriSign, Let’s Encrypt) issue certificates of three validation levels: DV (domain‑validated), OV (organization‑validated), and EV (extended‑validated), with EV providing the highest assurance.

Trust chains work as follows: a subordinate CA’s certificate is signed by a higher‑level CA, and ultimately a Root CA signs its own certificate (self‑signed). Operating systems and browsers ship with a set of trusted root certificates; when a server presents its certificate chain, the client validates each signature up to a trusted root.

Root certificates are inherently trusted; if a root CA is compromised, the entire PKI is at risk, so absolute security cannot be guaranteed.

Certificates also enable one‑way or two‑way authentication. Typical websites use one‑way authentication (client verifies server). High‑security scenarios like online banking employ mutual authentication, where the client also presents a certificate.

In summary, HTTPS achieves security by combining TLS encryption, certificate‑based authentication, hash‑based integrity checks, and a hierarchical trust model managed by CAs, while acknowledging that no system can be absolutely safe.