NZAI Security
TLS 1.2 and 1.3 Explained for NZ sites: modern cipher suites, deprecating TLS 1.0 and 1.1, nginx config
Cyber Basics

TLS 1.2 and 1.3 Explained for NZ Sites

Guide Educators + General Updated 20 Sept 2026

Plain-English guide to TLS for NZ sites: what TLS 1.2 and 1.3 mean, why old TLS versions are dangerous, and copy-paste nginx and Apache configs for modern TLS.

Written and reviewed by Feroze Ashraff Last reviewed Editorial standards

Quick answer

TLS is the protocol that puts the padlock in your browser's address bar, and modern web servers should accept only TLS 1.2 and TLS 1.3 — never TLS 1.0 or 1.1. TLS 1.0 and 1.1 have known cryptographic weaknesses, were formally deprecated by the IETF in 2018 (RFC 8996), and are blocked by all major browsers as of 2023. New Zealand schools and small businesses running a default web-server install usually still accept the old versions unless someone has explicitly turned them off — that's the gap to close.

If you want to check first, the Free Website Security Check confirms which TLS versions and cipher suites your server actually accepts.

What TLS actually is

TLS (Transport Layer Security) is the protocol your browser uses to talk to a web server over HTTPS. Every time you see https:// in the address bar, TLS is what makes the connection encrypted so that:

  • Anyone watching the network between you and the site cannot read the traffic
  • The site you reached really is the site you intended (not an attacker impersonating it)
  • The data has not been altered in transit

TLS has had several versions since it was first published in 1999. Each new version fixed weaknesses in the previous one:

| Version | Year | Status in 2026 | Comment | |---|---|---|---| | SSL 2.0 | 1995 | Broken, never used | Long since disabled everywhere | | SSL 3.0 | 1996 | Broken, formally deprecated | POODLE attack (2014) made it unusable | | TLS 1.0 | 1999 | Deprecated (RFC 8996) | Still accepted by some servers by accident | | TLS 1.1 | 2006 | Deprecated (RFC 8996) | Same — typically disabled by browsers | | TLS 1.2 | 2008 | Required minimum | The practical baseline; supported by every browser in use today | | TLS 1.3 | 2018 | Recommended | Faster handshake, removes old weak cipher suites entirely |

When a server "accepts" a version, it means a client can choose to use that version. Even if your site prefers TLS 1.3, a misconfigured server may still allow fallback to TLS 1.0 or 1.1 — and that fallback path is what attackers exploit (1).

Why TLS 1.0 and 1.1 are not safe to keep

TLS 1.0 and 1.1 are vulnerable to several well-known attack classes:

  • BEAST (2011) — browser-exploit against SSL/TLS, exploits CBC-mode cipher weaknesses
  • POODLE (2014) — padding-oracle attack against CBC-mode ciphers, originally against SSL 3 but the same class affects TLS 1.0/1.1 in some configurations
  • Sweet32 (2016) — birthday-bound attacks against 64-bit block-size ciphers (3DES and RC4), which were permitted under TLS 1.0/1.1
  • ROBOT (2017) — Bleichenbacher-style attack against RSA key exchange, possible in TLS 1.0/1.1 implementations

The IETF deprecated TLS 1.0 and 1.1 in RFC 8996 in March 2021 (1). Major browsers (Chrome, Firefox, Safari, Edge) shipped the cut-off during 2023, and Microsoft deprecated them for first-party Microsoft services in 2018.

For a New Zealand organisation, running a server that accepts TLS 1.0 or 1.1 is roughly equivalent to advertising "we have not updated this in 10 years". The CERT NZ baseline controls include "use modern TLS" as a Top 11 item (2).

The Mozilla SSL Configuration Generator remains the most accurate plain-English reference for current cipher list recommendations. Use it to confirm your ssl_ciphers directive matches what the Mozilla team recommends today (3).

If your site accepts TLS 1.0 or 1.1 today, attackers can force a downgrade: even if both you and the visitor prefer TLS 1.3, a man-in-the-middle can pretend the visitor only supports TLS 1.0. Unless you've explicitly disabled the old versions, that downgrade succeeds.

TLS 1.2 vs TLS 1.3 — what actually changed

TLS 1.3 is not a small revision — it removed a lot of legacy cruft and changed the handshake. Practically:

