What is TLS 1.2?
TLS 1.2 is the version of the Transport Layer Security protocol defined in RFC 5246 that was the dominant cryptographic handshake standard for internet security from 2008 through the late 2010s.
TLS 1.2 is a cryptographic protocol that provides authenticated, encrypted communication over a network. Published in August 2008 as RFC 5246, it succeeded TLS 1.1 and remained the most widely deployed TLS version until TLS 1.3 began achieving broad adoption around 2020. It is still supported by virtually all web servers and clients, though usage is declining.
The protocol works in two phases. First, a handshake establishes cipher suites, authenticates the server (and optionally the client) using X.509 certificates, and exchanges key material. TLS 1.2 introduced several improvements over TLS 1.1, including support for authenticated encryption with associated data (AEAD) cipher suites like AES-GCM, removal of the implicit Initialization Vector from CBC modes, and greater flexibility in the cryptographic negotiation through the extension mechanism. The handshake is deterministic but incurs two round trips, which TLS 1.3 later reduced to one.
In the wider internet stack, TLS 1.2 sits between the transport layer (TCP) and the application layer (HTTP, SMTP, etc.). It is the minimum version required by PCI DSS compliance mandates and is still used by a significant fraction of web traffic, legacy enterprise systems, and mail servers. Many organizations have begun migrating to TLS 1.3 for its performance and security improvements, but TLS 1.2 remains the baseline for interoperability with older clients and embedded devices.
Key facts
- Defined in RFC 5246, published August 2008.
- Supports AEAD cipher suites such as AES-GCM and ChaCha20-Poly1305.
- Eliminated the implicit Initialization Vector from older CBC modes.
- Requires a two-round-trip handshake before encrypted data flows.
- Remains the baseline version for PCI DSS compliance and many enterprise deployments.
How it works in practice
Related terms
References
More in TLS & PKI
ACME Protocol
ACME (Automated Certificate Management Environment) is a protocol that automates the issuance, renewal, and revocation of TLS certificates, defined in RFC 8555.
Certificate Authority
A Certificate Authority (CA) is a trusted entity that issues digital certificates after verifying that the requester controls the domain or identity named in the certificate.
Certificate Chain
A certificate chain is an ordered list of certificates, starting with the server certificate and ending with a root CA, that a client validates to establish trust in the server's identity.
Certificate Pinning
A security technique where an application trusts only a specific, pre-selected certificate or public key for a given server, bypassing the standard chain of trust.
Cipher Suite
A cipher suite is a named set of cryptographic algorithms negotiated during a TLS handshake, specifying key exchange, authentication, encryption, and integrity protection for secure communications.
Domain Validation
Domain Validation (DV) is the lowest level of certificate validation used in TLS/SSL, where the certificate authority verifies only that the applicant controls the domain name, typically via an HTTP or DNS challenge.
ECH
Encrypted Client Hello (ECH) is a TLS extension that encrypts the Client Hello message, including the Server Name Indication (SNI), to prevent on-path observers from learning the target hostname during the handshake.
Extended Validation
Extended Validation (EV) is the highest level of TLS certificate assurance, requiring the certificate authority to perform rigorous, human-verified checks on the legal identity and operational existence of the requesting organization before issuance.
HSTS
HTTP Strict Transport Security (HSTS) is a web security policy mechanism that forces browsers to interact with a website only over HTTPS, preventing downgrade attacks and cookie hijacking.
Intermediate Certificate
An intermediate certificate is a subordinate CA certificate signed by a root CA, used to sign end-entity certificates and enable path validation while the root remains offline.