Transport Layer Security (TLS) is a critical protocol for ensuring secure communication over the internet. It’s the technology that underpins HTTPS, the secure version of HTTP, and is essential for protecting data as it travels between web browsers and servers. TLS works by encrypting the connection between these points, preventing eavesdropping and ensuring data integrity. To achieve this security, TLS employs a sophisticated blend of cryptographic techniques, balancing robust protection with efficient performance. Let’s delve into the mechanics of TLS and explore how it safeguards our online interactions.
TLS leverages both symmetric and asymmetric cryptography, a combination that provides an optimal balance between speed and security for data transmission.
Symmetric cryptography uses a single secret key to both encrypt and decrypt data. This key must be known to both the sender and the recipient. Strong symmetric encryption algorithms typically use key lengths of 128 or preferably 256 bits. Keys shorter than 80 bits are now considered vulnerable to attacks. Symmetric cryptography is computationally efficient, making it ideal for encrypting large volumes of data quickly. However, the challenge lies in securely sharing the secret key between communicating parties before any encrypted data is exchanged.
Asymmetric cryptography, on the other hand, employs key pairs: a public key and a private key. These keys are mathematically linked, but deriving the private key from the public key is computationally infeasible given sufficiently long keys. In asymmetric encryption, the sender uses the recipient’s public key to encrypt data. Crucially, this encrypted data can only be decrypted using the recipient’s corresponding private key.
The primary advantage of asymmetric cryptography is that secure key exchange is simplified. Public keys can be shared openly without compromising security. However, this security comes at the cost of computational intensity. Asymmetric cryptography requires much longer key lengths compared to symmetric cryptography to achieve equivalent security strength. While a 1024-bit key is a minimum recommendation, 2048 bits is preferred. This increased key length makes asymmetric encryption significantly slower – up to a thousand times more computationally intensive than symmetric encryption with comparable security (e.g., a 2048-bit asymmetric key offers security roughly equivalent to a 112-bit symmetric key). Due to this performance overhead, pure asymmetric encryption is often impractical for encrypting entire communication sessions.
To reconcile security and performance, TLS uses asymmetric cryptography for the initial secure handshake process, specifically for generating and exchanging a symmetric session key. This session key is then used for the duration of the communication session to encrypt and decrypt the actual data being transmitted. Once the session ends, the session key is discarded, enhancing security by limiting the window of opportunity for key compromise.
Several key exchange methods are employed within TLS, including RSA, Diffie-Hellman (DH), Ephemeral Diffie-Hellman (DHE), Elliptic Curve Diffie-Hellman (ECDH), and Ephemeral Elliptic Curve Diffie-Hellman (ECDHE). DHE and ECDHE offer an important security feature known as forward secrecy. Forward secrecy ensures that even if one of the private keys is compromised in the future, past session keys remain secure. This is because DHE and ECDHE generate unique session keys for each session, and these keys are not derivable from the long-term private keys.
However, it’s important to note that the strength of even forward secrecy mechanisms can be undermined by weaknesses in random number generation or the use of a limited set of prime numbers in the key exchange process. It has been theorized that state-level actors with vast computing resources might be able to crack even 1024-bit DH keys under such conditions. Nevertheless, these potential vulnerabilities are often considered implementation issues rather than fundamental protocol flaws. Tools are available to test for weak cipher suites and ensure robust TLS configurations.
Beyond encryption, TLS also addresses the crucial aspect of server identity verification. When a client connects to a server, TLS aims to provide assurance that the server’s public key genuinely belongs to the intended server and not to a malicious imposter. This validation is typically achieved through X.509 digital certificates issued by trusted third-party organizations known as Certificate Authorities (CAs).
A digital certificate acts as an electronic identity card for a website or server. It contains the server’s public key and is digitally signed by a CA. By verifying the CA’s signature on the certificate, a client can gain confidence in the authenticity of the server’s public key. In certain situations, a server might utilize a self-signed certificate. While this eliminates the need for a CA, it requires the client to explicitly trust this certificate. Browsers typically display warnings when encountering untrusted self-signed certificates, as they do not offer the same level of assurance as CA-issued certificates. Self-signed certificates might be acceptable in private networks or controlled environments where secure certificate distribution is possible, but for public-facing websites, using certificates from publicly trusted CAs is strongly recommended.
Understanding Certificate Authorities (CAs)
A Certificate Authority (CA) plays a pivotal role in the TLS ecosystem. It is an organization that issues digital certificates that comply with the International Telecommunication Union’s (ITU-T) X.509 standard for Public Key Infrastructures (PKIs). These digital certificates serve to certify that the public key included in the certificate belongs to the certificate’s owner (the subject) and that the owner legitimately controls the domain being secured by the certificate. In essence, a CA acts as a trusted intermediary, providing relying parties (clients) with assurance that they are connecting to a server operated by a verified entity.
The validity of end-entity certificates is established through a chain of trust that originates from a root certificate, often referred to as the trust anchor. Asymmetric cryptography allows the private key of the root certificate to sign intermediate certificates, which in turn can sign end-entity certificates. Because they are signed by a certificate in the chain, end-entity certificates inherit the trust associated with the root CA. In practice, end-entity certificates are often signed by one or more intermediate certificates (also known as subordinate or sub-CAs). This layered approach enhances security by protecting the root certificate; if an end-entity certificate is compromised or incorrectly issued, the root certificate remains secure.
Trust in root certificates is typically established through their distribution within operating systems and web browsers. Major certification programs are operated by companies like Microsoft (Windows & Windows Phone), Apple (macOS & iOS), and Mozilla (Firefox & Linux). These programs impose stringent technical and audit requirements on CAs seeking to have their root certificates included in these distributions. CAs typically need to undergo audits such as WebTrust, ETSI EN 319 411-3 (formerly TS 102 042), or ISO 21188:2006 to meet these requirements. WebTrust is a program developed jointly by the American Institute of Certified Public Accountants and the Canadian Institute of Chartered Accountants. ETSI is the European Telecommunications Standards Institute, and ISO is the International Standards Organisation.
Root certificates distributed with major operating systems and browsers are considered publicly or globally trusted. The rigorous technical and audit standards effectively mean that publicly trusted CAs are typically multinational corporations or governmental organizations. Currently, there are approximately fifty publicly trusted CAs, many of which operate multiple root certificates and are members of the CA/Browser Forum, an industry body that develops guidelines for certificate issuance and management.
Beyond public CAs, private CAs can also be established. Trust in private CAs is established through secure distribution and installation of their root certificates on client systems. Examples of private CAs include the RPKI CAs operated by Regional Internet Registries (AfriNIC, APNIC, ARIN, LACNIC, and RIPE NCC), which issue certificates to Local Internet Registries to verify their IP address and Autonomous System (AS) number holdings. Another example is the International Grid Trust Federation (IGTF), which provides a trust anchor for issuing server and client certificates used in distributed scientific computing environments. In these cases, root certificates for private CAs are often securely downloadable from websites that themselves use certificates issued by publicly trusted CAs.
A known weakness of the X.509 PKI system is that CAs have the ability to issue certificates for any domain, regardless of whether the requesting entity actually owns or controls that domain. Domain validation, a common validation method, often involves sending an email with a verification link to an address associated with the domain, such as ‘hostmaster@domain’ or the technical contact listed in a WHOIS database. This approach is vulnerable to man-in-the-middle attacks targeting DNS or BGP protocols or simply to malicious actors registering administrative addresses on unreserved domains. Furthermore, Domain Validated (DV) certificates, while widely used, do not provide any assurance about the legal entity associated with a domain, even if a domain name might suggest one.
To address these limitations, CAs are increasingly promoting the use of Organisation Validated (OV) and Extended Validation (EV) certificates. OV certificates require additional verification steps, such as confirming the organization’s name, address, and phone number using public databases. EV certificates involve even more rigorous checks, including verification of legal establishment, physical location, and the identity of individuals acting on behalf of the requesting organization.
Despite these enhanced validation methods, the risk of CAs inadvertently or fraudulently issuing incorrect certificates remains. There have also been security incidents where CAs were compromised and tricked into issuing fraudulent certificates. Although security procedures have been significantly strengthened following high-profile incidents, the system still relies on third-party trust. This reliance on trust has driven the development of alternative mechanisms like the DNS-based Authentication of Named Entities (DANE) protocol, specified in RFCs 6698, 7671, 7672, and 7673.
DANE allows domain administrators to directly assert control over their public keys by storing them in the DNS (Domain Name System), or by specifying which certificates should be accepted by clients. DANE relies on DNSSEC (Domain Name System Security Extensions), which cryptographically signs DNS records to ensure their integrity and authenticity. While DNSSEC adoption is growing, it is not yet universally deployed, and major browsers currently require add-ons to support DANE. Moreover, even with DANE, domain ownership validation will still be necessary, likely shifting the responsibility to domain registries and registrars instead of CAs.
