Understanding TLS 1.2 and TLS 1.3

TLS (Transport Layer Security) is the cryptographic protocol that encrypts and authenticates data transmitted between clients and servers over a network. It protects personal information, financial transactions, API traffic, and business communications from eavesdropping, tampering, and impersonation. TLS 1.3 is the current recommended version. It reduces handshake round trips from 2-RTT to 1-RTT, mandates forward secrecy via ECDHE for all connections, removes all legacy weak cipher suites, and encrypts more of the handshake than TLS 1.2. The recommended action: enable TLS 1.3 on all servers immediately, disable TLS 1.0 and 1.1, restrict TLS 1.2 to ECDHE-AEAD cipher suites only during the transition period, and maintain both versions in parallel until legacy client analysis confirms TLS 1.2 can be retired.

Quick Answer: TLS 1.2 vs TLS 1.3 – Which to Use and Why

TLS 1.3 is the right choice for all new deployments. It is faster (1-RTT handshake vs 2-RTT), more secure (mandatory forward secrecy, encrypted handshake, removal of all legacy algorithms), and simpler (5 cipher suites instead of hundreds). TLS 1.2 remains necessary only for backward compatibility with clients and systems that do not yet support TLS 1.3. NIST mandates that all U.S. federal government TLS servers support both TLS 1.2 (with FIPS-compliant cipher suites) and TLS 1.3 per NIST SP 800-52 Revision 2, with TLS 1.3 required from January 1, 2024. TLS 1.0 and TLS 1.1 must not be used; they have known exploitable vulnerabilities and no current legitimate use.

What Is TLS?

Transport Layer Security (TLS) is a cryptographic protocol standardized by the IETF in 1999. TLS builds on SSL (Secure Sockets Layer) by addressing its vulnerabilities and enhancing security through stronger encryption algorithms, improved certificate validation, and protection against attacks present in SSL versions. Older TLS versions (1.0 and 1.1) had security flaws allowing attackers to steal sensitive data. TLS protects data through three mechanisms working together:

• Authentication: the server presents a TLS certificate issued by a trusted Certificate Authority (CA) during the handshake. The client verifies this certificate to confirm it is communicating with the legitimate server, not an impersonator.
• Encryption: after the handshake establishes a shared session key, all transmitted data is encrypted with a symmetric cipher (AES-GCM or ChaCha20-Poly1305 in TLS 1.3), preventing eavesdroppers from reading the content.
• Integrity: AEAD cipher suites include authentication tags that detect any modification of encrypted data, ensuring an attacker cannot alter data in transit without detection.

TLS 1.2 and Its Handshake

TLS 1.2, introduced in August 2008 (IETF RFC 5246), addressed limitations of TLS 1.0 and 1.1 through stronger encryption algorithms, improved certificate validation, and support for AEAD cipher suites. Its handshake requires two round trips (2-RTT):

• The client sends a ClientHello with supported TLS versions, cipher suites, a client random, and an optional session ID.
• The server responds with a ServerHello selecting the TLS version and cipher suite, its own random, and its signed certificate with public key. If mutual authentication is required, the server requests a client certificate.
• The client validates the server’s certificate against trusted CAs. In mutual TLS (mTLS), the server also validates the client’s certificate.
• Public key cryptography secures the key exchange: the client sends a pre-master secret encrypted with the server’s public key. Only the server can decrypt it with its private key, held securely in an HSM or key vault. Both parties derive session keys from the pre-master secret and their random values.
• Client and server exchange ChangeCipherSpec and Finished messages confirming they are ready for symmetric encryption. All subsequent communication uses the derived session keys.

Key Features of TLS 1.2

• Enhanced hashing: replaced the MD5+SHA-1 combination used in earlier versions with configurable hash algorithms including SHA-256 and SHA-384.
• AES cipher suite support: introduced AES cipher suites with 128-bit and 256-bit keys, offering significantly stronger symmetric encryption than the DES-based suites it replaced.
• Authenticated encryption (AEAD) support: expanded support for AEAD modes including AES-GCM and AES-CCM, which provide both confidentiality and integrity verification in a single operation.
• Negotiable hash and signature algorithms: both client and server can specify their supported hash and signature algorithms during the handshake, allowing the strongest mutually supported combination to be selected and allowing graceful migration away from weak algorithms like SHA-1.

TLS 1.3 and Its Handshake

TLS 1.3, published in August 2018 (RFC 8446), represents a significant redesign of the protocol. It prioritizes security by removing vulnerable legacy options rather than adding mitigations on top of them. The TLS 1.3 handshake completes in one round trip (1-RTT):

