# 傳輸層安全性協定

Canonical: https://web4.xpay.bi/zh-CN/wiki/wp-zh-348228/

Language: zh-CN

Published: 2026-10-30T02:03:25.769Z

Updated: 2026-10-30T02:03:25.769Z

傳輸層安全性協定（英語：Transport Layer Security，縮寫：TLS），前身稱為安全套接层（英語：Secure Sockets Layer，縮寫：SSL）是一种安全协议，目的是為網際網路通信提供安全及数据完整性保障。

## Key facts

## 概述

傳輸層安全性協定（英語：Transport Layer Security，縮寫：TLS），前身稱為安全套接层（英語：Secure Sockets Layer，縮寫：SSL）是一种安全协议，目的是為網際網路通信提供安全及数据完整性保障。 網景公司（Netscape）在1994年推出首版網頁瀏覽器－網景領航員時，推出HTTPS協定，以SSL進行加密，這是SSL的起源。 IETF將SSL進行標準化，1999年公布TLS 1.0標準文件（RFC 2246）。隨後又公布TLS 1.1（RFC 4346，2006年）、TLS 1.2（RFC 5246，2008年）和TLS 1.3（RFC 8446，2018年）。在瀏覽器、電子郵件、即時通訊、VoIP、網路傳真等應用程式中，廣泛使用這個協定。許多網站，如Google、Facebook、Wikipedia等也以這個協定來建立安全連線，傳送資料。目前已成为互联网上保密通信的工业标准。 SSL包含记录层（Record Layer）和传输层，记录层协议确定传输层数据的封装格式。傳輸層安全協議使用X.509認證，之後利用非對稱加密演算來對通訊方做身份認證，之後交換對稱密匙作為會话密匙（Session key）。這個會談密匙是用來將通訊兩方交換的資料做加密，保证两个应用间通信的保密性和可靠性，使客户與服务器应用之间的通信不被攻击者窃听。

## 概論

TLS協定採用主從式架構模型，用于在兩個應用程式間透過網路建立起安全的連線，防止在交換資料时受到竊聽及篡改。 TLS协议的优势是与高层的应用层协议（如HTTP、FTP、Telnet等）无耦合。应用层协议能透明地运行在TLS协议之上，由TLS协议进行建立加密通道需要的协商和认证。应用层协议传送的数据在通过TLS协议时都会被加密，从而保证通信的私密性。 TLS协议是可选的，必须配置客户端和服务器才能使用。主要有两种方式实现这一目标：一个是使用统一的TLS协议通訊埠（例如：用于HTTPS的端口443）；另一个是客户端请求服务器连接到TLS时使用特定的协议机制（例如：電子郵件常用的STARTTLS）。一旦客户端和服务器都同意使用TLS协议，他们通过使用一个握手过程协商出一个有状态的连接以传输数据。通过握手，客户端和服务器协商各种参数用于建立安全连接：

当客户端连接到支持TLS协议的服务器要求建立安全连接并列出了受支持的密碼套件（包括加密算法、散列算法等），握手开始。 服务器从该列表中决定密碼套件，并通知客户端。 服务器发回其数字证书，此证书通常包含服务器的名称、受信任的证书颁发机构（CA）和服务器的公钥。 客户端确认其颁发的证书的有效性。 为了生成会话密钥用于安全连接，客户端使用服务器的公钥加密随机生成的密钥，并将其发送到服务器，只有服务器才能使用自己的私钥解密。 利用随机数，双方生成用于加密和解密的对称密钥。这就是TLS协议的握手，握手完毕后的连接是安全的，直到连接（被）关闭。如果上述任何一个步骤失败，TLS握手过程就会失败，并且断开所有的连接。

## 安全网络编程

早期的研究工作，为方便改造原有网络应用程序，在1993年已经有了相似的Berkeley套接字安全传输层API方法。

## SSL 1.0、2.0和3.0

