How TLS Protects Connections: Handshakes, Identity and Limits

Transport Layer Security (TLS) protects a network connection against eavesdropping and undetected modification, and normally authenticates the server to the client. HTTPS is HTTP carried over TLS. The older label SSL remains common, but obsolete SSL protocols are not a modern deployment target.

A modern handshake, without the old RSA shortcut

In a typical certificate-authenticated TLS 1.3 handshake, the client and server negotiate parameters and establish shared key material using an ephemeral key exchange. The server presents its certificate and proves possession of the corresponding private key; the client validates the identity and certificate chain. Both endpoints derive traffic keys and verify the handshake before normal protected application traffic.

This is not the old explanation in which the client simply encrypts a session key with the certificate’s RSA public key and sends it to the server. TLS 1.3 does not use RSA key transport. Its resumption and pre-shared-key modes have different message flows, so a simplified certificate handshake is not a description of every connection.

Certificate identity and name coverage

The client must verify the requested hostname as well as a trusted chain and certificate validity. Encryption without correct peer authentication can protect a connection to the wrong endpoint. A server may request a client certificate for mutual authentication, but ordinary HTTPS does not require every visitor to have one.

Where protection ends

• TLS protects data in transit between the endpoints of that connection, not a stolen database, vulnerable application or compromised browser.
• A TLS-terminating proxy can read the plaintext it handles. Configure and validate its separate origin connection appropriately.
• Traffic timing, volume and some connection metadata can remain observable. TLS is not complete anonymity.
• Certificate issuance and renewal need monitoring. A successful handshake today is not evidence tomorrow’s renewal will work.

Versions and operational checks

TLS 1.0 and 1.1 are deprecated. Use supported TLS 1.2/1.3 configurations appropriate to the service and clients instead of enabling legacy algorithms globally. Check the web server, mail server, application runtime and proxy separately; a working browser request says little about an unrelated mail service.

Performance depends on the deployment, connection reuse, workload and hardware. This article does not provide measured overhead or capacity figures. For practical certificate coverage, see the website certificate guide.

References: TLS 1.3 specification; deprecation of TLS 1.0 and 1.1; service-specific cPanel protocol configuration.

Reviewed October 14, 2026. Protocol/documentation review, not a benchmark or customer-server configuration audit.