HTTPS (Hypertext Transfer Protocol Secure) is HTTP carried over an encrypted and authenticated TLS connection. Among internet protocols it is the standard way to deliver web content securely: it keeps requests and responses confidential, detects any tampering in transit, and proves the identity of the server through a certificate issued for its domain name.
HTTPS is not a separate application protocol. The HTTP messages are unchanged; only the transport underneath is secured. By default it uses port 443 and the https URL scheme, and it now carries the large majority of web traffic, as browsers mark plain HTTP pages as not secure and many web platform features work only in secure contexts.
How HTTPS secures a connection
Before any HTTP data is exchanged, client and server perform a TLS handshake. They agree on a protocol version and cipher suite, run an ephemeral key exchange to derive shared session keys, and the server presents its certificate chain to prove that it controls the requested name.
With TLS 1.3, a full handshake needs one round trip, and resumed connections can send data immediately with 0-RTT, at the cost of possible replay for that early data. After the handshake, every record is protected with authenticated encryption such as AES-GCM or ChaCha20-Poly1305.
| Property | Protected | Explanation |
|---|---|---|
| Confidentiality of content | Yes | Paths, headers, cookies and bodies are encrypted |
| Integrity | Yes | Modified records fail authentication and are rejected |
| Server authentication | Yes | Certificate binds the key to the domain name |
| Hidden destination | Partly | IP address is visible; hostname leaks via SNI unless encrypted |
| Trustworthy content | No | A phishing site can have a valid certificate |
| Traffic patterns | No | Timing and sizes remain observable |
Certificates and trust
The trust model of HTTPS rests on certificate authorities (CAs) that browsers and operating systems include in their root stores. A CA issues an X.509 certificate only after the requester proves control of the domain, and the browser verifies the chain, the name, the validity period and the revocation status.
| Level | What is verified | Typical use |
|---|---|---|
| Domain validated (DV) | Control of the domain name only | Most websites, automated issuance |
| Organization validated (OV) | Domain plus the legal organization | Business sites and APIs |
| Extended validation (EV) | Stricter organization checks | Rarely shown differently by browsers today |
The ACME protocol automates issuance and renewal, which made free DV certificates common. Every publicly trusted certificate must also appear in Certificate Transparency logs, letting domain owners detect misissued certificates. Maximum certificate lifetimes are being shortened in stages, which makes automated renewal effectively mandatory.
HTTPS compared with HTTP and other secure transports
HTTPS works with every version of HTTP, but the transport stack differs. The table shows how the main variants relate.
| Variant | Transport | Security | Note |
|---|---|---|---|
| HTTP over port 80 | TCP | None | Readable and modifiable on the path |
| HTTPS with HTTP/1.1 | TCP plus TLS | TLS 1.2 or 1.3 | One request at a time per connection |
| HTTPS with HTTP/2 | TCP plus TLS | TLS 1.2 or 1.3 | Multiplexed streams, negotiated via ALPN |
| HTTPS with HTTP/3 | QUIC over UDP | TLS 1.3 built into QUIC | No TCP head-of-line blocking |
In practice, HTTP/2 and HTTP/3 are deployed only over encrypted connections by browsers, so modern performance features are tied to HTTPS. QUIC goes further and encrypts most of its transport headers as well.
Deploying HTTPS correctly
A sound deployment covers more than installing a certificate. Redirects, headers and content must all ensure that no part of a site is loaded over plain HTTP.
| Element | Recommended setting | Purpose |
|---|---|---|
| Protocol versions | TLS 1.2 and 1.3 only | Removes weak legacy protocols |
| HTTP to HTTPS redirect | 301 or 308 on every URL | Moves all visitors to the secure scheme |
| Strict-Transport-Security | max-age of at least one year | Prevents downgrade on later visits |
| Mixed content | All subresources over HTTPS | Avoids blocked scripts and warnings |
| Cookies | Secure flag on all session cookies | Stops cookies from leaking over HTTP |
| OCSP stapling and renewal monitoring | Enabled and alerted | Faster validation, no surprise expiry |
The HSTS preload list goes one step further: domains on it are treated as HTTPS-only by browsers even on the very first visit. Removal from the list takes months, so it should be used only when every subdomain supports HTTPS.
Common misconceptions and failures
The padlock icon is often misread as a sign that a site is safe. It only states that the connection is encrypted and that the server controls the name shown.
- Expired certificates remain a leading cause of outages when renewal is manual.
- Incomplete certificate chains work in some browsers through caching but fail in others and in API clients.
- TLS termination at a proxy leaves traffic from the proxy to the origin unencrypted unless it is secured separately.
- Disabling certificate verification in code, often added during testing, removes authentication entirely.
- Assuming HTTPS slows pages down: with TLS 1.3, session resumption and HTTP/2 or HTTP/3, the overhead is small.
Stripped to the essentials
HTTPS is ordinary web traffic sent in a sealed, tamper-proof envelope. Anyone along the way can see that an envelope is traveling and roughly where it goes, but not what is inside, and they cannot change it without being noticed.
The envelope also carries a stamp that proves it came from the website you meant to visit. It protects the delivery, not the honesty of the sender, so a dishonest website can still use HTTPS.
Where it is applied
A city library runs an online catalog where members log in to renew books. The site still answers on plain HTTP, and members using public Wi-Fi in cafes could have their session cookies captured. The IT team introduces HTTPS with automated certificate renewal through ACME.
All HTTP URLs now redirect permanently to HTTPS, session cookies receive the Secure flag, and an HSTS header with a one-year max-age is added after two weeks of testing. Mixed-content warnings from old cover images are fixed by serving them from the same secure host. Members can now log in safely on any network, and the catalog becomes eligible for HTTP/2, which also shortens page load times.