TLS & HTTPS

Its job in the system

HTTPS combines HTTP with a protected connection. TLS is the protocol family behind that protection, and the current TLS 1.3 specification is RFC 9846. Its purpose is to protect communication against eavesdropping and tampering while authenticating the communicating endpoint as required by the application’s trust model.

How it works

During connection establishment, endpoints negotiate cryptographic parameters and establish shared secrets. In common web use, the browser validates a server certificate against the requested name and its trust configuration. After establishment, encrypted records protect the application data on that connection. This does not mean intermediate networks stop handling IP addresses or carrying the packets.

Protection has a scope. A TLS connection terminates at an endpoint, which may be a website’s server or an authorised front-end service such as a content delivery provider. That endpoint can process the decrypted request. Other traffic characteristics can remain observable, and device or application behaviour can disclose information outside the encrypted channel.

What it connects to

TLS relies on network connectivity and sits alongside the transport and application protocols. HTTP/3 integrates TLS-based cryptography with QUIC rather than simply placing a conventional TLS record layer above TCP. DNS helps find a service, but a DNS answer alone does not perform the certificate checks used by the browser.

Different places, different designs

Protocol versions, certificate management, enterprise configurations, and endpoint arrangements vary. We explain the common website case, not every possible TLS deployment. Encryption is one part of security and privacy; it does not determine a website’s honesty, data-retention practices, or the safety of downloaded content.