What is HTTPS? How HTTP becomes encrypted

10 min readUpdated Oct 2026

HTTPS is HTTP sent inside a TLS connection. An https:// address tells the client to secure the connection before it sends any request: the server must prove it acts for the name in the address, and all HTTP communication with it gets confidentiality and integrity protection ^[1]. The HTTP itself stays the same. Requests and responses are the same messages, carried as TLS application data ^[2]. It is one of the terms in the SSL and TLS glossary.

Defined by: the https URI scheme in RFC 9110, section 4.2.2 ^[1]
Runs over: TLS: all HTTP data is sent as TLS application data ^[2]
Protects: the server's identity, and the confidentiality and integrity of what HTTP sends ^[1]
Leaves visible: the server name in the ClientHello, IP addresses and ports, and the length of the data ^[4]^[1]^[3]
Origin: an https:// address and its http:// twin are distinct origins ^[1]

HTTP vs HTTPS

The protocol for https:// addresses is still HTTP, with the same messages; what changes is what the network can do with them. Over http:// an on-path attacker between client and server can read a request and rewrite the reply. Over https:// TLS gives the traffic confidentiality and integrity: the attacker can see where the connection goes, but cannot read or change what it carries.

What changes between an http:// and an https:// address
Criterion	http://	https://
On the wire, in the test below	path, cookie and reply as readable text	the server name; path, cookie and reply encrypted
Reply changed on the way	accepted without a warning	refused by the client
Server proves its identity	no	yes, with a certificate checked against the name in the address ^[1]
Default port	80 ^[1]	443 ^[1]

The port is the visible part of the difference; why port 80 stays open on an HTTPS site is covered under the HTTPS port. Less visible is the change of origin. RFC 9110 gives https resources no shared identity with http: they are distinct origins with separate namespaces ^[1]. So http://example.com/ and https://example.com/ are two different origins.

How HTTP becomes HTTPS

HTTP becomes HTTPS when a TLS connection is put underneath it, in four steps:

The client opens a connection to the server. Nothing is encrypted yet.
It sends the TLS ClientHello and the TLS handshake starts ^[2]. In TLS 1.3 every handshake message after the server's reply, the ServerHello, is encrypted, the server certificate included ^[3].
The client checks that the identity in the certificate matches the host in the address, using the trust anchors it is configured with. This check prevents server impersonation by an on-path attacker, or by an attacker that controls name resolution ^[1].
Only when the handshake has finished does the first HTTP request go out, and all HTTP data is sent as TLS application data ^[2].

RFC 2818, HTTP Over TLS, set out steps 2 and 4; RFC 9110 now holds the rules. A client must secure its requests for an https resource before they are sent, and accept only secured responses ^[1]. When the certificate is not valid for the address, a browser must either get the user's confirmation or end the connection with a bad certificate error, and an automated client should end it ^[1]. The handshake itself, message by message, is in the TLS section of this site.

What HTTPS encryption protects: a test

We placed a relay between curl and a test server: a small program that passes every byte on and records it, which is the position of anyone on the network path. The client asked for /account?id=42 with the cookie session=s3cr3t, and the server answered Pay 100 to account 42. The server certificate for www.example.com came from a test authority, Example Test CA. Tools: curl 8.5.0 and OpenSSL 3.0.13; --resolve pointed the name at the test machine, and --cacert replaced curl's default CA file with the test authority's certificate ^[6].

Strings found in the bytes recorded by the relay, by protocol
Found in the recorded bytes	http://	https://, TLS 1.3	https://, TLS 1.2
`www.example.com`	1	1	1
`GET /account?id=42`	1	0	0
`session=s3cr3t`	1	0	0
`Pay 100`	1	0	0
`Example Test CA`	0	0	1

Over http:// the path, the cookie and the reply crossed the relay as text. Over https:// none of them did. The server name appeared once, inside the ClientHello, the first record the client sent. With TLS 1.2 the certificate also crossed in the clear, issuer name included; TLS 1.3 encrypts it ^[3].

Changing the reply, or answering for the name

Two more attacks went through over plain HTTP and failed at the client over HTTPS.

Two attacks on the reply and on the server identity, by protocol
Attack in the test	http://	https://
The relay changes the reply: `Pay 100` to `Pay 900` over http://, one bit flipped in each encrypted record over https://	curl printed `Pay 900 to account 42`, exit code 0	curl stopped with `decryption failed or bad record mac`, exit code 56
Another server answers for `www.example.com`, over https:// with a certificate it signed itself	curl printed that server's reply, exit code 0	curl stopped with `SSL certificate problem: self-signed certificate`, exit code 60

$ curl -sS --cacert ca.pem --resolve www.example.com:8444:127.0.0.1 'https://www.example.com:8444/account?id=42'
curl: (60) SSL certificate problem: self-signed certificate

