HTTPS (HyperText Transfer Protocol Secure) is HTTP with an added security layer called TLS (Transport Layer Security). When you see the padlock icon in a browser's address bar, TLS is encrypting the data travelling between your browser and the web server, preventing eavesdropping and tampering.

What is the difference between HTTP and HTTPS?

HTTP (HyperText Transfer Protocol) is the protocol used to transfer web pages between a server and a browser. By default, HTTP sends all data — including passwords, form entries, and cookies — in plaintext. Anyone on the same network (a café Wi-Fi, for example) using a packet sniffer can read every byte.

HTTPS adds TLS encryption on top of HTTP. The same data is now encrypted before transmission, so even if an attacker intercepts the packets, they see only ciphertext — meaningless without the decryption key.

Feature HTTP HTTPS
Port 80 443
Data in transit Plaintext — readable by anyone Encrypted — unreadable without the key
Padlock shown? No Yes
Authentication None Server's identity verified by a certificate
Suitable for Non-sensitive public content Any site handling logins, payments, personal data

What is TLS?

TLS (Transport Layer Security) is the cryptographic protocol that provides the security in HTTPS. It is the successor to SSL (Secure Sockets Layer) — you may see "SSL" used informally, but all modern connections use TLS 1.2 or TLS 1.3.

TLS achieves three security goals:

Goal What it means How TLS achieves it
Confidentiality Data cannot be read by eavesdroppers Symmetric encryption of data in transit
Integrity Data cannot be tampered with undetected Message Authentication Codes (MACs)
Authentication You are talking to the real server, not an impostor Digital certificates signed by a Certificate Authority

All three properties are needed simultaneously. Encryption without authentication still allows a man-in-the-middle attack; authentication without encryption still exposes the content.

How does a TLS connection start? (the TLS handshake)

Before any page data is exchanged, the browser and server perform a TLS handshake to agree on how to communicate securely:

  1. ClientHello — the browser tells the server which TLS version and cipher suites (encryption algorithms) it supports.
  2. ServerHello — the server picks a cipher suite and sends its digital certificate.
  3. Certificate verification — the browser checks the certificate is valid, unexpired, and signed by a trusted Certificate Authority (CA).
  4. Key exchange — browser and server use asymmetric (public-key) cryptography to agree on a shared session key without transmitting it openly.
  5. Encrypted session — all further data (the actual web page) is encrypted using the session key with a fast symmetric cipher (e.g. AES-256).

Steps 1–4 use slow asymmetric encryption just once. Step 5 uses fast symmetric encryption for all data. This combination is both secure and efficient.

What is a digital certificate?

A digital certificate (also called an SSL/TLS certificate) is an electronic document that proves a website's identity. It contains:

  • The website's domain name (e.g. aitutors.me)
  • The website's public key
  • The issuing Certificate Authority (CA)
  • The certificate's validity period
  • A digital signature from the CA

A Certificate Authority (CA) is a trusted third party (such as Let's Encrypt, DigiCert, or Comodo) that verifies the applicant owns the domain and then digitally signs the certificate. Browsers come pre-loaded with a list of trusted CAs.

When your browser sees a certificate signed by a trusted CA, it knows: (a) the public key belongs to the domain, and (b) the CA has verified this. A certificate signed by an unknown CA, or a mismatched domain, triggers a browser warning — "your connection is not private".

What is a man-in-the-middle attack and how does HTTPS prevent it?

In a man-in-the-middle (MitM) attack, an attacker intercepts communications between two parties, reading and potentially altering data without either party knowing.

Without HTTPS:

  • User sends login credentials to bank.co.uk.
  • Attacker intercepts the plaintext packet and reads the password.

With HTTPS:

  • The TLS handshake authenticates the server's certificate.
  • An attacker who intercepts packets sees only ciphertext.
  • An attacker who tries to impersonate the server cannot produce a valid certificate for bank.co.uk signed by a trusted CA.

HTTPS does not prevent the attacker from intercepting packets — it makes those packets useless because they are encrypted and the server's identity has been verified.

Why should every website use HTTPS even if it doesn't handle passwords?

Google and other search engines penalise HTTP-only sites in rankings. Browsers mark HTTP pages as "Not Secure". But beyond these practical pressures, there are technical reasons:

  • Cookies can be stolen on HTTP (session hijacking).
  • Content injection — an attacker on the same network can insert adverts or malicious scripts into HTTP pages.
  • HTTP/2 (the faster version of HTTP) is only available over HTTPS in most browsers.
  • User trust — the padlock icon signals professionalism and security to visitors.

Even a site that only displays read-only public information should use HTTPS, because the network path between the user and the server is not controlled by the site owner.

Frequently asked questions

What is the difference between TLS and SSL?

SSL (Secure Sockets Layer) was the original protocol, developed by Netscape in the 1990s. It had security vulnerabilities and was deprecated. TLS is its successor and all modern connections use TLS 1.2 or 1.3. The terms "SSL" and "SSL/TLS" are still widely used in everyday speech because of historical familiarity — but technically, SSL is dead. At GCSE, you may encounter both terms; know that they refer to the same conceptual purpose (securing web traffic), with TLS being the current standard.

How does asymmetric encryption help during the TLS handshake?

During the handshake, the browser uses the server's public key (from the certificate) to encrypt a secret value. Only the server's private key can decrypt it. This means the two parties can establish a shared session key without ever transmitting it over the network — an eavesdropper who records the handshake cannot derive the session key. This technique is called the key exchange and it is why TLS can be secure even on a network where every packet is intercepted.

Can HTTPS be broken?

TLS itself, when implemented correctly, is not practically breakable with current technology. However, attacks do occur through weaker points: stolen private keys (the server's private key leaks), misconfigured servers (using old TLS 1.0), social engineering (tricking users into accepting a fraudulent certificate), and compromised CAs (a CA signs a fraudulent certificate). Regularly updated, well-configured HTTPS remains the strongest practical protection for web traffic.

Does HTTPS guarantee a website is trustworthy?

No — HTTPS only guarantees that the connection is encrypted and that the server owns the certificate. It says nothing about whether the site is legitimate or safe. A phishing site can have a valid HTTPS certificate for its fake domain. The padlock means "this connection is secure", not "this website is honest". Always verify you are on the genuine domain before entering sensitive information.


Explore network security, encryption, and every GCSE cybersecurity topic with Professor Turing at aitutors.me.