SSL and TLS are the protocols I reach for when a connection needs privacy, integrity, and identity checks instead of plain-text traffic. The useful question is not just what they are, but which version is safe to use, how the handshake actually works, and what can still go wrong when the configuration is sloppy. In 2026, the practical answer is simple: TLS is the standard, SSL is legacy, and the real security comes from how you deploy it.
The practical view at a glance
- TLS protects data in transit by encrypting traffic, checking integrity, and authenticating the server.
- SSL is historical terminology; in real deployments, modern systems should use TLS 1.3 first and TLS 1.2 only when compatibility requires it.
- The certificate proves identity, but the protocol version and cipher choices determine how strong the session really is.
- Older protocols are not acceptable; SSL 3.0, SSL 2.0, TLS 1.0, and TLS 1.1 should not be part of a new security baseline.
- Most failures are configuration failures, not failures of the idea of encrypted transport itself.
What TLS protects in practice
When I talk about TLS with teams, I keep the explanation grounded: it protects traffic while it moves across the network. That means an attacker on the same Wi-Fi, in a hostile ISP path, or sitting between a client and server should not be able to read the data, silently modify it, or impersonate the endpoint without being detected.
| Security goal | What TLS gives you | What it does not solve |
|---|---|---|
| Confidentiality | Traffic is encrypted so outsiders cannot read it in transit. | It does not stop malware on the endpoint from reading the data after decryption. |
| Integrity | Packets cannot be altered without detection. | It does not fix a broken application that accepts bad input. |
| Authentication | The server proves its identity with a certificate. | It does not magically make a phishing site trustworthy if the user goes to the wrong domain. |
I separate these three properties because people often collapse them into “encryption.” That shorthand hides the real risk: a connection can be encrypted and still be badly authenticated, or authenticated but weakened by an old protocol stack. Once that distinction is clear, the handshake itself makes more sense.
How the handshake builds trust
The TLS handshake is the part most non-specialists never see, but it is where the protocol earns its security. In broad terms, the client and server agree on the version, choose cryptographic parameters, verify the server’s certificate, and then derive shared session keys that will protect the rest of the conversation.
The certificate step
The certificate is not the encryption itself; it is the identity proof. The browser or client checks that the certificate chains back to a trusted authority and that the domain name matches the service it is connecting to. If that validation fails, the encrypted tunnel may still exist technically, but it should not be trusted.
Why forward secrecy matters
Modern TLS deployments usually rely on ephemeral key exchange, especially ECDHE. That matters because it gives forward secrecy: if a long-term server key is exposed later, previously captured traffic is still much harder to decrypt. I consider this non-negotiable for serious systems, because the value of encrypted traffic is partly about protecting yesterday’s data, not just today’s session.
Why 0-RTT needs caution
TLS 1.3 introduced 0-RTT, which can reduce latency by allowing some early data before the handshake fully completes. That is useful in the right place, but it comes with replay risk. I only like it when the application has a clear replay story, because a small latency win is not worth turning a sensitive request into a repeatable one.
Once you understand the handshake, the next question is which version and settings deserve a place in a 2026 deployment.
Which versions and settings I would use in 2026
If I were setting a baseline for a UK service today, I would treat TLS 1.3 as the default and keep TLS 1.2 only where compatibility forces me to. The NCSC’s current guidance points in the same direction: use TLS 1.3 and/or TLS 1.2 with recommended profiles, disable TLS 1.1 and 1.0, and turn off insecure features. The IETF’s TLS 1.3 specification is even more direct about legacy SSL versions: they are not acceptable negotiation targets.
| Version | Current status | Where it still appears | My take |
|---|---|---|---|
| TLS 1.3 | Preferred | New websites, APIs, internal services, modern clients | Use this first. It is cleaner, faster, and removes a lot of old failure modes. |
| TLS 1.2 | Acceptable fallback | Legacy integrations, older enterprise software, some third-party platforms | Keep it only if you need it, and lock it down hard. |
| TLS 1.1 / 1.0 | Deprecated | Rare compatibility edge cases | Disable by default. If a system still requires them, it needs a migration plan, not a shrug. |
| SSL 3.0 and earlier | Obsolete | Should not be used | Remove from any modern security discussion. |
Read Also: True Positive vs. False Positive - Master Your SOC Alerts
The cipher choices I trust
- ECDHE for key exchange, because it supports forward secrecy.
- AES-128-GCM for general-purpose deployments, because it is widely supported and efficient.
- ChaCha20-Poly1305 where device hardware makes it a better fit, especially on mobile or low-power systems.
- RSA 2048 or ECDSA with P-256 for certificate authentication, depending on ecosystem support and certificate policy.
I would not optimize for cleverness here. Strong, boring defaults beat exotic configuration every time. The real trick is to keep the profile modern without breaking legitimate clients, and that is where service context matters most.
Where TLS matters most across everyday services
People often think of TLS only as “the padlock in the browser,” but that is too narrow. In practice, it protects a lot more than HTTPS. I look for it anywhere credentials, personal data, or control traffic cross a network boundary.
- Websites and web apps use HTTPS to protect login sessions, forms, and payment flows.
- APIs need TLS because machine-to-machine traffic often carries tokens, session data, and customer records.
- Email services use it for IMAP, POP3, and SMTP when messages or credentials move between systems.
- Admin interfaces should never be left on plain HTTP, even on an internal network.
- Private service-to-service links may benefit from mutual TLS, where both sides verify each other before trust is established.
That last point matters in UK enterprise environments more often than people expect. For internal APIs, mTLS can be a practical way to strengthen identity between services, but it also increases certificate management overhead. I only recommend it when the operational team can actually maintain the client certificate lifecycle, because failed automation is still a failure.
From there, the most useful next step is to look at the mistakes that quietly weaken even a well-intended setup.
Common mistakes that undermine a solid deployment
The biggest TLS problems I see are rarely theoretical. They are usually the result of old compatibility settings, weak operational habits, or an assumption that “encrypted” automatically means “secure.”
- Leaving legacy protocols enabled because one old client still depends on them.
- Confusing certificates with security and forgetting that hostname validation, version choice, and cipher policy still matter.
- Accepting weak downgrade paths that let an attacker push a connection into a less secure mode.
- Ignoring patch levels on the TLS library, reverse proxy, or load balancer.
- Enabling 0-RTT without replay controls on applications that cannot safely repeat requests.
- Stopping at the edge and leaving traffic unprotected between the load balancer and the application tier.
The baseline I would ship first in a UK environment
If I were hardening a UK-facing service in 2026, I would start with a narrow, realistic baseline rather than a perfect one. That means enabling TLS 1.3, keeping TLS 1.2 only where required, disabling TLS 1.1, 1.0, and all SSL versions, and using certificate and cipher profiles that match the strongest broadly supported options. I would also check that the same policy applies on public endpoints, internal APIs, and management interfaces, because attackers do not care which path was supposed to be “less exposed.”
- Use TLS 1.3 wherever possible.
- Allow TLS 1.2 only for compatibility, not as a default design choice.
- Disable SSL, TLS 1.0, and TLS 1.1 everywhere.
- Use ECDHE-based cipher suites with AEAD modes such as AES-GCM or ChaCha20-Poly1305.
- Keep certificates, proxies, and TLS libraries patched and monitored.
- Test external and internal endpoints, not just the public website.
If you need one practical rule to keep, I would make it this: modern TLS is a deployment discipline, not a checkbox. Get the protocol version right, keep the certificate chain clean, remove old compatibility crutches, and the security value rises immediately.