• The client sends a ClientHello including supported TLS version, cipher suites, client random, and key shares for its preferred ECDHE groups. If client authentication is enabled, the client also includes certificate information.
• The server selects the cipher suite and ECDHE group, generates the master secret from the ClientHello random and server-generated random combined with the selected key shares, and sends a ServerHello with the selected parameters plus a ServerFinished message. The server’s certificate and all subsequent handshake messages are encrypted.
• The client verifies the server’s certificate, generates the same master secret using its own key share and the server’s response, sends a ClientFinished message, and both parties begin encrypted application data exchange. The entire handshake is complete in one round trip.

Key Features of TLS 1.3

• Mandatory forward secrecy: TLS 1.3 requires ECDHE for all key exchanges, making forward secrecy mandatory for every connection. Even if a server’s long-term TLS private key is later compromised, past sessions cannot be decrypted because the ephemeral session keys are gone.
• Only AEAD cipher suites permitted: TLS 1.3 allows only five cipher suites, all AEAD: AES-128-GCM-SHA256, AES-256-GCM-SHA384, ChaCha20-Poly1305-SHA256, AES-128-CCM-SHA256, and AES-128-CCM-8-SHA256. All provide authenticated encryption detecting tampering.
• Encrypted handshake: TLS 1.3 encrypts more of the handshake than TLS 1.2, including the server certificate. Passive observers cannot see which certificate a server presents.
• 0-RTT resumption: clients reconnecting to a server they have connected to before can send application data with the first message (0-RTT), reducing latency for recurring connections. Note: 0-RTT data is vulnerable to replay attacks and should not be used for non-idempotent operations (state-changing requests like financial transactions).
• Algorithm removal: TLS 1.3 removes RC4, DES, 3DES, MD5, SHA-1, RSA key exchange, static DH, CBC cipher suites, and TLS compression — all of which were attack vectors in TLS 1.2 implementations.

Comparison: TLS 1.2 vs TLS 1.3

Feature	TLS 1.2	TLS 1.3	Impact
Handshake round trips	2-RTT	1-RTT (0-RTT for session resumption)	TLS 1.3 faster connection establishment; 0-RTT has replay attack risk
Permitted cipher suites	Hundreds, including weak ones (RC4, DES, CBC)	Five AEAD suites only	TLS 1.2 requires careful configuration to avoid weak suites; TLS 1.3 is safe by design
Key exchange	RSA, DHE, ECDHE (all supported)	ECDHE only	TLS 1.3 provides forward secrecy for every connection; TLS 1.2 RSA key exchange has no forward secrecy
Forward secrecy	Optional (depends on cipher suite)	Mandatory	TLS 1.3 protects past sessions even if long-term key is compromised
Handshake encryption	Certificate exposed in plaintext during handshake	Certificate encrypted in handshake	TLS 1.3 hides server identity from passive observers
Algorithm removal	Supports RC4, MD5, SHA-1, 3DES (must be explicitly disabled)	These algorithms removed entirely	TLS 1.3 eliminates entire attack classes (POODLE, BEAST, CRIME) by removing the vulnerable primitives
Session resumption	Session IDs and session tickets	PSK with 0-RTT option	TLS 1.3 session tickets provide forward secrecy; TLS 1.2 session tickets may not
Certificate validation	Some handshake details exposed	Full handshake encrypted after ServerHello	TLS 1.3 provides privacy improvement for certificate contents
Performance	Slower (2-RTT handshake)	Faster (1-RTT; 0-RTT for resumption)	TLS 1.3 reduces latency especially for high-latency networks and mobile clients
NIST mandate	Required; FIPS-compliant cipher suites only	Required from January 1, 2024 (NIST SP 800-52 Rev. 2)	Both required for federal systems; TLS 1.3 is the current standard

Cipher Suite Selection for TLS 1.2

TLS 1.3 has a fixed list of five AEAD cipher suites; there is nothing to choose. TLS 1.2 supports a much wider range, including insecure options that must be explicitly disabled. Recommended TLS 1.2 cipher suites per NIST SP 800-52 Rev. 2 (in preference order):

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (best: ECDHE forward secrecy, ECDSA cert, AES-256-GCM AEAD)
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ECDHE forward secrecy, RSA cert, AES-256-GCM AEAD)
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

