TLS1.3协议详解：互联网安全的新标准

PDF文件

下载需积分: 50 | 222KB | 更新于2024-07-20 | 99 浏览量 | 举报收藏

立即下载

"TLS1.3规范是网络工作小组(E. Rescorla)为RTFM, Inc.起草的一份互联网草案，旨在更新和替代之前的TLS 1.2及更早版本。该规范详细规定了Transport Layer Security (TLS)协议的第1.3版，用于在互联网上提供安全的客户端/服务器通信，防止窃听、篡改和消息伪造。此文档遵循BCP78和BCP79的规定，并且作为Internet-Draft，有效期最长为六个月，可能会随时更新、替换或过期。" **TLS 1.3协议概述** TLS（Transport Layer Security）协议是互联网上广泛使用的加密通信协议，它为应用程序提供了安全的数据传输层。TLS 1.3是其最新版本，相较于之前的版本（如TLS 1.2），它进行了许多优化和改进，以提高速度、安全性以及用户体验。 **主要改进** 1. **更快的握手**：TLS 1.3引入了一种被称为“0-RTT”（零往返时间）的握手模式，允许客户端在第一次连接后立即发送加密数据，显著减少了延迟。 2. **更强大的加密**：TLS 1.3弃用了较弱的加密套件，只支持前向安全的密码套件，如ChaCha20-Poly1305和AES-GCM，确保即使密钥被泄露，过去的通信记录也无法被解密。 3. **简化握手**：TLS 1.3将握手协议简化为两种类型——“完整握手”和“早期数据握手”，降低了握手过程中被中间人攻击的风险。 4. **前向安全性**：TLS 1.3确保了即使密钥被泄露，之前传输的数据仍然保持安全，因为每个会话都有独立的密钥。 5. **预共享密钥支持**：通过PSK（Pre-Shared Key）扩展，TLS 1.3支持已知密钥的快速重新连接，提高了性能和用户隐私。 6. **证书压缩**：为了减少传输开销，TLS 1.3支持证书压缩，尤其是对于大型证书链。 7. **安全默认值**：TLS 1.3设定了更严格的默认配置，避免了不安全的参数选择。 8. **密钥交换与签名算法的更新**：TLS 1.3弃用了一些较弱的密钥交换和签名算法，如RSA和SHA-1，转而支持更强的算法，如ECDHE和ECDSA。 9. **明文记录**：TLS 1.3不再在记录层进行MAC-then-encrypt操作，而是采用encrypt-then-MAC，以防止某些类型的攻击。 **安全性增强** 1. **防止重放攻击**：TLS 1.3引入了新的序列号机制，有效防止了重放攻击。 2. **防止中间人攻击**：通过前向安全和强制执行严格的证书验证，TLS 1.3增强了对中间人攻击的防护。 3. **防止密钥泄漏**：通过使用 HKDF（HMAC-based Extract-and-Expand Key Derivation Function）进行密钥派生，即使一个密钥被泄露，其他密钥也不会受到影响。 4. **防止 Padding Oracle 攻击**：TLS 1.3不再使用CBC（Cipher Block Chaining）模式，从而消除了填充 oracle 攻击的可能。 **结论** TLS 1.3规范是TLS协议的重要里程碑，它提升了网络安全标准，提供了更快、更安全的通信保障。由于其对旧版本的兼容性和向后兼容性，TLS 1.3正在逐渐成为互联网上的新标准。理解并实施TLS 1.3对于任何涉及敏感数据传输的应用程序和服务器都是至关重要的。

Internet-Draft TLS April 2017

2. Protocol Overview

The cryptographic parameters of the connection state are produced by

the TLS handshake protocol, which a TLS client and server use when

first communicating to agree on a protocol version, select

cryptographic algorithms, optionally authenticate each other, and

establish shared secret keying material. Once the handshake is

complete, the peers use the established keys to protect application

layer traffic.

A failure of the handshake or other protocol error triggers the

termination of the connection, optionally preceded by an alert

message (

Section 6).

TLS supports three basic key exchange modes:

- (EC)DHE (Diffie-Hellman, both the finite field and elliptic curve

varieties),

- PSK-only, and

- PSK with (EC)DHE

Figure 1 below shows the basic full TLS handshake:

Rescorla Expires October 30, 2017 [Page 16]

Internet-Draft TLS April 2017

Client Server

Key ^ ClientHello

Exch | + key_share*

| + signature_algorithms*

| + psk_key_exchange_modes*

v + pre_shared_key* -------->

ServerHello ^ Key

+ key_share* | Exch

+ pre_shared_key* v

{EncryptedExtensions} ^ Server

{CertificateRequest*} v Params

{Certificate*} ^

{CertificateVerify*} | Auth

{Finished} v

<-------- [Application Data*]

^ {Certificate*}

Auth | {CertificateVerify*}

v {Finished} -------->

[Application Data] <-------> [Application Data]

+ Indicates noteworthy extensions sent in the

previously noted message.

* Indicates optional or situation-dependent

messages/extensions that are not always sent.

