This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Transport Layer Security
Transport Layer Security

Version management

Difference between version and

At line 1 added 51 lines
!!! Overview
[{$pagename}] is the degree of resistance to encountering an [Unfortunate event] at the [Transport Layer][{$pagename}] [(TLS)] is also, and most often, the [Standard] [Transport-layer Security Mechanism] [protocol] for creating [secure connection] between a [client] and a [server] at the [Transport Layer]
[{$pagename}] is an improved and standardized form of the [Secure Socket Layer] ([SSL]).!! Introduction
The primary goal of [{$pagename}] is to provide a [secure channel|Secure connection] between two communicating peers; the only requirement from the underlying transport is a reliable, in-order, data stream.
Specifically, the [secure channel|Secure connection] 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].
These properties should be true even in the face of an [attacker] who has complete control of the network, as described in [Internet Threat Model] ([BCP 72]).
[{$pagename}] consists of two primary components:
* A [handshake|TLS Handshake] [protocol] that authenticates the communicating parties, negotiates [cryptographic] modes and [parameters], and establishes shared keying material. The [handshake|TLS 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|TLS Handshake] protocol to protect [network traffic] between the communicating peers. The [Record Protocol] divides [network traffic] up into a series of records, each of which is independently protected using the traffic [keys].
[{$pagename}] is [application] [protocol] independent; higher-level [protocols] can layer on top of TLS transparently. The [TLS] standard, however, does not specify how protocols add security with TLS; how to initiate TLS handshaking and how to interpret the [authentication] [certificates] exchanged are left to the judgment of the designers and implementers of [protocols] that run on top of [TLS].
!! [Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)]
[Transport Layer Security] ([{$pagename}]) 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|https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS|target='_blank'], 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].
[{$pagename}] is a [protocol] created to provide [authentication], [confidentiality], and [data] [integrity] protection between two communicating [applications]. [{$pagename}] is based on a precursor protocol called the [Secure Socket Layer] Version 3.0 ([SSLv3]) and is considered to be an improvement to [SSLv3].
* [{$pagename}] [version] 1 ([TLS 1.0]) is specified in [RFC 2246]. Each document specifies a similar protocol that provides security services over the Internet.
* [{$pagename}] version 1.1 ([TLS 1.1]) is specified in [RFC 4346]
* [{$pagename}] version 1.2 ([TLS 1.2]) is specified in [RFC 5246]
* [TLS extensions] have been specified to mitigate some of the known security [vulnerabilities|Vulnerability] in [implementations] above have also been
* [{$pagename}] version 1.3 ([TLS 1.3]) is specified in [RFC 8446] is a significant update to previous versions that includes protections against security concerns that arose in previous [versions] of [TLS]
They are internally very similar with each other, and with [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.
Still internally, all versions are designated by a version number with the major.minor format; [SSLv3] is then 3.0, while the [TLS] versions are, respectively, 3.1, 3.2 and 3.3.
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 Protocol Limitations]
In addition to [Exploits] against [{$pagename}], there are also some fundamental [TLS Protocol Limitations].
!! [How SSL-TLS Works]
In [LDAP] TLS is implemented by the usage of the [StartTLS] or using [LDAPS] __which does NOT imply__ [SSL].
!! [TLS Maturity Model]
!! [Server-side TLS configuration guide]
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop