HTTPS and TLS

HTTPS is HTTP carried through a TLS-protected connection. The URL starts with https://. The port defaults to 443 instead of 80. Everything else you learned about methods, headers, status codes, and bodies still applies.

TLS gives you three properties:

• Encryption keeps message contents private in transit.
• Integrity detects tampering on the way.
• Server authentication lets the client verify the certificate matches the hostname.

Let’s see the handshake. Run curl in verbose mode:

curl -vI https://flaviocopes.com/ 2>&1 | head -20

You should see lines about TLSv1.3, certificate verification, and SSL connection using.... Only after TLS succeeds does the HTTP request go out. The status line still reads HTTP/2 200 or similar once the connection is secure.

The HTTP concepts stay familiar. You still use URLs, methods, headers, status codes, and bodies. TLS wraps the transport. It does not change what a GET or POST means.

HTTPS does not prove a site is honest or bug-free. It protects the connection to the authenticated host. A phishing site can have a valid certificate too. Application security remains your responsibility: validate input, escape output, patch dependencies.

Use HTTPS everywhere, not only on login pages. An attacker can modify an unprotected HTTP page to steal credentials before the visitor reaches your secure form. Mixed content (HTTPS page loading HTTP scripts) weakens the whole page.

Be careful with self-signed certificates in development. Browsers warn because they cannot verify the issuer. That is expected locally. Never ship self-signed certs to production users.

Try this: compare curl -I http://flaviocopes.com/ with curl -I https://flaviocopes.com/. Most production sites redirect HTTP to HTTPS. Notice the Location header on the redirect response.