傳輸層安全性協定
傳輸層安全性協定(英語: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协议,他们通过使用一个握手过程协商出一个有状态的连接以传输数据[1]。通过握手,客户端和服务器协商各种参数用于建立安全连接:
發展歷史
協議 | 發布時間 | 狀態 |
---|---|---|
SSL 1.0 | 未公佈 | 未公佈 |
SSL 2.0 | 1995年 | 已於2011年棄用[2] |
SSL 3.0 | 1996年 | 已於2015年棄用[3] |
TLS 1.0 | 1999年 | 于2021年弃用[4] |
TLS 1.1 | 2006年 | 于2021年弃用[4] |
TLS 1.2 | 2008年 | |
TLS 1.3 | 2018年 |
安全网络编程
早期的研究工作,为方便改造原有网络应用程序,在1993年已经有了相似的Berkeley套接字安全传输层API方法[5]。
SSL 1.0、2.0和3.0
SSL(Secure Sockets Layer)是网景公司(Netscape)设计的主要用于Web的安全传输协议,这种协议在Web上获得了广泛的应用[6]。
基础算法由作为网景公司的首席科学家塔希爾·蓋莫爾(Taher Elgamal)编写,所以他被人称为“SSL之父”。[7][8]
2014年10月,Google發布在SSL 3.0中發現設計缺陷,建議禁用此一協議。攻擊者可以向TLS發送虛假錯誤提示,然後將安全連接強行降級到过时且不安全的SSL 3.0,然後就可以利用其中的設計漏洞竊取敏感信息。Google在自己公司相關產品中陸續禁止回溯相容,強制使用TLS協議。Mozilla也在11月25日發布的Firefox 34中徹底禁用了SSL 3.0。微軟同樣發出了安全通告[9]。
- 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月发表[10],它是TLS 1.0的更新。在此版本中的差异包括:
微軟、Google、蘋果、Mozilla四家瀏覽器業者將在2020年終止支援TLS 1.0及1.1版[12]。2021年3月,RFC 8996标准弃用了TLS 1.0和TLS 1.1[4]。
TLS 1.2
TLS 1.2在 RFC 5246 中定义,于2008年8月发表。它基于更早的TLS 1.1规范。主要区别包括:
- 增加SHA-2密碼雜湊函數。
- 增加AEAD加密算法,如GCM模式。
- 添加TLS扩展定义和AES密码组合[11]:2。所有TLS版本在2011年3月发布的RFC 6176中删除了对SSL的兼容,这样TLS会话将永远无法协商使用的SSL 2.0以避免安全问题。
TLS 1.3
TLS 1.3在 RFC 8446 中定义,于2018年8月发表。[13]它与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)。[14]
网络安全服务(NSS)是由Mozilla开发并由其网络浏览器Firefox使用的加密库,自2017年2月起便默认启用TLS 1.3。[15]随后TLS 1.3被添加到2017年3月发布的Firefox 52.0中,但它由于某些用户的兼容性问题,默认情况下禁用。[16]直到Firefox 60.0才正式默认启用。[17]
Google Chrome曾在2017年短时间将TLS 1.3设为默认,然而由于类似Blue Coat Systems等不兼容组件而被取消。[18]
wolfSSL在2017年5月发布的3.11.1版本中启用了TLS 1.3。[19]作为第一款支持TLS 1.3部署,wolfSSL 3.11.1 支持 TLS 1.3 Draft 18(现已支持到Draft 28),[20]同时官方也发布了一系列关于TLS 1.2和TLS 1.3性能差距的博客。[21]
算法
密钥交换和密钥协商
在客户端和服务器开始交换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)[22]、预共享密钥(在TLS握手协议中被称为TLS_PSK)[23]和安全远程密码(在TLS握手协议中被称为TLS_SRP)。[24]
TLS_DH_anon和TLS_ECDH_anon的密钥协商协议不能验证服务器或用户,因为易受中间人攻击因此很少使用。只有TLS_DHE和TLS_ECDHE提供前向保密能力。
在交换过程中使用的公钥/私钥加密密钥的长度和在交换协议过程中使用的公钥证书也各不相同,因而提供的強健性的安全。2013年7月,Google宣布向其用户提供的TLS加密将不再使用1024位公钥并切换到至少2048位,以提高安全性。[25]
算法 | SSL 2.0 | SSL 3.0 | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 | 状态 |
---|---|---|---|---|---|---|---|
RSA | 是 | 是 | 是 | 是 | 是 | 否 | RFC中TLS 1.2的定義 |
DH-RSA | 否 | 是 | 是 | 是 | 是 | 否 | |
DHE-RSA(具有前向安全性) | 否 | 是 | 是 | 是 | 是 | 是 | |
ECDH-RSA | 否 | 否 | 是 | 是 | 是 | 否 | |
ECDHE-RSA(具有前向安全性) | 否 | 否 | 是 | 是 | 是 | 是 | |
DH-DSS | 否 | 是 | 是 | 是 | 是 | 否 | |
DHE-DSS(具有前向安全性) | 否 | 是 | 是 | 是 | 是 | 否[26] | |
DHE-ECDSA (具有前向安全性) | 否 | 否 | 否 | 否 | 否 | 是 | |
ECDH-ECDSA | 否 | 否 | 是 | 是 | 是 | 否 | |
ECDHE-ECDSA(具有前向安全性) | 否 | 否 | 是 | 是 | 是 | 是 | |
DHE-EdDSA (具有前向安全性) | 否 | 否 | 否 | 否 | 否 | 是 | |
ECDH-EdDSA | 否 | 否 | 是 | 是 | 是 | 否 | |
ECDHE-EdDSA (具有前向安全性)[27] | 否 | 否 | 是 | 是 | 是 | 是 | |
PSK | 否 | 否 | 是 | 是 | 是 | 是 | |
RSA-PSK | 否 | 否 | 是 | 是 | 是 | 否 | |
DHE-PSK(具有前向安全性) | 否 | 否 | 是 | 是 | 是 | 是 | |
ECDHE-PSK(具有前向安全性) | 否 | 否 | 是 | 是 | 是 | 是 | |
SRP | 否 | 否 | 是 | 是 | 是 | 否 | |
SRP-DSS | 否 | 否 | 是 | 是 | 是 | 否 | |
SRP-RSA | 否 | 否 | 是 | 是 | 是 | 否 | |
Kerberos | 否 | 否 | 是 | 是 | 是 | ? | |
DH-ANON(不安全) | 否 | 是 | 是 | 是 | 是 | 否 | |
ECDH-ANON(不安全) | 否 | 否 | 是 | 是 | 是 | 否 | |
GOST R 34.10-94 / 34.10-2001[28] | 否 | 否 | 是 | 是 | 是 | 在RFC草案中提出 | |
GOST R 34.10-2012[29] | 否 | 否 | 否 | 否 | 是 | 是 | RFC 9189 9367中TLS 1.2、1.3的定义 |
加密密码
密碼 | 协议版本 | 状态 | |||||||
---|---|---|---|---|---|---|---|---|---|
类型 | 算法 | 长度(bits) | SSL 2.0 | SSL 3.0 [n 1][n 2][n 3][n 4] | TLS 1.0 [n 1][n 3] | TLS 1.1 [n 1] | TLS 1.2 [n 1] | TLS 1.3 | |
分组密码及其加密方式 | AES GCM[30][n 5] | 256, 128 | 不適用 | 不適用 | 不適用 | 不適用 | 安全 | 安全 | RFC中TLS 1.2的定義 |
AES CCM[31][n 5] | 不適用 | 不適用 | 不適用 | 不適用 | 安全 | 安全 | |||
AES CBC[n 6] | 不適用 | 不安全 | 依赖于后期加入的措施 | 依赖于后期加入的措施 | 依赖于后期加入的措施 | 不適用 | |||
Camellia GCM[32][n 5] | 256, 128 | 不適用 | 不適用 | 不適用 | 不適用 | 安全 | 不適用 | ||
Camellia CBC[33][n 6] | 不適用 | 不安全 | 依赖于后期加入的措施 | 依赖于后期加入的措施 | 依赖于后期加入的措施 | 不適用 | |||
ARIA加密算法 GCM[34][n 5] | 256, 128 | 不適用 | 不適用 | 不適用 | 不適用 | 安全 | 不適用 | ||
ARIA加密算法 CBC[34][n 6] | 不適用 | 不適用 | 依赖于后期加入的措施 | 依赖于后期加入的措施 | 依赖于后期加入的措施 | 不適用 | |||
SEED加密算法 CBC[35][n 6] | 128 | 不適用 | 不安全 | 依赖于后期加入的措施 | 依赖于后期加入的措施 | 依赖于后期加入的措施 | 不適用 | ||
3DES EDE CBC[n 6][n 7] | 112[n 8] | 不安全 | 不安全 | 不安全 | 不安全 | 不安全 | 不適用 | ||
GOST 28147-89 CNT[28][n 7] | 256 | 不適用 | 不適用 | 不安全 | 不安全 | 不安全 | 不適用 | 定义于RFC 4357 | |
GOST R 34.12-2015 Magma CTR[29][n 7] | 256 | 不適用 | 不適用 | 不安全 | 不安全 | 不安全 | 不適用 | 定义于RFC 4357 9189 | |
GOST R 34.12-2015 Kuznyechik CTR[29] | 256 | 不適用 | 不適用 | 不適用 | 不適用 | 安全 | 不適用 | 定义于RFC 9189 | |
GOST R 34.12-2015 Magma MGM[29][n 5][n 7] | 256 | 不適用 | 不適用 | 不適用 | 不適用 | 不適用 | 不安全 | 定义于RFC 9367 | |
GOST R 34.12-2015 Kuznyechik MGM[29][n 5] | 256 | 不適用 | 不適用 | 不適用 | 不適用 | 不適用 | 安全 | 定义于RFC 9367 | |
IDEA CBC[n 6][n 7][n 9] | 128 | 不安全 | 不安全 | 不安全 | 不安全 | 不適用 | 不適用 | 从TLS 1.2标准中移除 | |
DES CBC[n 6][n 7][n 9] | 56 | 不安全 | 不安全 | 不安全 | 不安全 | 不適用 | 不適用 | ||
[n 10] | 40不安全 | 不安全 | 不安全 | 不適用 | 不適用 | 不適用 | 在TLS 1.1及之后版本禁止 | ||
RC2 CBC[n 6][n 7] | [n 10] | 40不安全 | 不安全 | 不安全 | 不適用 | 不適用 | 不適用 | ||
流加密 | ChaCha20-Poly1305[40][n 5] | 256 | 不適用 | 不適用 | 不適用 | 不適用 | 安全 | 安全 | RFC中TLS 1.2的定義 |
RC4[n 11] | 128 | 不安全 | 不安全 | 不安全 | 不安全 | 不安全 | 不適用 | 由RFC 7465定义所有版本TLS禁止 | |
[n 10] | 40不安全 | 不安全 | 不安全 | 不適用 | 不適用 | 不適用 | |||
None | Null[n 12] | – | 不安全 | 不安全 | 不安全 | 不安全 | 不安全 | 不適用 | RFC中TLS 1.2的定義 |
- 标注
数据完整性
訊息鑑別碼(MAC)用于对数据完整性进行认证。HMAC用于CBC模式的块密码。AEAD例如GCM模式和CCM模式使用AEAD內建的訊息鑒別碼,不使用HMAC[41]。另外,在TLS握手過程中需要使用基於HMAC的偽隨機函數(PRF),或HKDF。
算法 | SSL 2.0 | SSL 3.0 | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 | 狀態 |
---|---|---|---|---|---|---|---|
HMAC-MD5 | 是 | 是 | 是 | 是 | 是 | 否 | RFC中TLS 1.2的定義 |
HMAC-SHA1 | 否 | 是 | 是 | 是 | 是 | 否 | |
HMAC-SHA256/384 | 否 | 否 | 否 | 否 | 是 | 否 | |
AEAD | 否 | 否 | 否 | 否 | 是 | 是 | |
GOST 28147-89 IMIT | 否 | 否 | 否 | 否 | 是 | 否 | RFC 9189中TLS 1.2的定义 |
GOST R 34.11-94 | 否 | 否 | 否 | 否 | 是 | RFC Draft中TLS 1.2的定义 | |
GOST R 34.12-2015 AEAD | 否 | 否 | 否 | 否 | 否 | 是 | RFC 9367中TLS 1.3的定义 |
过程
TLS在互联网上為HTTP等應用程式提供身份驗證、加密、完整性,其基础是公钥基础设施。这是因为公鑰基礎設施普遍商业运营。TLS协议的设计在某种程度上能够使主从架构应用程序通讯预防窃听、干扰和消息伪造。
TLS包含幾個基本阶段:
- 对等协商支援的TLS版本,和支援的密碼套件。
- 基于非对称密钥的身份认证,通常是基于PKI证书的身份认证。伺服器將其X.509證書發送給客戶端,由客戶端驗證伺服器的身份。如果伺服器要驗證客戶端的證書,則客戶端可能會將客戶端證書發送給伺服器。通常僅驗證伺服器,不驗證客戶端。
- 基于对称密钥的數據加密。客戶端生成隨機數作為對談金鑰,並使用伺服器公鑰(伺服器公鑰在伺服器證書中)加密對談金鑰,最後將已加密的對談金鑰發送給伺服器。由伺服器的私鑰解密出對談金鑰。最後使用此對談金鑰加密數據。TLS也可以使用預共用金鑰(PSK)作為對稱密鑰。
在第一阶段,客户端与服务器协商所用密码算法。当前广泛实现的算法选择如下:
参考文献
外部链接
维基共享资源上的相关多媒体资源:傳輸層安全性協定 |