SSL（Secure Sockets Layer）是网景公司（Netscape）设计的主要用于Web的安全传输协议，这种协议在Web上获得了广泛的应用。 基础算法由作为网景公司的首席科学家塔希爾·蓋莫爾（Taher Elgamal）编写，所以他被人称为“SSL之父”。 2014年10月，Google發布在SSL 3.0中發現設計缺陷，建議禁用此一協議。攻擊者可以向TLS發送虛假錯誤提示，然後將安全連接強行降級到过时且不安全的SSL 3.0，然後就可以利用其中的設計漏洞竊取敏感信息。Google在自己公司相關產品中陸續禁止回溯相容，強制使用TLS協議。Mozilla也在11月25日發布的Firefox 34中徹底禁用了SSL 3.0。微軟同樣發出了安全通告。

1.0版本从未公开过，因为存在严重的安全漏洞。 2.0版本在1995年2月发布。2011年，RFC 6176 標準棄用了SSL 2.0。 3.0版本在1996年发布，是由網景工程師保罗·科切、Phil Karlton和Alan Freier完全重新设计的。2015年，RFC 7568 標準棄用了SSL 3.0。

## TLS 1.0

IETF将SSL标准化，即 RFC 2246 ，并将其称为TLS（Transport Layer Security）。

## TLS 1.1

TLS 1.1在 RFC 4346 中定义，于2006年4月发表，它是TLS 1.0的更新。在此版本中的差异包括：

添加对CBC攻击的保护： 隐式IV被替换成一个显式的IV。 更改分组密码模式中的填充错误。 支持IANA登记的参数。 微軟、Google、蘋果、Mozilla四家瀏覽器業者在2020年終止支援TLS 1.0及1.1版。2021年3月，RFC 8996标准弃用了TLS 1.0和TLS 1.1。

## TLS 1.2

TLS 1.2在 RFC 5246 中定义，于2008年8月发表。它基于更早的TLS 1.1规范。主要区别包括：

增加SHA-2密碼雜湊函數。 增加AEAD加密算法，如GCM模式。 添加TLS扩展定义和AES密码组合。所有TLS版本在2011年3月发布的RFC 6176中删除了对SSL的兼容，这样TLS会话将永远无法协商使用的SSL 2.0以避免安全问题。

## TLS 1.3

TLS 1.3在 RFC 8446 中定义，于2018年8月发表。它与TLS 1.2的主要区别包括：

将密鑰交換算法（如ECDHE）和認證算法（如RSA）从密码套件中分离出来。 移除MD5、SHA1密碼雜湊函數的支持。 请求数字签名。 集成HKDF和半短暂DH提议。 替换使用PSK和票据的恢复。 支持1-RTT握手并初步支持0-RTT。 通过在密鑰協商期间使用临时密钥来保证完善的前向安全性。 放弃许多不安全或过时特性的支持，包括数据压缩、重新协商、非AEAD加密算法、静态RSA和静态DH密钥交换、自定义DHE分组、点格式协商、更改密码本规范的协议、UNIX时间的Hello消息，以及长度字段AD输入到AEAD密码本。 較TLS 1.2速度更快，效能更好。 移除RC4加密演算法的支援。 集成会话散列的使用。 弃用记录层版本号和冻结数以改进向后兼容性。 将一些安全相关的算法细节从附录移动到标准，并将ClientKeyShare降级到附录。 支援Ed25519和Ed448数字签名算法。 支援X25519密鑰交換。 支援帶Poly1305訊息驗證碼的ChaCha20加密演算法。 支持加密服务器名称指示（Encrypted Server Name Indication, ESNI）。 网络安全服务（NSS）是由Mozilla开发并由其网络浏览器Firefox使用的加密库，自2017年2月起便默认启用TLS 1.3。随后TLS 1.3被添加到2017年3月发布的Firefox 52.0中，但它由于某些用户的兼容性问题，默认情况下禁用。直到Firefox 60.0才正式默认启用。 Google Chrome曾在2017年短时间将TLS 1.3设为默认，然而由于类似Blue Coat Systems等不兼容组件而被取消。 wolfSSL在2017年5月发布的3.11.1版本中启用了TLS 1.3。作为第一款支持TLS 1.3部署，wolfSSL 3.11.1 支持 TLS 1.3 Draft 18（现已支持到Draft 28），同时官方也发布了一系列关于TLS 1.2和TLS 1.3性能差距的博客。

