HTTPS and TLS

What it means

HTTPS is HTTP carried over a secure transport, normally TLS. A correctly authenticated TLS connection aims to protect application data from eavesdropping and modification between its TLS endpoints. The browser verifies the server's claimed identity before treating the connection as authenticated. The current TLS 1.3 specification is RFC 9846 (July 2026), which obsoletes the earlier RFC 8446. TLS 1.3 Service identity

HTTPS does not make a site truthful or free from malicious scripts, and it does not protect data once an authorized endpoint or browser is compromised. Encryption in transit is only one part of web security.

Try it

Example — follow the protection boundary. This is a simplified conceptual path, not a network capture or a live certificate test.

Browser -- TLS-secured connection --> Public TLS endpoint
                                         |
                                         +--> Web app / origin
                                              (separate connection)

The browser checks the TLS certificate for www.example.com when visiting https://www.example.com/guide. After negotiation, HTTP method, path, headers and body travel as protected application data between those TLS endpoints. If a reverse proxy terminates TLS, the proxy can read HTTP and may send it to its upstream over another connection. That connection needs its own security decision: public HTTPS does not prove proxy-to-origin TLS.

What TLS actually does

1. Client and server negotiate cryptographic parameters and establish keys during the TLS handshake. Validating the peer is essential; encryption to the wrong peer is not the intended security property. Handshake
2. The browser checks the authenticated service name and certificate chain according to its trust policy. Certificate validity is not an endorsement of a website's business practices. Certificate identity
3. Protected application records carry HTTP. A server can still return 404, 502 or malicious content over a perfectly working HTTPS connection.
4. The connection ends at a TLS peer. When a CDN or reverse proxy is involved, there may be more than one TLS connection or an upstream leg using a different transport.

What HTTPS does not hide

The destination IP address and traffic timing/size may remain observable. DNS lookups and some handshake metadata, including server-name information in configurations without encrypted ClientHello, may reveal the destination name. Do not assume HTTPS offers anonymity or hides all metadata. The exact visibility depends on protocols, deployment and optional protections. TLS protocol

Mixed-content restrictions protect a secure page from loading certain resources insecurely, but site operators still need secure dependencies, access control, patching and safe storage of credentials. Do not suppress certificate warnings or disable TLS verification in order to make a health check pass.

When it matters

For certificate errors, first check the exact hostname, expiry, chain, trusted issuer and correct TLS endpoint/SNI configuration. Test the public route, not just an origin IP with a different name. To analyze site availability, separate transport handshake success from the HTTP status returned afterward. For a proxy, confirm independently whether and how its upstream connection is protected.

In practice

HTTPS is the correct default for a public website, but keep the roles separate: HTTP request and response explains the application message; Reverse proxy explains where TLS may terminate; HTTP 502 troubleshooting begins after an intermediary fails to obtain an acceptable upstream response.