Why HTTPS Matters: Understanding SSL/TLS and Secure Web Communication

Why Do We Need HTTPS?

There are three main reasons:

Privacy : All information is transmitted encrypted, preventing third parties from eavesdropping. Plain HTTP would expose passwords and personal data to interception.

Integrity : If data is tampered, the receiver can detect the alteration, guaranteeing that transmitted data remains unchanged.

Authentication : Servers present certificates issued by a Certificate Authority (CA) to prove their identity, preventing impersonation. In rare cases, such as some banking systems, the client also presents a certificate.

What Is HTTPS? What Are SSL/TLS?

HTTP (HyperText Transfer Protocol) is a clear‑text protocol that operates at the application layer of the OSI model, making it vulnerable to interception and tampering.

SSL (Secure Socket Layer) was originally designed by Netscape for secure web transmission. It sits between the TCP transport layer and the application layer.

The IETF later standardized SSL as TLS (Transport Layer Security). TLS 1.0 appeared in 1999, and TLS 1.3 was released in March 2018.

HTTPS (HyperText Transfer Protocol Secure) is simply HTTP layered over SSL/TLS, i.e., HTTPS = HTTP + SSL/TLS , where the final “S” stands for “Secure”.

SSL/TLS Development History

Modern browsers no longer use SSL; they use TLS. SSL 3.0 was deprecated in 2015.

>99.5% of browsers now support TLS 1.2 or TLS 1.3; less than 1% still use TLS 1.0/1.1.

TLS 1.2 remains the mainstream protocol (as of early 2020), with TLS 1.3 expected to become dominant.

Major browsers are phasing out TLS 1.0/1.1: Chrome 72 stopped recommending it, Chrome 81 will drop support; Firefox, Edge, Safari will also remove support in 2020.

Sites still using TLS 1.0/1.1 must upgrade to TLS 1.2 or TLS 1.3.

How SSL/TLS Works

Understanding SSL/TLS requires knowledge of two encryption algorithms:

Symmetric encryption : Both parties use the same key. It is fast but requires secure key distribution. Examples include AES and DES.

Asymmetric encryption : Uses a public key and a private key. The public key can be shared openly, while the private key remains secret. Commonly used for SSH keys and RSA.

SSL/TLS combines both: the handshake uses asymmetric encryption to exchange a secret, then symmetric encryption secures the data transfer.

After TCP connection, the client sends ClientHello containing supported TLS versions, cipher suites, session ID (optional), and a random value ( client‑random ).

The server replies with ServerHello , selecting the TLS version, cipher suite, its own random value ( server‑random ), and a session ID.

The server sends its certificate (including the public key) signed by a trusted CA. Optionally, the server may request a client certificate.

The client verifies the server certificate using the CA’s root certificate, then generates a pre‑master secret, encrypts it with the server’s public key, and sends it to the server.

Both sides compute the master secret from pre‑master , client‑random , and server‑random . This secret is used to derive symmetric keys for encryption and MAC.

Both client and server send a “Finished” message encrypted with the newly derived keys. Once both are verified, secure communication begins.

The trust chain works because browsers ship a list of trusted root CAs (e.g., GlobalSign, VeriSign). When a server presents a certificate signed by an intermediate CA, the browser verifies the chain up to a trusted root. If any link is altered, the signature verification fails, indicating a possible man‑in‑the‑middle attack.

In summary, the TLS handshake quickly (within a few hundred milliseconds) establishes a shared master secret using asymmetric cryptography, after which all subsequent traffic is encrypted with efficient symmetric algorithms, providing confidentiality, integrity, and authentication.