The bit flip is the integrity property at work: data sent after the handshake cannot be modified without detection ^[3]. The second refusal is authentication: curl verified against the test authority alone, and the other server's certificate did not lead back to it ^[1].

Is HTTPS secure?

HTTPS is secure in a defined, narrow sense. RFC 9110 calls an https connection secured when the server has been authenticated as acting for the name in the address, and all HTTP communication with it has confidentiality and integrity protection ^[1]. Each of the three guarantees showed up in the test above.

Is HTTPS secure?
Guarantee of a secured connection	In the test above
Confidentiality: once the connection is established, data is visible only to the endpoints ^[3]	The path, the cookie and the reply never appeared on the relay as text
Integrity: data cannot be modified by attackers without detection ^[3]	The flipped bit made curl stop
Server authentication: the client checks the server's identity against the origin in the address ^[1]	The impostor with a self-signed certificate was refused

The security of HTTPS ends there. The three guarantees describe the connection and the server's identity; the definition in RFC 9110 says nothing about the owner of the site, the security of the server itself, or the device the visitor uses ^[1]. Because the data reaches the endpoints in full ^[3], an encrypted HTTPS connection protects a request on its way to the site, not what the site does with it afterwards. What the connection still shows to the network is listed under What HTTPS does not hide.

What HTTPS does not hide

HTTPS encryption covers what HTTP sends between the two ends of the connection, and nothing beyond that:

The server name. It sits in the Server Name Indication of the ClientHello. RFC 9849 calls plaintext SNI perhaps the most sensitive information left unencrypted in TLS 1.3, and defines Encrypted Client Hello to protect it ^[4]. SNI has its own entry in this glossary.
Addresses and ports. TCP and the port number are outside the secured communication ^[1], so the path sees which IP address and port each connection goes to.
Sizes. TLS does not hide the length of the data it transmits; endpoints can pad records to obscure it ^[3].
Anything at the other end. Data sent after the handshake is visible only to the endpoints ^[3]. Whoever terminates TLS, the server or a CDN edge in front of it, reads the request in full.

Moving a site from HTTP to HTTPS

Because http:// and https:// are distinct origins ^[1], moving a site to HTTPS is a change of address. Three things have to move with it.

A certificate for every name the site answers on. The client checks the name in the address against it ^[1]; a name the certificate does not cover fails that check.
A redirect from each http:// address to its https:// twin, so old links and typed addresses arrive encrypted. The redirect itself travels over plain HTTP. HTTP Strict Transport Security lets a browser that has seen the policy skip it and go straight to https:// on later visits.
Cookies with the Secure attribute. Cookies apply to every origin with the same host, http:// included ^[1]. A cookie with the Secure attribute is sent only over a secure channel. RFC 6265 adds that Secure protects only the cookie's confidentiality: an active attacker can still overwrite it from an insecure channel ^[5].

HTTPS on Bridge CDN

On Bridge CDN the HTTPS connection a visitor opens ends at the edge. Bridge CDN terminates TLS and delivers the page, which is why the certificate can live there. Bridge SSL is the certificate layer of Bridge CDN: TLS certificates are issued and renewed automatically where your site is served, and it works only for hostnames Bridge CDN serves. There is no certificate file on your machine, and Bridge SSL has no certificate upload.

FAQ

What is the difference between HTTP and HTTPS?

HTTPS is HTTP sent over TLS. Over HTTP anyone on the network path can read requests and change replies; over HTTPS the server proves its identity with a certificate, and the content is encrypted and protected against changes. An http:// and an https:// address of one site are also distinct origins. ^[2]^[1]

Does HTTPS encrypt the URL?

HTTPS does encrypt the path and query, along with headers, cookies and the body, because all HTTP data travels as TLS application data. The hostname is not: it goes in the ClientHello in plaintext unless Encrypted Client Hello is used, and the IP address and port stay visible either way. ^[2]^[4]^[1]

Is HTTPS the same as SSL?

No. HTTPS is HTTP, the web protocol, running over TLS, the security layer underneath it. SSL is the old name of that layer, and TLS is its successor; the SSL vs TLS entry of this glossary explains why both names are still in use. ^[2]

Can someone on my network read HTTPS traffic?

Not the content: after the handshake it is visible only to the two endpoints and cannot be changed without detection. They can still see the server name in the ClientHello, the IP address and port, and how much data moves. ^[3]^[4]^[1]

Sources

RFC 9110, HTTP Semantics: §4.2.1, §4.2.2 (https URI scheme), §4.3.3 (https origins), §4.3.4 (https certificate verification).
RFC 2818, HTTP Over TLS: §2.1.
RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3: §1, §1.2.
RFC 9849, TLS Encrypted Client Hello: §1.
RFC 6265, HTTP State Management Mechanism: §4.1.2.5 (the Secure attribute).
curl manual: options --resolve and --cacert.