TLS 1.2 (still required, still safe when configured properly):

  • Supports many cipher suites; you must pick the right ones and disable the weak ones
  • Handshake is two round-trips before application data flows (slower)
  • Permits older key exchange methods (RSA, static DH) that have known weaknesses

TLS 1.3 (preferred):

  • Only 5 cipher suites are defined, all using modern AEAD ciphers (AES-GCM, ChaCha20-Poly1305) and forward-secret key exchange (X25519, secp256r1)
  • Handshake is one round-trip before application data flows (faster — visibly faster page loads on slow networks)
  • Removes RSA key exchange entirely; mandates forward secrecy
  • Encrypts more of the handshake itself, reducing metadata leakage

For most readers, the practical takeaway is the same: disable TLS 1.0 and 1.1; enable TLS 1.2 with a modern cipher list and TLS 1.3 if your server supports it.

If you run a current nginx (≥ 1.17) or OpenSSL (≥ 1.1.1), TLS 1.3 works out of the box. Apache httpd needs mod_ssl ≥ 1.3.2 with OpenSSL ≥ 1.1.1 (so basically anything shipped in the last 4 years).

Copy-paste fixes for nginx

In your server block (or a conf.d/ssl.conf snippet), set the allowed protocols and the cipher list:

# Disable TLS 1.0 and 1.1; require TLS 1.2 minimum; allow TLS 1.3.
ssl_protocols TLSv1.2 TLSv1.3;

# Modern cipher list — Mozilla "intermediate" baseline (as of 2026).
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

# Honour the client's preference rather than the server's.
ssl_prefer_server_ciphers off;

# Enable TLS 1.3-specific session optimisation.
ssl_session_tickets on;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;

Reload with nginx -s reload or sudo systemctl reload nginx.

To confirm only TLS 1.2/1.3 are accepted (and TLS 1.0/1.1 are refused), test from the command line:

openssl s_client -connect yoursite.nz:443 -tls1    # should fail or refuse
openssl s_client -connect yoursite.nz:443 -tls1_1  # should fail or refuse
openssl s_client -connect yoursite.nz:443 -tls1_2  # should succeed
openssl s_client -connect yoursite.nz:443 -tls1_3  # should succeed if your OpenSSL ≥ 1.1.1

If -tls1 still succeeds, your server config has not actually disabled the old version — nginx -T | grep ssl_protocols is the quickest way to confirm what nginx will use on reload.

Copy-paste fixes for Apache httpd

In your <VirtualHost> (or in mod_ssl config):

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder off
SSLCompression off

Note the -all +TLSv1.2 +TLSv1.3 form — Apache's syntax is to first disable everything, then turn on only what you want. This is the safer pattern: it's hard to accidentally permit TLS 1.0 by adding a new directive.

After editing, reload with sudo systemctl reload apache2. Confirm via the same openssl s_client tests as for nginx.

TLS 1.2 and 1.3 Explained for NZ sites — modern cipher suite selection and deprecation of old TLS versions

TLS 1.3 gotchas that catch people out

Three real-world snags:

