Generated by DeepSeek V3.2| Transport Layer Security | |
|---|---|
| Name | Transport Layer Security |
| Designer | Internet Engineering Task Force |
| Publish date | 1999 |
| Derived from | Secure Sockets Layer |
| Key size | 2048–4096 bits (RSA), 256 bits (ECC) |
| Cipher | AES, ChaCha20 |
| Hash | SHA-2 |
| Certification | FIPS 140-2, Common Criteria |
Transport Layer Security. It is a cryptographic protocol designed to provide communications security over a computer network, widely deployed in applications such as web browsing, email, instant messaging, and voice over IP. The protocol aims primarily to provide privacy, data integrity, and authentication between two or more communicating computer applications. It evolved from the earlier Secure Sockets Layer protocol and is standardized by the Internet Engineering Task Force.
The protocol operates between the application layer and the transport layer of the Internet protocol suite, often securing the Hypertext Transfer Protocol to become HTTPS. A primary use case is securing data transmission between a user's web browser and a website, ensuring that sensitive information like login credentials or credit card numbers remains confidential. It utilizes a combination of symmetric-key cryptography for bulk encryption and public-key cryptography for key exchange and authentication. The connection establishment phase, known as the handshake protocol, involves negotiation of cryptographic parameters and verification of the server's identity, typically through a digital certificate issued by a trusted certificate authority like DigiCert or Let's Encrypt.
The handshake begins with the client sending a `ClientHello` message specifying supported cipher suites and a random value. The server responds with a `ServerHello` selecting a cipher suite, its own random value, and sends its X.509 certificate; for mutual authentication, it may also request the client's certificate. Following this, key exchange occurs using methods such as RSA, the Diffie–Hellman key exchange, or its elliptic-curve cryptography variant, ECDH. Subsequent messages compute the pre-master secret and derive the master secret, which generates symmetric keys for algorithms like Advanced Encryption Standard or ChaCha20-Poly1305. The record protocol then fragments, compresses, encrypts, and authenticates application data using a Message Authentication Code like HMAC or an authenticated encryption mode.
The protocol is designed to be a secure channel that provides protection against eavesdropping, tampering, and message forgery. Forward secrecy, a critical property, is achieved when using Ephemeral Diffie-Hellman or Elliptic-curve Diffie–Hellman key exchanges, ensuring that past sessions remain secure even if long-term private keys are compromised. Resistance to known attacks like BEAST, CRIME, and POODLE has been addressed in modern versions. However, vulnerabilities can arise from implementation flaws, weak cipher suites, or compromised certificate authorities, as seen in incidents involving DigiNotar and Comodo Group. The protocol does not inherently hide metadata such as the identities of the communicating parties or the amount of data transferred.
The protocol was first defined in 1999 as TLS 1.0, an upgrade of SSL 3.0 developed by Netscape Communications Corporation. TLS 1.1, published in 2006, added protection against CBC mode attacks. TLS 1.2, introduced in 2008, deprecated weak algorithms and made SHA-2 the default hash function. The current version, TLS 1.3, was finalized in 2018 by the IETF and brought significant security and performance improvements, including a simplified handshake, mandatory forward secrecy, and the removal of support for obsolete features like RSA key transport and SHA-1. The deprecation of older versions has been advocated by major organizations including the National Institute of Standards and Technology and the Payment Card Industry Security Standards Council.
Beyond securing HTTP for World Wide Web traffic, the protocol is fundamental to many other applications. It secures email transmission via protocols like SMTP, IMAP, and POP3, often referred to as STARTTLS. It is used in virtual private networks such as OpenVPN, for securing Session Initiation Protocol signaling in VoIP, and in instant messaging protocols like XMPP. Major software vendors, including Microsoft, Google, Apple Inc., and Mozilla Foundation, have implemented support in their operating systems and applications. Widespread adoption has been driven by initiatives like Let's Encrypt, which provides free certificates, and enforcement by browsers such as Google Chrome and Mozilla Firefox which mark non-secure sites prominently.
Deploying the protocol requires careful configuration to avoid security pitfalls. Administrators must select strong cipher suites, disable outdated versions like SSL 2.0 and TLS 1.0, and ensure proper certificate management, including timely renewal and use of sufficiently strong key sizes like RSA 2048 or ECC 256. Performance overhead can be mitigated using techniques like TLS session resumption or False Start. Libraries providing implementations include OpenSSL, used by projects like Apache HTTP Server and nginx, and alternatives such as GnuTLS, BoringSSL, and LibreSSL. Testing and validation tools, such as Qualys SSL Labs scanner, help assess configuration security against threats like Heartbleed or DROWN.
Category:Cryptographic protocols Category:Internet standards Category:Computer security