Use TLS, not SSL. Every version of SSL is formally deprecated and must not be used. Modern HTTPS runs on TLS 1.2 or TLS 1.3, and the NCSC is unambiguous: disable SSL entirely, disable TLS 1.0 and 1.1, and configure your server to prefer TLS 1.3. Under UK GDPR, continuing to support SSL on a public-facing service can constitute a failure to implement appropriate technical security measures, which puts you in direct conflict with ICO expectations.
If you want a quick check right now, run this in your terminal:
openssl s_client -connect yourdomain.com:443 2>/dev/null | grep "Protocol"
The output will show you exactly which protocol version your server negotiated. Anything showing SSLv2, SSLv3, TLSv1, or TLSv1.1 needs fixing today.
- Use: TLS 1.3 (preferred) and TLS 1.2 (acceptable, when properly configured)
- Disable: All SSL versions, TLS 1.0, TLS 1.1
- UK authority: NCSC TLS guidance and ICO encryption guidance both confirm this position
Key takeaways
TLS 1.3 is the current standard for encrypted web communications; SSL is deprecated, formally unsafe, and must not be used on any public-facing service.
| Point | Details |
|---|---|
| Use TLS 1.3 and 1.2 only | Disable all SSL versions and TLS 1.0/1.1; NCSC and ICO both require this for UK services. |
| Forward secrecy is mandatory in TLS 1.3 | TLS 1.2 supports it optionally; always configure ECDHE or DHE key exchange if staying on 1.2. |
| “SSL certificate” means TLS certificate | The naming is legacy marketing; what matters is the protocol version and cipher configuration, not the label. |
| Certificate type signals identity level | DV proves domain control only; OV and EV verify the organisation, which matters for UK business credibility. |
| Kukoocreative builds with TLS from the start | New sites from Kukoocreative include correct HTTPS, HSTS, and certificate management as standard. |
Table of Contents
- What are SSL and TLS, and how do they differ?
- How did we get from SSL to TLS? A brief timeline
- What are the key technical differences that affect security?
- Why is SSL unsafe? Attacks you need to know about
- Which TLS versions and settings should you use today?
- What do people mean by ‘SSL certificate’, and which type do you need?
- How do you check whether your server is using TLS?
- Practical migration checklist for web and mail operators
- Why TLS matters for UK small businesses
- The thing most guides get wrong about SSL vs TLS
- Your website security, handled properly
- Sources
What are SSL and TLS, and how do they differ?
SSL (Secure Sockets Layer) was developed by Netscape in the mid-1990s to encrypt communications between a browser and a web server. It was the first widely deployed protocol for securing internet traffic, but it contained fundamental design flaws that were never fully resolved.
TLS (Transport Layer Security) is the direct successor. It provides encryption, data integrity, and authentication for communications between two parties, whether that is a browser and a web server, a mail client and a mail server, or two application servers. TLS is the protocol your browser actually uses when you see https:// in the address bar.
The relationship to HTTPS is straightforward. HTTPS is HTTP running over a TLS connection, not an SSL one. The certificate your server presents is an X.509v3 certificate signed by a trusted Certificate Authority (CA). Vendors and hosting panels still label these “SSL certificates” for historical reasons, but they are TLS certificates in every meaningful sense. Cloudflare confirms that modern servers negotiate TLS 1.2 or 1.3, regardless of what the product page calls the certificate.
A simplified view of how a connection works:
- Client hello: your browser sends supported TLS versions and cipher suites
- Server hello: the server selects a version and cipher, presents its X.509 certificate
- Authentication: the client validates the certificate against trusted CAs
- Key exchange: both sides derive a shared session key
- Encrypted channel: all subsequent HTTP traffic travels inside this encrypted tunnel
The term “SSL” in everyday speech now means “the certificate and encryption setup on a website.” Technically, it means a deprecated protocol you should not be running.
How did we get from SSL to TLS? A brief timeline
Understanding the history explains why the deprecations are not bureaucratic caution but responses to real, exploited vulnerabilities.
- 1994: Netscape develops SSL 2.0 (never publicly released in a stable form; quickly found to be broken)
- 1995: SSL 3.0 released; widely adopted but contained serious weaknesses
- 1999: TLS 1.0 published as RFC 2246; essentially SSL 3.1 with fixes, but still carries legacy weaknesses
- 2006: TLS 1.1 (RFC 4346) adds protections against CBC padding attacks
- 2008: TLS 1.2 (RFC 5246) introduces AEAD cipher suites and SHA-256; still the minimum acceptable version today
- 2018: TLS 1.3 (RFC 8446) published; removes legacy ciphers, mandates forward secrecy, reduces handshake round trips
- 2021: RFC 8996 formally deprecates TLS 1.0 and TLS 1.1 at the IETF level
- Ongoing: NCSC and GOV.UK guidance formally deprecate all SSL versions and TLS 1.0/1.1 for UK public services
SSL 3.0 fell to POODLE. TLS 1.0 was vulnerable to BEAST. The deprecations are earned.
What are the key technical differences that affect security?
The gap between SSL/early TLS and TLS 1.3 is not cosmetic. These are substantive protocol changes with direct security consequences.
Handshake design
SSL and TLS 1.2 require two full round trips before encrypted data can flow. TLS 1.3 reduces this to one round trip (1-RTT), and supports zero round trips (0-RTT) for session resumption. 0-RTT is faster but carries a replay-attack risk, so it should only be enabled for idempotent requests and with careful implementation.
Record protocol and message authentication
SSL used MAC-then-encrypt, a construction that is vulnerable to padding oracle attacks. TLS 1.2 supports both MAC-then-encrypt (legacy) and AEAD (Authenticated Encryption with Associated Data). TLS 1.3 drops MAC-then-encrypt entirely and uses only AEAD, which authenticates and encrypts in a single operation. Authgear’s technical summary confirms this as one of the most significant practical improvements in TLS 1.3.
Cipher suite evolution
| Feature | SSL 3.0 / TLS 1.0–1.1 | TLS 1.2 | TLS 1.3 |
|---|---|---|---|
| Key exchange | RSA, DH (static) | RSA, ECDHE, DHE | ECDHE, DHE only |
| Authentication | RSA, DSA | RSA, ECDSA | RSA, ECDSA, EdDSA |
| Bulk encryption | RC4, 3DES, AES-CBC | AES-CBC, AES-GCM, ChaCha20 | AES-GCM, ChaCha20-Poly1305 |
| MAC / integrity | HMAC-MD5, HMAC-SHA1 | HMAC-SHA256, AEAD | AEAD only |
| Forward secrecy | Not supported | Optional (ECDHE/DHE) | Mandatory |
Forward secrecy
Forward secrecy means that compromising today’s private key cannot decrypt yesterday’s recorded traffic. TLS 1.2 supports it optionally via ECDHE or DHE key exchange. TLS 1.3 makes it mandatory. In practice, a TLS 1.2 server configured with ECDHE-RSA-AES128-GCM-SHA256 has forward secrecy; one configured with RSA-AES128-CBC-SHA does not. TLS 1.3 removes the ambiguity: every session uses ephemeral keys, so TLS_AES_128_GCM_SHA256 is always forward-secret by design.
Why is SSL unsafe? Attacks you need to know about
These are not theoretical. Each attack below was demonstrated against real traffic in the wild.
- POODLE (2014): exploits SSL 3.0’s CBC padding to decrypt session cookies. The fix is disabling SSL 3.0 entirely. There is no patch for the underlying design.
- BEAST (2011): targets TLS 1.0’s CBC implementation, allowing an attacker to recover plaintext from an encrypted stream. Mitigated by TLS 1.1+ and by using AEAD ciphers.
- DROWN (2016): if a server supports SSLv2 on any port or shares a private key with a server that does, an attacker can use SSLv2 weaknesses to decrypt TLS sessions. Disabling SSLv2 everywhere is the only remedy.
- Downgrade attacks (FREAK, Logjam): an attacker forces a negotiation to a weaker cipher suite or protocol version. TLS 1.3 removes the vulnerable cipher suites that make downgrade attacks possible; TLS 1.2 servers should use
TLS_FALLBACK_SCSVto signal that a downgrade is illegitimate.
Supporting SSL or TLS 1.0/1.1 alongside modern versions does not just expose old clients. It exposes all clients, because an active attacker can force a downgrade.
Pro Tip: Keep your TLS library (OpenSSL, BoringSSL, LibreSSL) updated on a regular patching cycle. New vulnerabilities in TLS implementations appear regularly, and an unpatched library can undermine an otherwise correct configuration.
Which TLS versions and settings should you use today?
The NCSC and Gov are clear: enable TLS 1.3 and TLS 1.2; disable everything else. The ICO reinforces this from a UK GDPR perspective, noting that browser support for TLS 1.3 is now near-universal.
Mozilla publishes three configuration profiles that map neatly onto different operational contexts:
| Profile | TLS versions | Cipher suites | Typical use case |
|---|---|---|---|
| Modern | TLS 1.3 only | TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA, TLS_CHACHA20_POLY1305_SHA256 | New services, no legacy client requirement |
| Intermediate | TLS 1.2 + 1.3 | ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256, ChaCha20-Poly1305 | Most public-facing web services |
| Old (compatibility) | TLS 1.0+ | Broad cipher support | Legacy systems only; not recommended |
The NCSC frames this as a practical trade-off: the Modern profile maximises security but will drop connections from very old clients. The Intermediate profile is the pragmatic choice for most UK businesses during migration.
Server configuration checklist
- Update your TLS library and web server software to current stable releases
- Enable TLS 1.3 and TLS 1.2; explicitly disable TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0
- Remove EXPORT, RC4, NULL, DES, and 3DES cipher suites from your configuration
- Prefer AEAD cipher suites: AES-GCM and ChaCha20-Poly1305
- Disable TLS renegotiation or enable secure renegotiation only
- Enable HTTP Strict Transport Security (HSTS) with a
max-ageof at least 31536000 seconds - Submit your domain to the HSTS preload list once you are confident in your configuration
- Test with SSL Labs and target an A or A+ grade
What do people mean by ‘SSL certificate’, and which type do you need?
The phrase “SSL certificate” is legacy marketing language. What you are actually deploying is an X.509v3 TLS certificate, signed by a Certificate Authority. Keyfactor notes that this naming persistence causes genuine confusion in procurement, where teams specify “SSL” without considering the TLS configuration that actually matters.
The certificate type determines how much identity verification the CA performed before issuing it.
| Type | Verification | Trust signal | Typical use |
|---|---|---|---|
| DV (Domain Validated) | Domain control only | Padlock in browser | Blogs, personal sites, internal tools |
| OV (Organisation Validated) | Domain + legal entity check | Organisation name in cert details | Business websites, e-commerce |
| EV (Extended Validation) | Full legal, operational, and physical checks | Organisation name historically shown in browser bar | Financial services, high-value transactions |
DV certificates are now trivially easy to obtain, including at no cost via Let’s Encrypt. That makes the browser padlock a weak trust signal on its own. For a professional services business, an OV certificate adds a verified organisation name to the certificate details, which a technically aware client or partner can inspect. EV adds the most rigorous verification, though major browsers have reduced the visual prominence of EV indicators in recent years.
Pro Tip: For a UK business website handling client enquiries or transactions, OV is the minimum worth considering. DV is fine for a development environment or a blog; it is not a strong identity signal for a business asking clients to share sensitive information.
How do you check whether your server is using TLS?
You do not need specialist software. Three approaches cover most situations.
Browser developer tools
Open Chrome or Firefox, navigate to your site, and open Developer Tools (F12). Go to the Security tab. You will see the TLS version negotiated, the cipher suite in use, and the certificate details. This takes under a minute and requires no command-line access.
Command-line tools
-
openssl s_client — the most direct method:
openssl s_client -connect yourdomain.com:443 -tls1_3 2>/dev/null | grep "Protocol|Cipher"Replace
-tls1_3with-tls1_2or-tls1_1to test specific version support. If the connection fails, that version is not supported (which is what you want for 1.1 and below). -
curl with version flags:
curl --tlsv1.3 --tls-max 1.3 -v https://yourdomain.com 2>&1 | grep "SSL connection"A successful response confirms TLS 1.3 is available.
-
nmap ssl-enum-ciphers (for a full cipher audit):
nmap --script ssl-enum-ciphers -p 443 yourdomain.com
SSL Labs online scanner
Qualys SSL Labs provides the most thorough free analysis available. Paste your domain, wait two to three minutes, and you receive a letter grade (A+ to F) alongside a full breakdown of supported protocols, cipher suites, certificate chain, HSTS status, and known vulnerabilities. An A+ requires TLS 1.3 support, a valid certificate chain, HSTS with a long max-age, and no weak ciphers. Anything below a B warrants immediate attention.
You can also pair this with a technical SEO audit to catch HTTPS-related issues alongside other site health signals in a single pass.
Practical migration checklist for web and mail operators
Work through this in order. Skipping steps, particularly testing, is where migrations go wrong.
- Inventory your services. List every domain, subdomain, and port that terminates TLS, including mail servers, APIs, and internal tools.
- Update libraries and server software. Upgrade OpenSSL, Nginx, Apache, or your cloud load balancer to a current release before changing configuration.
- Enable TLS 1.3 in your server configuration alongside TLS 1.2.
- Tighten cipher suites. Remove RC4, NULL, EXPORT, DES, and 3DES. Prefer AES-GCM and ChaCha20-Poly1305.
- Disable TLS 1.0, 1.1, and all SSL versions explicitly in your configuration file.
- Test with SSL Labs before going live. Fix any issues flagged as critical or high severity.
- Enable HSTS. Start with a short
max-age(e.g. 300 seconds) to test, then extend to 31536000 once you are confident. - Rotate certificates if any are approaching expiry or were issued under SHA-1. Automate renewal with ACME/Let’s Encrypt or your CA’s tooling.
- Monitor connection logs for TLS handshake failures in the 24–48 hours after the change. A spike in failures indicates a legacy client population you may need to accommodate temporarily.
- For mail servers: prefer implicit TLS (port 465 for submission, port 993 for IMAP) over STARTTLS where possible. STARTTLS is vulnerable to downgrade if not carefully configured. Consider implementing MTA-STS to signal to sending MTAs that your domain requires TLS. Gmail prefers TLS for outbound mail and will fall back to plaintext if the receiving server does not support it, so your mail server’s TLS configuration directly affects deliverability.
For a staged rollout, keep a configuration branch that re-enables TLS 1.1 for a defined fallback window (no more than two weeks). Log which clients use it. If the count is zero after a week, remove it permanently.
Why TLS matters for UK small businesses
For a small business in the UK, TLS is not just a technical setting. It is a legal and commercial obligation.
The ICO’s guidance on encryption and data transfer makes clear that using deprecated protocols like SSL when handling personal data can constitute a failure to implement appropriate technical measures under UK GDPR Article 5(1)(f). That is not a theoretical risk. ICO enforcement actions have cited inadequate encryption as a contributing factor in data breach penalties.
Beyond compliance, there is a practical trust argument. A visitor who sees a browser security warning because your certificate has lapsed, or whose security-conscious IT department flags your site as using TLS 1.1, will not complete an enquiry form. The padlock is the floor, not the ceiling.
Key business considerations:
- GDPR obligation: personal data transmitted over deprecated protocols is inadequately protected under UK law
- Client trust: OV or EV certificates signal verified business identity, not just domain ownership
- Search visibility: Google has used HTTPS as a ranking factor; a misconfigured TLS setup can affect crawlability
- Mixed content: enabling TLS on your main domain while loading scripts or images over HTTP breaks the security model entirely; securing your website means auditing every asset, not just the certificate
For a practical overview of what a well-built UK business website should include beyond TLS, the small business website must-haves guide covers the full picture.
The thing most guides get wrong about SSL vs TLS
Most SSL vs TLS articles spend their energy on the naming confusion and then stop. The naming confusion is real but it is also the least consequential part of the problem.
The more important issue is that teams treat TLS as a binary. Either the padlock is there or it is not. In practice, a server can have a valid certificate, negotiate TLS 1.2, and still be dangerously misconfigured because it supports RSA key exchange without forward secrecy, or because it accepts RC4 as a fallback, or because HSTS is not set and a first-time visitor can be intercepted before the redirect fires.
The conventional advice, “just get an SSL certificate,” papers over this entirely. A DV certificate from a free CA takes three minutes to obtain. It proves nothing about who operates the site. It does not prevent a downgrade attack. It does not protect recorded traffic if the private key is later compromised. The certificate is the starting point, not the destination.
What actually matters is the full configuration: which versions are enabled, which cipher suites are offered, whether forward secrecy is enforced, whether HSTS is deployed, and whether the certificate type matches the trust level your clients reasonably expect. For a UK professional services business, that means OV at minimum, TLS 1.3 preferred, and a regular scan with SSL Labs to catch drift.
The padlock tells your visitor the connection is encrypted. It does not tell them it is encrypted well.
Your website security, handled properly
Your site’s TLS configuration is one part of a broader picture of building trust online. At Kukoocreative, we build websites for UK small businesses that are not just visually credible but technically sound from day one, with correct HTTPS configuration, HSTS, and certificate management built into the process rather than bolted on afterwards.
If your current site is running on an old hosting setup, or you are not sure what protocol version it negotiates, that is exactly the kind of thing we check as part of a new build or a site review. Take a look at our portfolio to see the kind of work we do for UK businesses, or read through our web design process to understand how we approach security alongside design. When you are ready to talk, get in touch and we will take it from there.