1. Old curl or old clients fail to negotiate. If your enterprise monitoring system or backup client uses an OpenSSL older than 1.1.1, it may not understand TLS 1.3. The fix is either upgrade the client (preferred) or ensure the server still supports TLS 1.2 (it should — that's what -TLSv1.2 ensures).

2. TLS 1.3 ciphers look different in server logs. Where TLS 1.2 logs show the cipher name directly (e.g. ECDHE-RSA-AES256-GCM-SHA384), TLS 1.3 only logs the negotiation as TLS_AES_256_GCM_SHA384 — the same cipher under a different name. Log parsers that grep for the old string will miss them.

3. OCSP stapling matters more with TLS 1.3. TLS 1.3 encrypts more of the handshake, which means browsers can't passively check certificate revocation as easily. Stapled OCSP responses at the server (rather than the browser fetching separately) are now standard. Most packages do this automatically once certs are configured; check that ssl_stapling on (nginx) or SSLUseStapling on (Apache) is enabled.

Test your config in a staging environment first, not on the production site. The wrong ssl_protocols line can lock you out of your own server — and the recovery requires console/SSH access that managed-hosting customers may not have.

Verify your config before saying you're done

Three ways to verify, in increasing depth:

1. The free NZAI scanner. Run the Free Website Security Check — it confirms whether TLS 1.2/1.3 are accepted and TLS 1.0/1.1 are refused, and flags weak ciphers.

2. SSL Labs. The free scan at https://www.ssllabs.com/ssltest/ is the most thorough public TLS checker. It grades you A through F, identifies every accepted version, shows all cipher suites, and tests for known attacks. Note that the scan can take a couple of minutes — wait for the full report before reading.

3. Direct openssl s_client testing. Already shown above — useful as a quick sanity check that the server config actually loaded after the reload. openssl s_client -tls1 should fail to negotiate a handshake; if it doesn't, the reload did not take.

Common mistakes to avoid

  • "TLS 1.3 only" is too aggressive. If you disable TLS 1.2 entirely, you'll break some older but legitimate clients (Java 8, old curl, some embedded devices). The pragmatic minimum is TLS 1.2 + TLS 1.3, not TLS 1.3 only.
  • Permitting cipher suites you didn't mean to. The default cipher list for nginx and Apache includes weak and strong ciphers mixed together. Always set an explicit ssl_ciphers line rather than relying on defaults.
  • Forgetting HSTS. Disabling old TLS is one half of the picture. The other half is enabling HSTS so visitors can't be downgraded to plain HTTP. See the HSTS guide for the one-line config.
  • Mixed content. TLS 1.3 doesn't fix http:// references inside your HTTPS pages. See HTTPS Everywhere for the CSP upgrade-insecure-requests fix.

Knowledge check

Test your understanding of TLS versions and configuration with these questions. Click or tap each card to flip it and see the answer.

Q1You run openssl s_client -connect yourschool.nz:443 -tls1 and it negotiates a successful handshake. Does that mean your site is accepting real visitors on TLS 1.0?tap to flip
Answer: Yes — TLS 1.0 was successfully negotiated, which means your server accepts TLS 1.0 if asked. Modern browsers will not ask, but an attacker who can force a protocol downgrade (man-in-the-middle on a coffee-shop Wi-Fi, for example) can still trigger it. Your ssl_protocols directive in nginx or SSLProtocol in Apache has not removed TLS 1.0. Disable it explicitly, reload, and re-test with openssl s_client -tls1 — this time it should fail (4).
Q2SSL Labs gives your site a grade A but says it accepts both TLS 1.2 and TLS 1.3 with the cipher TLS_AES_256_GCM_SHA384. Is that configuration OK for a New Zealand school website?tap to flip
Answer: Yes — that is the modern best practice. TLS_AES_256_GCM_SHA384 is the strongest cipher suite defined for TLS 1.3; it uses AES-256 in GCM mode for confidentiality and authentication, with SHA-384 for the handshake hash. The grade A reflects the absence of old TLS versions and weak ciphers. The remaining thing to check is HSTS (so visitors can't be downgraded to plain HTTP) — run the HSTS check at HSTS Preload to confirm (5).
Q3You disable TLS 1.0 and 1.1 on nginx, reload, and run the free scan again. The TLS line passes but the security headers line fails (CSP, HSTS, X-Frame-Options all marked missing). What happened, and is anything actually broken?tap to flip
Answer: Two unrelated checks ran. The TLS one covered the protocol negotiation and cipher list. The header one is a separate response-header check on the application layer — TLS settings do not affect HTTP response headers. You need to set those headers in a separate add_header block (nginx) or Header always set directive (Apache). See Security Headers Explained for NZ Sites for the copy-paste block, and re-run the scan once the headers are in place (6).

Sources and references

[1] Sheffer, Y., Holz, T., & Saint-Andre, P. (2021). RFC 8996 — Deprecating TLS 1.0 and TLS 1.1. Internet Engineering Task Force. https://datatracker.ietf.org/doc/html/rfc8996

[2] CERT NZ. (2025). Top 11 cyber security tips for your business. https://www.cert.govt.nz/business/guides/top-tips-for-cyber-security/

[3] Mozilla. (2025). Mozilla SSL Configuration Generator. https://ssl-config.mozilla.org/

[4] OpenSSL Software Foundation. (2025). openssl-s_client(1) manual page. https://docs.openssl.org/master/man1/openssl-s_client/

[5] SSL Labs. (2025). SSL Server Test. https://www.ssllabs.com/ssltest/

[6] Mozilla. (2025). MDN Web Docs — Transport Layer Security (TLS). https://developer.mozilla.org/en-US/docs/Web/Security/Transport_Layer_Security

What to do next