Overview #Transport Layer Security is the degree of resistance to encountering an Unfortunate event at the Transport Layer
Introduction#The primary goal of Transport Layer Security is to provide a secure channel between two communicating peers; the only requirement from the underlying transport is a reliable, in-order, data stream.
Specifically, the secure channel should provide the following properties:
- Authentication: The server side of the channel is always authenticated; the client side is optionally authenticated. Authentication can happen via Asymmetric Key Cryptography (e.g., RSA, ECDSA, EdDSA) or a Pre-Shared Key (PSK).
- Confidentiality: Data sent over the channel after establishment is only visible to the endpoints. TLS does not hide the length of the data it transmits, though endpoints are able to pad TLS records in order to obscure lengths and improve protection against traffic analysis techniques.
- Integrity: Data sent over the channel after establishment cannot be modified by attackers.
Transport Layer Security consists of two primary components:
- A handshake protocol that authenticates the communicating parties, negotiates cryptographic modes and parameters, and establishes shared keying material. The handshake protocol is designed to resist tampering; an Active attacker should not be able to force the peers to negotiate different parameters than they would if the connection were not under attack.
- A Record Protocol that uses the parameters established by the handshake protocol to protect traffic between the communicating peers. The Record Protocol divides traffic up into a series of records, each of which is independently protected using the traffic keys.
Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)#Transport Layer Security (Transport Layer Security) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are applicable to the majority of use cases.
History#SSL-TLS is a protocol with a long history and several versions. First prototypes came from Netscape, when they were developing the first versions of their flagship browser, Netscape Navigator (this browser killed off Mosaic in the early times of the Browser Wars, which are still raging, albeit with new competitors).
SSL Version 1 has never been made public so we do not know how it looked like. SSL version 2 (SSLv2), is described in a draft, had a number of weaknesses, some of them rather serious, so it is deprecated (RFC 6176) and newer SSL-TLS implementations do not support it (while older deactivated by default).
SSLv3 version 3 was an enhanced protocol which still works today and is widely supported. Although still a property of Netscape Communications (or whoever owns that nowadays), the protocol has been published as an "historical RFC" RFC 6101. Meanwhile, the protocol was standardized, with a new name in order to avoid legal issues, the new name is TLS.SSLv3, to the point that an implementation can easily support SSLv3 and all three TLS versions with at least 95% of the code being common.
Thus, it is no wonder that TLS 1.0 is sometimes called SSL 3.1 (and it is not incorrect either). SSL 3.0 and TLS 1.0 differ by only some minute details. TLS 1.2 is becoming widely supported, although there is impetus for that, because of possible weaknesses (see below, for the "BEAST attack"). TLS 1.0 are supported nearly "everywhere". TLS 1.3 is still an Internet DraftExploits against Transport Layer Security, there are also some fundamental TLS Protocol Limitations. LDAP TLS is implemented by the usage of the StartTLS or using LDAPS which does NOT imply SSL.
More Information#There might be more information for this subject on one of the following:
- Application-Layer Protocol Negotiation
- Authenticated Protected Channel
- Best Practices for LDAP Security
- Certificate Transparency
- Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)
- DNS over TLS
- DNS-Based Authentication of Named Entities
- Data In Transit
- Diffie-Hellman Ephemeral
- End-to-end Encryption
- How SSL-TLS Works
- Information security
- Internet Protocol Security
- LDAP Result Codes
- LDAP Server Standards and Specifications
- Lucky 13
- Mutual TLS Profiles for OAuth Clients
- OAuth 2.0 Dynamic Client Registration Management Protocol
- OAuth 2.0 Message Authentication Code (MAC) Tokens
- OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens
- Protected Extensible Authentication Protocol
- RFC 3749
- RFC 4492
- RFC 5246
- RFC 5489
- RFC 5705
- RFC 6125
- RFC 6460
- RFC 6698
- RFC 6961
- RFC 7301
- RFC 7672
- RFC 7919
- RFC 8446
- RFC 8472
- Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
- Schannel SSP
- Secure connection
- Security Support Provider Interface
- Supported Groups Registry
- TLS 1.3
- Token Binding Protocol Negotiation
- Transport Layer Security
- Transport-layer Security Mechanism