Explicitly disable in TLS 1.2: any suite containing RC4, DES, 3DES, NULL encryption, EXPORT, MD5, or anonymous (anon) key exchange. Disable all RSA key exchange suites (TLS_RSA_*): they provide no forward secrecy. Avoid CBC suites where possible due to padding oracle attack susceptibility (POODLE, BEAST).

Vulnerabilities: TLS 1.2 and TLS 1.3

TLS 1.2 has been targeted by several high-profile attacks, most exploiting its support for legacy algorithms:

• BEAST (2011): exploited CBC IV predictability in TLS 1.0; partially mitigated in TLS 1.2 through AES-GCM and AEAD cipher suites.
• POODLE (2014): exploited SSL 3.0 padding oracle via protocol downgrade attacks; fixed by disabling SSL 3.0 and TLS 1.0/1.1.
• Heartbleed (2014): OpenSSL memory disclosure vulnerability; not in the TLS specification itself but affected TLS 1.2 implementations.
• Raccoon attack (2020): timing-based side-channel attack on DHE key exchange; TLS 1.3’s use of ECDHE eliminates static DH entirely.
• CRIME and BREACH: exploited TLS compression to extract secrets; TLS 1.3 removes compression entirely.

TLS 1.3 eliminates most of these attack surfaces by removing the vulnerable primitives (CBC modes, DH, compression, RSA key exchange) rather than patching around them. TLS 1.3 is not immune to implementation vulnerabilities: misconfigurations like predictable nonces in AES-GCM, improper 0-RTT replay protection, and weak key generation can still create vulnerabilities. The NIST CVE database has documented TLS 1.3 implementation flaws in specific products. Regular patching, security audits, and TLS configuration review remain essential even with TLS 1.3.

Deployment Example: Enterprise TLS Migration

A financial services organization with 200 public-facing services implements a structured TLS migration:

1. Audit and inventory: TLS configuration scanning across all 200 endpoints identifies: 12 services still running TLS 1.0 or 1.1; 85 services using TLS 1.2 with RSA key exchange cipher suites (no forward secrecy); 40 services using weak CBC cipher suites; 63 services already using TLS 1.2 with ECDHE-AEAD suites. TLS certificates: 140 RSA-2048, 60 ECDSA P-256.
2. TLS 1.0/1.1 immediate disable: the 12 services running TLS 1.0/1.1 are updated to disable these versions within 30 days, the maximum risk in the environment.
3. TLS 1.3 enablement on all servers: TLS 1.3 is enabled alongside TLS 1.2 on all servers. Modern browsers and API clients immediately begin using TLS 1.3; legacy clients continue using TLS 1.2.
4. TLS 1.2 cipher suite hardening: all RSA key exchange and CBC cipher suites are disabled on TLS 1.2 configurations. Only ECDHE-AEAD suites remain enabled, providing forward secrecy for TLS 1.2 connections during the transition period.
5. Certificate migration: RSA-2048 certificates are migrated to ECDSA P-256 on certificate renewal, using CertSecure Manager to automate renewal and track inventory. ECDSA P-256 reduces TLS handshake size and certificate data volume.
6. TLS 1.2 retirement planning: access log analysis shows TLS 1.2 usage dropping month-over-month as clients update. A plan is set to disable TLS 1.2 once usage falls below 1% of connections, expected within 12 months.

Key Management Dependencies for TLS

• TLS private key protection: the TLS server’s private key is the most sensitive component in a TLS deployment. Compromise of this key allows decryption of past sessions without forward secrecy (TLS 1.2 RSA key exchange) and enables server impersonation. Store TLS private keys in FIPS 140-2 Level 2 or higher HSMs or hardware key stores where possible. See HSM as a Service.
• Certificate lifecycle automation: TLS certificates are machine identities with expiry dates. Manual certificate management at scale fails: the CA/Browser Forum has mandated certificate lifetimes dropping to 47 days by 2029. CertSecure Manager automates discovery, renewal, and policy enforcement across all TLS certificate inventory.
• Certificate algorithm currency: RSA-2048 certificates are proposed for deprecation after 2030 per NIST IR 8547. Organizations should be issuing ECDSA P-256 certificates for all new deployments and migrating RSA certificates on renewal.

Migration Challenges

