HTTP (Hypertext Transfer Protocol) is the protocol a browser uses to ask a server for a page or data, and that the server uses to reply. It works in a request–response model and is stateless — it treats each request on its own, with no memory of previous ones. HTTPS (HTTP Secure) is the same protocol, but carried through an encrypted TLS (Transport Layer Security) tunnel. TLS adds confidentiality, data integrity, and proof of the server’s identity. HTTP uses port 80 by default, and HTTPS uses port 443. The whole difference is that HTTPS wraps plain HTTP in a layer of encryption.

What is HTTP?

HTTP sets out how a client (usually a browser) asks for a resource and how a server responds. It is stateless: each request is independent, and the fact that you are logged in or have something in your cart is remembered by extra mechanisms — cookies, authorization headers, tokens. A single HTTP message has a start line, headers, and an optional body (the actual content).

HTTP methods

GET — retrieve a resource (no side effects).
POST — submit data for processing.
PUT — create or replace a resource.
PATCH — partially modify a resource.
DELETE — remove a resource.
HEAD — like GET, but returns headers only, no body.
OPTIONS — check which methods are allowed (including CORS preflight).
CONNECT — establish a tunnel (typically to a proxy for HTTPS).

HTTP status codes

1xx — informational (e.g. 101 Switching Protocols).
2xx — success (200 OK, 201 Created, 204 No Content).
3xx — redirection (301 Moved Permanently, 302 Found, 304 Not Modified).
4xx — client-side errors (400, 401, 403, 404, 429 Too Many Requests).
5xx — server-side errors (500, 502, 503, 504).

How does HTTPS differ from HTTP?

HTTPS is HTTP carried over a connection secured with TLS (the successor to the older SSL). TLS adds three things that plain HTTP lacks:

Confidentiality — the content is encrypted, so someone listening in on the network (on public Wi-Fi, at an ISP, or at an intermediary) cannot read the HTTP body or headers, including cookies and login credentials.
Integrity — if the data is altered along the way, it is detected (MAC/AEAD mechanisms). That makes it hard for an outsider to inject their own content.
Server identity — an X.509 certificate signed by a Certificate Authority (CA) confirms you are connecting to the right domain, not an impostor server. That hinders a man-in-the-middle attack, where an attacker slips in between you and the server.

In plain HTTP everything travels in cleartext: the URL with its path and query parameters, the headers, cookies, and body. Anyone in the path can read or change it. In HTTPS, an outside observer mainly sees the destination IP, port 443, approximate packet sizes and timing, and the hostname (via the SNI field in the handshake and via DNS queries — unless encrypted DNS and Encrypted Client Hello are used). The full URL path, parameters, and the content itself stay encrypted.

How does the TLS handshake work?

Before the first HTTP request is sent, both sides agree on the rules of encryption in the so-called TLS handshake:

The client sends a ClientHello with the supported TLS version, a random value, and a list of cipher suites.
The server replies with a ServerHello, sends its certificate, and picks a cipher suite.
The sides agree on a session key using asymmetric cryptography (e.g. ECDHE, which gives forward secrecy — traffic captured today cannot be decrypted even if the key is stolen later).
From then on the communication is encrypted symmetrically with a shared session key — much faster than asymmetric cryptography.

TLS 1.3 cuts the handshake to a single round trip (and to 0-RTT on session resumption), drops legacy ciphers, and mandates forward secrecy. When a certificate has expired, the cipher is weak, or the hostname does not match, the browser shows a security error.

What is HSTS?

HSTS (HTTP Strict Transport Security) is a response header (Strict-Transport-Security) that tells the browser: for a set period, connect to this domain over HTTPS only. Once it is remembered, the browser rewrites http:// to https:// on its own, and the HTTP request never even leaves the device. That is how HSTS protects against downgrade and SSL-stripping attacks, where an attacker tries to push the victim back to unencrypted HTTP. Domains on the HSTS preload list are forced to HTTPS on the very first connection.

HTTP/1.1 vs HTTP/2 vs HTTP/3 (QUIC)

The logic of HTTP itself (methods, codes, headers) is stable, but the way data is carried has changed over the years:

HTTP/1.1 — a textual protocol with persistent connections (keep-alive) and the Host header (many domains per IP). It has a head-of-line blocking problem: a stuck request blocks the ones behind it. Browsers work around this by opening several parallel TCP connections to the server.
HTTP/2 — binary framing, multiplexing (many streams over a single TCP connection), and header compression (HPACK). It removes blocking at the HTTP level, but a lost TCP packet still stalls all streams (blocking at the transport level).
HTTP/3 — runs over QUIC (a UDP-based transport with built-in TLS 1.3). Its streams are independent, so transport-level blocking disappears. Setting up the connection and the encryption fits into a single handshake (a faster start), and connection migration keeps the session alive across a network change (e.g. Wi-Fi → LTE). HTTP/3 is always encrypted.

Why do HTTP/HTTPS matter for security and network monitoring?

HTTP/HTTPS is the most common application traffic on the network today. That is exactly why it is both a primary target for attacks and an important data (telemetry) source for SOC teams and NDR/IDS systems.

Attack surface — injections (SQLi, XSS), API abuse, web shells, and application-layer attacks all ride over HTTP. Unencrypted HTTP lets an attacker capture login data and session cookies and swap out content on the fly.
Visibility vs encryption — HTTPS protects the user but limits insight into content for monitoring. Detection therefore relies on layer-4 metadata, analysis of the SNI field and certificates, handshake fingerprints (e.g. JA3/JA4), proxy logs, and — where it is permitted and controlled — TLS decryption at a gateway.
Anomaly detection — unusual User-Agent headers, suspicious SNI domains, self-signed certificates, C2 traffic (beaconing) hidden inside HTTPS, bursts of 4xx/5xx codes, or a sudden spike of traffic on port 443 are typical signals for NDR.
Configuration hygiene — enforcing HTTPS (redirects, HSTS), disabling old TLS versions and weak ciphers, valid certificates, and watching their expiry date reduce the risk of downgrade and session hijacking.

Learn more

QUIC — QUIC often runs over UDP and uses TLS 1.3 to secure data, like HTTPS does.
REST API — REST APIs commonly use HTTP methods and status codes for client-server communication.
Encrypted Traffic Analysis (ETA) — ETA helps inspect HTTPS traffic patterns when payloads are encrypted.
Content Security Policy (CSP) — CSP is delivered via HTTP headers to control what content a page may load.
API Security — API security protects HTTP-based interfaces from misuse, interception, and abuse.
Cross-Site Request Forgery (CSRF) — CSRF exploits authenticated HTTP requests sent by a victim’s browser.
WAF (Web Application Firewall) — A WAF filters HTTP and HTTPS requests to block common web attacks.
Scrubbing Center — Scrubbing centers can remove volumetric attacks that target HTTP and HTTPS services.

HTTP / HTTPS

Protocol a browser uses to fetch web resources via request–response (port 80). HTTPS is the same protocol inside a TLS tunnel (port 443): confidentiality, integrity, server identity.