{} Indicates messages protected using keys

derived from a [

sender]_handshake_traffic_secret.

[] Indicates messages protected using keys

derived from [

sender]_application_traffic_secret_N

Figure 1: Message flow for full TLS Handshake

The handshake can be thought of as having three phases (indicated in

the diagram above):

- Key Exchange: Establish shared keying material and select the

cryptographic parameters. Everything after this phase is

encrypted.

- Server Parameters: Establish other handshake parameters (whether

the client is authenticated, application layer protocol support,

etc.).

- Authentication: Authenticate the server (and optionally the

client) and provide key confirmation and handshake integrity.

Rescorla Expires October 30, 2017 [Page 17]

Internet-Draft TLS April 2017

In the Key Exchange phase, the client sends the ClientHello

(

Section 4.1.2) message, which contains a random nonce

(ClientHello.random); its offered protocol versions; a list of

symmetric cipher/HKDF hash pairs; some set of Diffie-Hellman key

shares (in the "key_share" extension

Section 4.2.7), a set of pre-

shared key labels (in the "pre_shared_key" extension

Section 4.2.10)

or both; and potentially some other extensions.

The server processes the ClientHello and determines the appropriate

cryptographic parameters for the connection. It then responds with

its own ServerHello (

Section 4.1.3), which indicates the negotiated

connection parameters. The combination of the ClientHello and the

ServerHello determines the shared keys. If (EC)DHE key establishment

is in use, then the ServerHello contains a "key_share" extension with

the server’s ephemeral Diffie-Hellman share which MUST be in the same

group as one of the client’s shares. If PSK key establishment is in

use, then the ServerHello contains a "pre_shared_key" extension

indicating which of the client’s offered PSKs was selected. Note

that implementations can use (EC)DHE and PSK together, in which case

both extensions will be supplied.

The server then sends two messages to establish the Server

Parameters:

EncryptedExtensions: responses to ClientHello extensions that are

not required to determine the cryptographic parameters, other than

those that are specific to individual certificates.

[

Section 4.3.1]

CertificateRequest: if certificate-based client authentication is

desired, the desired parameters for that certificate. This

message is omitted if client authentication is not desired.

[

Section 4.3.2]

Finally, the client and server exchange Authentication messages. TLS

uses the same set of messages every time that authentication is

needed. Specifically:

Certificate: the certificate of the endpoint and any per-certificate

extensions. This message is omitted by the server if not

authenticating with a certificate and by the client if the server

did not send CertificateRequest (thus indicating that the client

should not authenticate with a certificate). Note that if raw

public keys [

RFC7250] or the cached information extension

[

RFC7924] are in use, then this message will not contain a

certificate but rather some other value corresponding to the

server’s long-term key. [

Section 4.4.2]

Rescorla Expires October 30, 2017 [Page 18]

Internet-Draft TLS April 2017

Client Server

ClientHello

+ key_share -------->

<-------- HelloRetryRequest

+ key_share

ClientHello

+ key_share -------->

ServerHello

+ key_share

{EncryptedExtensions}

{CertificateRequest*}

{Certificate*}

{CertificateVerify*}

{Finished}

<-------- [Application Data*]

{Certificate*}

{CertificateVerify*}

{Finished} -------->

[Application Data] <-------> [Application Data]

Figure 2: Message flow for a full handshake with mismatched

parameters

Note: The handshake transcript includes the initial ClientHello/

HelloRetryRequest exchange; it is not reset with the new ClientHello.

TLS also allows several optimized variants of the basic handshake, as

described in the following sections.

2.2. Resumption and Pre-Shared Key (PSK)

Although TLS PSKs can be established out of band, PSKs can also be

established in a previous connection and then reused ("session

resumption"). Once a handshake has completed, the server can send

the client a PSK identity that corresponds to a key derived from the

initial handshake (see

Section 4.6.1). The client can then use that

PSK identity in future handshakes to negotiate use of the PSK. If

the server accepts it, then the security context of the new

connection is tied to the original connection and the key derived

from the initial handshake is used to bootstrap the cryptographic

state instead of a full handshake. In TLS 1.2 and below, this

functionality was provided by "session IDs" and "session tickets"

[

RFC5077]. Both mechanisms are obsoleted in TLS 1.3.

Rescorla Expires October 30, 2017 [Page 20]

剩余136页未读，继续阅读

The_Hungry_Brain

粉丝: 145

TLS1.3协议详解：互联网安全的新标准

The Transport Layer Security (TLS) Protocol Version 1.3.pdf

TLS1.3(RFC8446) - 翻译版 .docx

RFC8446_TLS1.3

tls13-spec:TLS 1.3规范

深入研究TLS 1.3规范草案及其在Python中的应用

TLS协议详解：从SSL到TLS1.3的安全演进

TLS 1.3：最新标准，增强安全与隐私

【TLS版本安全性对比】：TLS 1.2 vs TLS 1.3，选哪个？

【全面解析】OpenSSL与TLS 1.3的融合：3.3.2版本的新特性与优化

查看服务器tls1.3是否存在

最新资源