TLS:修订间差异
(未显示同一用户的7个中间版本) | |||
第14行: | 第14行: | ||
Many of the major vulnerabilities in TLS 1.2 had to do with older cryptographic algorithms that were still supported. TLS 1.3 drops support for these vulnerable cryptographic algorithms, and as a result it is less vulnerable to cyber attacks. | Many of the major vulnerabilities in TLS 1.2 had to do with older cryptographic algorithms that were still supported. TLS 1.3 drops support for these vulnerable cryptographic algorithms, and as a result it is less vulnerable to cyber attacks. | ||
= Overview= | |||
Internally, TLS is a layered protocol: | |||
<syntaxhighlight lang="bash"> | |||
+-------------+------------+--------------+---------+ | |||
Content | | | Application | | | |||
Layer | Handshake | Alerts | Data | ... | | |||
| | | | | | |||
+-------------+------------+--------------+---------+ | |||
Record | | | |||
Layer | Records | | |||
| | | |||
+---------------------------------------------------+ | |||
</syntaxhighlight> | |||
Each content-layer message (e.g., handshake, alerts, and application data) is carried as a series of typed TLS records by the record layer. Records are individually cryptographically protected and then transmitted over a reliable transport (typically TCP), which provides sequencing and guaranteed delivery. | |||
TLS supports both pre-shared key (PSK) and Diffie-Hellman over either finite fields or elliptic curves ((EC)DHE) key exchanges. PSK is the basis for Early Data (0-RTT); the latter provides forward secrecy (FS) when the (EC)DHE keys are destroyed. | |||
TLS provides two basic handshake modes of interest to QUIC: | |||
* A full <syntaxhighlight lang="bash" inline>1-RTT</syntaxhighlight> handshake, in which the client is able to send application data after one round trip and the server immediately responds after receiving the first handshake message from the client. | |||
* A <syntaxhighlight lang="bash" inline>0-RTT</syntaxhighlight> handshake, in which the client uses information it has previously learned about the server to send application data immediately. This application data can be replayed by an attacker, so 0-RTT is not suitable for carrying instructions that might initiate any action that could cause unwanted effects if replayed. | |||
== 1-RTT == | |||
== 0-RTT == | |||
<syntaxhighlight lang="bash"> | |||
Client Server | |||
ClientHello | |||
(0-RTT Application Data) --------> | |||
ServerHello | |||
{EncryptedExtensions} | |||
{Finished} | |||
<-------- [Application Data] | |||
{Finished} --------> | |||
[Application Data] <-------> [Application Data] | |||
() Indicates messages protected by Early Data (0-RTT) Keys | |||
{} Indicates messages protected using Handshake Keys | |||
[] Indicates messages protected using Application Data | |||
(1-RTT) Keys | |||
</syntaxhighlight> | |||
== Handshake == | == Handshake == | ||
[[Image:tls1.3-handshake. | |||
[[Image:tls1.3-handshake.webp|600px]]<ref>https://www.a10networks.com/glossary/key-differences-between-tls-1-2-and-tls-1-3/</ref> | |||
== Key exchange == | |||
It recommends support for [[X25519]], Ed25519, X448, and Ed448 algorithms.<ref>[https://datatracker.ietf.org/doc/html/rfc8446 RFC8446 - The Transport Layer Security (TLS) Protocol Version 1.3]</ref> | |||
[[Category:Network]] | [[Category:Network]] |
2024年2月1日 (四) 10:56的最新版本
Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.
- SSL 3.0 1996 Deprecated in 2015 (RFC 7568)
- TLS 1.2 2008 In use since 2008
- TLS 1.3 2018 In use since 2018
TLS 1.3
TLS 1.3 is the latest version of the TLS protocol. TLS, which is used by HTTPS and other network protocols for encryption, is the modern version of SSL. TLS 1.3 dropped support for older, less secure cryptographic features, and it sped up TLS handshakes, among other improvements.
TLS 1.3 was defined in RFC 8446 in August 2018. It is based on the earlier TLS 1.2 specification. Major differences from TLS 1.2 include:
In a nutshell, TLS 1.3 is faster and more secure than TLS 1.2. One of the changes that makes TLS 1.3 faster is an update to the way a TLS handshake works: TLS handshakes in TLS 1.3 only require one round trip (or back-and-forth communication) instead of two, shortening the process by a few milliseconds. And in cases when the client has connected to a website before, the TLS handshake will have zero round trips. This makes HTTPS connections faster, cutting down latency and improving the overall user experience[1].
Many of the major vulnerabilities in TLS 1.2 had to do with older cryptographic algorithms that were still supported. TLS 1.3 drops support for these vulnerable cryptographic algorithms, and as a result it is less vulnerable to cyber attacks.
Overview
Internally, TLS is a layered protocol:
+-------------+------------+--------------+---------+
Content | | | Application | |
Layer | Handshake | Alerts | Data | ... |
| | | | |
+-------------+------------+--------------+---------+
Record | |
Layer | Records |
| |
+---------------------------------------------------+
Each content-layer message (e.g., handshake, alerts, and application data) is carried as a series of typed TLS records by the record layer. Records are individually cryptographically protected and then transmitted over a reliable transport (typically TCP), which provides sequencing and guaranteed delivery.
TLS supports both pre-shared key (PSK) and Diffie-Hellman over either finite fields or elliptic curves ((EC)DHE) key exchanges. PSK is the basis for Early Data (0-RTT); the latter provides forward secrecy (FS) when the (EC)DHE keys are destroyed.
TLS provides two basic handshake modes of interest to QUIC:
- A full
1-RTT
handshake, in which the client is able to send application data after one round trip and the server immediately responds after receiving the first handshake message from the client. - A
0-RTT
handshake, in which the client uses information it has previously learned about the server to send application data immediately. This application data can be replayed by an attacker, so 0-RTT is not suitable for carrying instructions that might initiate any action that could cause unwanted effects if replayed.
1-RTT
0-RTT
Client Server
ClientHello
(0-RTT Application Data) -------->
ServerHello
{EncryptedExtensions}
{Finished}
<-------- [Application Data]
{Finished} -------->
[Application Data] <-------> [Application Data]
() Indicates messages protected by Early Data (0-RTT) Keys
{} Indicates messages protected using Handshake Keys
[] Indicates messages protected using Application Data
(1-RTT) Keys
Handshake
Key exchange
It recommends support for X25519, Ed25519, X448, and Ed448 algorithms.[3]