TLS
In plain English
Plain definition
TLS (Transport Layer Security) is the cryptographic protocol used to secure network communications; this entry defines the term, its handshake mechanics, common misconfigurations and safe verification practice.
Technical Definition
TLS operates above the transport layer, typically carried over TCP, and establishes a secured channel through a handshake that negotiates a protocol version and cipher suite, performs key exchange, authenticates an endpoint (commonly the server, via an X.509 certificate), and derives session keys used to symmetrically encrypt subsequent application data. Standardisation of the protocol is managed through the Internet Engineering Task Force’s RFC Series, described by the RFC Editor as an authoritative publication channel for Internet technical specifications. Multiple TLS protocol versions have been published over time; the exact version and cipher suite negotiated by a specific implementation should be confirmed directly against the deployed stack rather than assumed from this entry.
Operational Relevance
TLS underpins the majority of secured web traffic (HTTPS) and many other protocols, including mail submission and retrieval, and internal service-to-service traffic. Practitioners are typically responsible for verifying:
- Which protocol versions are permitted by a given service or client
- Which cipher suites are enabled or disabled
- Whether certificates are correctly issued, chained and unexpired
- How the handshake behaves under normal and abnormal conditions
Because TLS misconfiguration is a common and often silent source of insecure or broken connections, treat its state as something to actively verify rather than assume.
Architecture Relationship
TLS sits between the transport layer and application layer in conventional network stacks, wrapping application protocols so they do not need to implement cryptography directly. It depends on the reliability of lower layers and interacts with certificate authorities, key stores and revocation infrastructure to establish endpoint trust. Architectural decisions such as where TLS is terminated (load balancer versus origin server), which certificate authorities are trusted, and how session keys and certificates are rotated all materially affect the security guarantees a given deployment actually delivers.
Example
A read-only diagnostic check can be used to observe negotiated TLS parameters without altering any configuration state:
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/nullExpected output includes the negotiated protocol version, the cipher suite selected, and the presented certificate chain. This command performs no state change and is safe to run against any endpoint you are authorised to query.
Misunderstanding
A common misunderstanding treats “using TLS” as a binary, all-or-nothing guarantee of security. In practice, the term covers many possible configurations — protocol version, cipher suite, certificate validation behaviour — that differ materially in the protection they actually provide. A connection using TLS with an expired or unvalidated certificate, or a deprecated cipher suite, does not deliver the same assurance as a well-configured deployment. A second, related misunderstanding conflates TLS with its deprecated predecessor SSL; the terms are related but not interchangeable in current practice, even though “SSL” persists informally.
Related Terms
- SSL
- X.509 certificate
- Certificate authority
- Cipher suite
- HTTPS
- Mutual TLS (mTLS)
Further Reading
Protocol specifications and revisions are published through the IETF RFC Series, maintained by the RFC Editor. Before relying on this entry to make a configuration change, confirm the exact protocol version and cipher suite policy currently required by your organisation, and validate any change first in an isolated or non-production environment using a read-only check such as the example above.