## 密钥交换和密钥协商

在客户端和服务器开始交换TLS所保护的加密信息之前，他们必须安全地交换或协定加密密钥和加密数据时要使用的密码。用于密钥交换的方法包括：使用RSA算法生成公钥和私钥（在TLS 握手协议中被称为TLS\_RSA）、Diffie-Hellman（在TLS握手协议中被称为TLS\_DH）、临时Diffie-Hellman（在TLS握手协议中被称为TLS\_DHE）、橢圓曲線迪菲-赫爾曼（在TLS握手协议中被称为TLS\_ECDH）、临时椭圆曲线Diffie-Hellman（在TLS握手协议中被称为TLS\_ECDHE）、匿名Diffie-Hellman（在TLS握手协议中被称为TLS\_DH\_anon）、预共享密钥（在TLS握手协议中被称为TLS\_PSK）和安全远程密码（在TLS握手协议中被称为TLS\_SRP）。 TLS\_DH\_anon和TLS\_ECDH\_anon的密钥协商协议不能验证服务器或用户，因为易受中间人攻击因此很少使用。只有TLS\_DHE和TLS\_ECDHE提供前向保密能力。 在交换过程中使用的公钥/私钥加密密钥的长度和在交换协议过程中使用的公钥证书也各不相同，因而提供的強健性的安全。2013年7月，Google宣布向其用户提供的TLS加密将不再使用1024位公钥并切换到至少2048位，以提高安全性。

## 加密密码

标注

## 数据完整性

訊息鑑別碼（MAC）用于对数据完整性进行认证。HMAC用于CBC模式的块密码。AEAD例如GCM模式和CCM模式使用AEAD內建的訊息鑒別碼，不使用HMAC。另外，在TLS握手過程中需要使用基於HMAC的偽隨機函數（PRF），或HKDF。

## 过程

TLS在互联网上為HTTP等應用程式提供身份驗證、加密、完整性，其基础是公钥基础设施。这是因为公鑰基礎設施普遍商业运营。TLS协议的设计在某种程度上能够使主从架构应用程序通讯预防窃听、干扰和消息伪造。 TLS包含幾個基本阶段：

对等协商支援的TLS版本，和支援的密碼套件。 基于非对称密钥的身份认证，通常是基于PKI证书的身份认证。伺服器將其X.509證書發送給客戶端，由客戶端驗證伺服器的身份。如果伺服器要驗證客戶端的證書，則客戶端可能會將客戶端證書發送給伺服器。通常僅驗證伺服器，不驗證客戶端。 基于对称密钥的數據加密。客戶端生成隨機數作為對談金鑰，並使用伺服器公鑰（伺服器公鑰在伺服器證書中）加密對談金鑰，最後將已加密的對談金鑰發送給伺服器。由伺服器的私鑰解密出對談金鑰。最後使用此對談金鑰加密數據。TLS也可以使用預共用金鑰（PSK）作為對稱密鑰。 在第一阶段，客户端与服务器协商所用密码算法。当前广泛实现的算法选择如下：

身份驗證：RSA、DSA、ECDSA； 密鑰交換：PSK、Diffie-Hellman、ECDH； 对称密钥加密：RC4、DES、3DES、AES、ChaCha20以及Camellia； 散列函数：MD5、SHA家族。

## Sources

- 傳輸層安全性協定 · Wikipedia: https://zh.wikipedia.org/?curid=348228

Source: Wikipedia contributors — https://zh.wikipedia.org/?curid=348228&oldid=91555191

Licence: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/

Adaptation notice: Reformatted for XPay; the source may be abridged, restructured or translated. Consult the cited revision for the original.