What are SSL and TLS?

Transport Layer Security, or TLS, protects data while it is transmitted. The protocol encrypts the connection, detects modification and normally authenticates the server with a digital certificate. HTTPS is HTTP over TLS. The older name SSL remains common in informal use, but the actual SSL protocols are obsolete and must no longer be enabled.

Which security properties does TLS provide?

Depending on protocol and network, metadata such as IP addresses, traffic volume and connection timing remains visible. TLS protects content but does not make communication anonymous.

How does the TLS handshake work?

1. Offer capabilities: The client sends supported TLS versions, cryptographic parameters and random values.
2. Select parameters: The server chooses a compatible secure set and sends its key-exchange data.
3. Prove identity: The server provides its certificate and proves possession of the corresponding private key.
4. Validate the certificate: The client checks trust chain, hostname, validity and signature.
5. Derive session keys: Both sides independently derive the same symmetric keys.
6. Transfer application data: After confirmation, data flows encrypted and integrity-protected.

Symmetric encryption protects application data efficiently. Asymmetric cryptography and signatures are mainly required for authentication and secure key exchange. Session resumption accelerates later connections. TLS 1.3 0-RTT data can reduce latency further but may be replayed, so it is unsuitable for some state-changing requests.

What is the purpose of certificates?

An X.509 certificate binds a public key to names and other information. For a public website, a trusted certification authority confirms this binding. The browser follows the certificate chain to a locally trusted root CA and checks that the requested hostname is included. A valid certificate for shop.example does not confirm admin.example unless that name or a matching wildcard is covered.

Domain Validation, Organization Validation and Extended Validation differ in the identity checks performed during issuance. They do not change the strength of transport encryption. The private key remains solely with the operator and must be protected against export, unauthorized access and accidental publication.

SSL, TLS 1.2 or TLS 1.3?

TLS 1.3 was originally specified in RFC 8446. RFC 9846, published in 2026, replaces that specification with a backward-compatible revision while retaining the TLS 1.3 version number. It clarifies requirements and, among other changes, prohibits negotiation of TLS 1.0 and 1.1.

What is mutual TLS?

With ordinary HTTPS, only the server proves its identity using a certificate. Mutual TLS (mTLS) also requires a client certificate. It is useful for service-to-service communication, administrative interfaces and managed devices. mTLS authenticates a certificate but does not automatically implement business authorization: the service still decides which actions the identified peer may perform.

Which TLS mistakes are common?

• Expired certificates, missing intermediates or a hostname mismatch.
• Enabled legacy protocols, weak cipher suites or unsuitable key lengths.
• Private keys stored in repositories, images, backups or accessible to too many administrators.
• TLS terminates at a load balancer while the remaining internal path is unprotected and uncontrolled.
• Mixed content loads individual HTTP resources into an HTTPS page and weakens the boundary.
• Clients disable certificate validation or accept every certificate warning.
• Manual renewal continues until a forgotten certificate causes an unexpected outage.

How is TLS operated securely?

Operators should prefer TLS 1.3, configure TLS 1.2 securely only where compatibility requires it, and disable older versions. Certificate issuance and renewal can be automated, while monitoring warns of expiry and unexpected change. Private keys belong in suitable secret or key-management systems. HTTP should redirect consistently to HTTPS. HSTS should be enabled and extended to subdomains only after all affected hosts support HTTPS permanently.

Regular configuration testing needs to cover every endpoint: web servers, APIs, mail services, load balancers and internal service connections. One certificate may be correct while another virtual host or obsolete listener still offers unsafe parameters.

What does TLS not protect?

TLS protects the connection, not the application or endpoints. A perfectly encrypted website can still contain authorization flaws, malware, phishing or insecure business logic. After decryption at an endpoint, data is available to the application in plaintext. TLS is therefore an essential transport control but only one part of overall security.