• Legacy system incompatibility: older systems, embedded devices, and some enterprise middleware may not support TLS 1.3. These require updates or replacement, which can be costly for industries with heavy legacy infrastructure.
• RSA key exchange removal: TLS 1.3’s elimination of RSA key exchange breaks systems that depend on it. Network inspection appliances that perform TLS inspection by intercepting and re-signing connections may need reconfiguration to work with TLS 1.3’s ephemeral key exchange.
• Handshake changes requiring application updates: TLS 1.3’s modified handshake and session resumption mechanisms require updates to application logic in systems with complex authentication or connection flows.
• Balancing backward compatibility during transition: maintaining TLS 1.2 alongside TLS 1.3 during the migration period is necessary but temporary. TLS 1.2 with ECDHE-AEAD suites provides acceptable security during transition; plain TLS 1.2 with RSA key exchange does not and should be disabled even while TLS 1.2 is maintained.

How Encryption Consulting Can Help

At Encryption Consulting, we help organizations address TLS migration challenges with customized solutions matched to their specific infrastructure. Our services cover TLS configuration assessment and audit (identifying weak cipher suites, deprecated protocol versions, and certificate gaps across your environment), migration planning and implementation (structured approach to enabling TLS 1.3 and retiring weaker configurations with minimal service disruption), and certificate lifecycle management via CertSecure Manager (automating discovery, renewal, and policy enforcement for TLS certificates, including the upcoming 47-day certificate lifetime requirement). Our PKI Services also cover the certificate authority infrastructure that issues TLS certificates, ensuring the trust chain is properly designed and governed.

Conclusion

TLS is the foundational protocol securing data in transit across the internet. TLS 1.3 is the current standard: faster than TLS 1.2, mandatory forward secrecy, encrypted handshake, and no legacy algorithm baggage. Organizations should enable TLS 1.3 on all servers immediately, disable TLS 1.0 and 1.1 without delay, harden TLS 1.2 to ECDHE-AEAD suites only during the transition period, and plan for TLS 1.2 retirement once legacy client analysis confirms it is no longer needed.

The certificate dimension of TLS management is intensifying: 47-day certificate lifetimes by 2029 require automated lifecycle management rather than manual tracking. The algorithm dimension is also moving: RSA-2048 certificates face proposed deprecation after 2030, making ECDSA P-256 the right choice for all new TLS certificate issuance now. For related content, see our guides on Understanding ECC and SSL/TLS Certificates.

Frequently Asked Questions

What is TLS and what does it protect?

TLS is a cryptographic protocol providing confidentiality, integrity, and authentication for network data. It protects data from eavesdropping (encryption), tampering (integrity via AEAD), and impersonation (server certificate authentication via CA). Used in HTTPS, SMTP, IMAP, API traffic, database connections, and VPN protocols.

What is the difference between TLS 1.2 and TLS 1.3?

TLS 1.3 is faster (1-RTT vs 2-RTT), mandates forward secrecy via ECDHE, permits only 5 AEAD cipher suites (vs hundreds in TLS 1.2 including weak ones), encrypts more of the handshake, and removes all legacy algorithms (RC4, 3DES, RSA key exchange, CBC, compression) that were attack vectors in TLS 1.2.

What cipher suites should be used with TLS 1.2?

NIST SP 800-52 Rev. 2 recommends ECDHE-AEAD suites: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 are preferred. Disable all RSA key exchange suites (no forward secrecy), all RC4/DES/3DES suites, MD5/SHA-1 suites, and CBC suites where possible.

What is forward secrecy and why does TLS 1.3 require it?

Forward secrecy means compromising the long-term TLS private key cannot decrypt past sessions, because session keys were ephemeral. TLS 1.3 mandates this via ECDHE for all connections. Without forward secrecy (TLS 1.2 RSA key exchange), an attacker recording today’s traffic can decrypt it retroactively if they later obtain the private key.

How should organizations migrate from TLS 1.2 to TLS 1.3?

Enable TLS 1.3 on all servers alongside TLS 1.2 (not instead of it). Immediately disable TLS 1.0 and 1.1. Harden TLS 1.2 to ECDHE-AEAD suites only. Monitor TLS protocol distribution in access logs. Plan TLS 1.2 retirement once monitoring shows minimal usage by active clients.

Which attacks affect TLS 1.2 and are they fixed in TLS 1.3?

BEAST, POODLE, and similar attacks exploited TLS 1.2’s support for CBC cipher suites and weak algorithms. TLS 1.3 removes CBC cipher suites entirely, eliminating these attack classes. Raccoon targeted DHE; TLS 1.3 uses only ECDHE. CRIME exploited compression; TLS 1.3 removes compression. TLS 1.3 is not immune to implementation flaws but eliminates the vulnerable primitives that enabled most known protocol-level attacks.