All guides

HTTP vs HTTPS: What's the Difference?

If you're studying for CompTIA Network+ or Security+, HTTP vs HTTPS looks like a one-letter difference — but that "S" is the whole point. It's where ports, TLS, certificates and several classic attacks all show up.

The short answer

HTTP (Hypertext Transfer Protocol) is the language browsers and web servers use to exchange pages — but it sends everything in plain text over TCP port 80. HTTPS is the exact same protocol running inside a TLS-encrypted tunnel over TCP port 443. The "S" stands for Secure, and it adds three things: confidentiality (no one can read it), integrity (no one can change it undetected), and authentication (you're really talking to the server you think you are).

Think of HTTP as a postcard — every router it passes can read it — and HTTPS as the same message sealed in a tamper-proof envelope.

What is HTTP?

HTTP defines how a client requests a resource (GET /login) and how the server responds (status codes like 200 OK or 404 Not Found). It works perfectly well — but it has zero security. Because the data is plain text, anyone in the path can:

  • Sniff it — read usernames, passwords, session cookies and form data with a packet capture.
  • Tamper with it — a man-in-the-middle (MITM) can inject or rewrite the response (think malicious ads or fake login forms).
  • Spoof the server — you have no proof the host answering on port 80 is the real one.

That's why plain HTTP is now treated as a finding for anything sensitive, and browsers mark it "Not secure."

What is HTTPS?

HTTPS is HTTP over TLS (Transport Layer Security — the modern successor to SSL). Before any page data flows, the client and server complete a TLS handshake: the server presents an X.509 certificate signed by a trusted Certificate Authority (CA), both sides agree on a cipher and derive a shared session key, and only then does the actual HTTP traffic ride through, encrypted.

That handshake is what powers the padlock in the address bar. It means the connection is encrypted and the certificate chains up to a CA your browser trusts — so the data is private, unmodified, and coming from the named server.

HTTP vs HTTPS, side by side

HTTPHTTPS
EncryptionNone — plain textEncrypted with TLS
Default portTCP 80TCP 443
TransportTCPTCP (TLS on top)
Certificate / CANot usedX.509 cert signed by a CA
ConfidentialityNoYes
IntegrityNo (tamperable)Yes (detects tampering)
Server authenticationNoYes
Browser label"Not secure"Padlock

The certificate and the CA chain

The certificate is the trust anchor. When a server sends its X.509 certificate, the browser checks that it's signed by a CA it already trusts, that it matches the domain, and that it hasn't expired or been revoked. If any check fails you get the scary full-page warning — that's the browser refusing to vouch for the connection.

One trap the exam (and real life) loves: a valid certificate proves the connection is secure, not that the site is honest. A phishing site can buy a perfectly valid certificate and show a padlock. So "encrypted" is not the same as "trustworthy" — judge the domain name, not just the lock.

HSTS: forcing HTTPS

Even on an HTTPS site, the first request often starts as plain http:// (you typed the domain, clicked an old link). That gap is what SSL stripping abuses — a MITM keeps the user on HTTP while talking HTTPS to the server, silently downgrading the connection.

HSTS (HTTP Strict Transport Security) closes that gap. It's a response header (Strict-Transport-Security) that tells the browser: for this domain, only ever use HTTPS, for this long. After the first visit, the browser upgrades every request to HTTPS itself and refuses to fall back — defeating downgrade and SSL-stripping attacks. Sites can also submit to the HSTS preload list so the rule applies even on the very first visit.

Which one shows up on the exam?

On Network+, expect the straight port mapping — HTTP = TCP 80, HTTPS = TCP 443 — and the fact that HTTPS is HTTP secured by TLS. On Security+, the angle is why plaintext is dangerous and how to fix it: sniffing and MITM on HTTP, the role of PKI / certificates / CAs, SSL stripping as a downgrade attack, and HSTS as the mitigation. Remember that HTTPS doesn't encrypt everything end to end — the destination IP and (in most current setups) the domain name via SNI are still visible to anyone watching the wire; what's hidden is the URL path, headers and body.

Common gotchas

  • HTTPS uses TLS, not SSL. Every SSL version is deprecated and broken; the "S" today is TLS 1.2 or 1.3. (The "SSL certificate" you buy is really a TLS certificate.)
  • Padlock is not a trust badge. It certifies encryption, not the operator's intentions.
  • HTTP/3 changes the transport. HTTP/1.1 and HTTP/2 ride TCP, but HTTP/3 runs over QUIC on UDP — so "web traffic is always TCP" is no longer strictly true, even though HTTPS still means TLS-grade security.

Lock it in

HTTP vs HTTPS only sticks once you can fire back the port numbers and the acronyms — TLS, CA, X.509, MITM, HSTS — without pausing. That kind of instant recall comes from quizzing yourself, not re-reading. Drill these protocols and the acronyms hanging off them with active recall and spaced repetition (SM-2) in exam mode, and the comparison becomes automatic when a port-and-protocol question lands on test day.

Get the App