傳輸層安全協議

维基百科,自由的百科全书
(重定向自传输层安全
跳转至: 导航搜索

傳輸層安全協議英语Transport Layer Security,縮寫為 TLS),及其前身安全套接层Secure Sockets LayerSSL)是一种安全协议,目的是為網際網路通信,提供安全及数据完整性保障。在網景公司(Netscape)推出首版Web浏览器的同时提出SSL,IETF將SSL進行標準化,1999年公布了 TLS標準文件。

SSL包含记录层(Record Layer)和传输层,记录层协议确定了传输层数据的封装格式。傳輸層安全協議使用X.509認證,之後利用非對稱加密演算來對通訊方做身份認證,之後交換對稱金鑰作為會談金鑰(session key)。這個會談金鑰是用來將通訊兩方交換的資料做加密,保证两个应用间通信的保密性和可靠性,使客户與服务器应用之间的通信不被攻击者窃听。

SSL在服务器和客户机两端可同时被支持,目前已成为互联网上保密通讯的工业标准。现行的Web浏览器亦普遍将HTTP和SSL相结合,从而实现安全通信。

简介[编辑]

TLS 协议允许 C/S 模型的应用程序跨网络通讯,旨在防止窃听和篡改的方式进行沟通。 TLS 协议的优势在于它是应用层协议独立无关的。高层的应用层协议(例如:HTTPFTPTelnet等等)能透明的建立于 TLS 协议之上。TLS 协议在应用层协议通信之前就已经完成加密算法、通信密钥的协商以及服务器认证工作。在此之后应用层协议所传送的数据都会被加密,从而保证通信的私密性。

TLS 协议是可选的,所以如果需要使用就必须配置客户端和服务器,有两种主要方式实现这一目标:一个是使用统一的 TLS 协议端口号(例如用于 HTTPS 的端口 443);另一个是客户端请求服务器连接到 TLS 时使用特定的协议机制 (例如,邮件、新闻协议和 STARTTLS)。一旦客户端和服务器都同意使用 TLS 协议,他们通过使用一个握手过程协商出一个有状态的连接以传输数据[1]。通过握手,客户端和服务器协商各种参数用于建立安全连接:

  • 当客户端连接到支持 TLS 协议的服务器要求建立安全连接并列出了受支持的密码组合(加密密码算法和加密哈希函数),握手开始。
  • 服务器从该列表中决定加密和散列函数,并通知客户端。
  • 服务器发回其数字证书,此证书通常包含服务器的名称、受信任的证书颁发机构(CA)和服务器的公钥。
  • 客户端确认其颁发的证书的有效性。
  • 为了生成会话密钥用于安全连接,客户端使用服务器的公钥加密随机生成的密钥,并将其发送到服务器,只有服务器才能使用自己的私钥解密。
  • 利用随机数,双方生成用于加密和解密的对称密钥。

这就是 TLS 协议的握手,握手完毕后的连接是安全的,直到连接(被)关闭。如果上述任何一个步骤失败,TLS 握手过程就会失败,并且断开所有的连接。

發展歷史[编辑]

定义
协议 年份
SSL 1.0 N/A
SSL 2.0 1995
SSL 3.0 1996
TLS 1.0 1999
TLS 1.1 2006
TLS 1.2 2008
TLS 1.3 待定

安全网络编程[编辑]

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

SSL 1.0, 2.0 和 3.0[编辑]

SSL(Secure Sockets Layer)是网景公司(Netscape)设计的主要用于Web的安全传输协议,这种协议在Web上获得了广泛的应用[3]

基础算法由作为网景公司的首席科学家 Taher Elgamal 编写,所以他被人称为“SSL之父”[4][5]

2014年10月,Google 發布在 SSL 3.0 中發現設計缺陷,建議禁用此一協議。攻擊者可以向 TLS 發送虛假錯誤提示,然後將安全連接強行降級到古老的SSL 3.0,然後就可以利用其中的設計漏洞竊取敏感信息。Google 在自己公司相關產品中陸續禁止回溯相容,強制使用 TLS 協議。Mozilla 也會計劃於11月25日發布的 Firefox 34 中,將徹底禁用 SSL 3.0。微軟也同樣發出了安全通告[6]

  • 1.0 版本从未公开过,因为存在严重的安全漏洞
  • 2.0 版本在1995年2月发布,但因为存在数个严重的安全漏洞而被 3.0 版本替代[7]
  • 3.0 版本在1996年发布,是由 Paul KocherPhil KarltonAlan Freier 完全重新设计的。较新版本的 SSL/TLS 基于 SSL 3.0。SSL 3.0 作为历史文献 IETF 通过 RFC 6101 发表。

TLS 1.0[编辑]

IETF 将 SSL 标准化,即 RFC 2246,并将其称为TLSTransport Layer Security)。从技术上讲,TLS 1.0 与 SSL 3.0 的差異非常微小。 但正如 RFC 所述 "the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough to preclude interoperability between TLS 1.0 and SSL 3.0"(本协议和 SSL 3.0 之间的差异并不是显著,却足以排除 TLS 1.0 和 SSL 3.0 之间的互操作性)。TLS 1.0 包括可以降级到 SSL 3.0 的实现,这削弱了连接的安全性[8]:1–2

TLS 1.1[编辑]

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

  • 添加对 CBC 攻击的保护:
    • 隐式 IV 被替换成一个显式的 IV
    • 更改分组密码模式中的填充错误。
  • 支持 IANA 登记的参数。[8]:2

TLS 1.2[编辑]

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

  • 可使用密码组合选项指定伪随机函数使用 SHA-256 替换 MD5-SHA-1 组合。
  • 可使用密码组合选项指定在完成消息的哈希认证中使用 SHA-256 替换 MD5-SHA-1 算法,但完成消息中哈希值的长度仍然被截断为 96 位。
  • 在握手期间 MD5-SHA-1 组合的数字签名被替换为使用单一 Hash 方法,默认为 SHA-1。
  • 增强服务器和客户端指定 Hash 和签名算法的能力。
  • 扩大经过身份验证的加密密码,主要用于 GCM 和 CCM 模式的 AES 加密的支持。
  • 添加 TLS 扩展定义和 AES 密码组合[8]:2

所有 TLS 版本在2011年3月发布的 RFC 6176 中删除了对 SSL 的兼容,这样 TLS 会话将永远无法协商使用的 SSL 2.0 以避免安全问题。

TLS 1.3 (草案)[编辑]

截至2014年10月  (2014-10) TLS 1.3 还是 RFC 草案, 细节并未确定[10][11],它基于更早的 TLS 1.1 和 1.2 规范。与 TLS 1.2 的主要区别包括:

  • 移除 GMT 时间。
  • 合并在 RFC 4492 中对椭圆曲线加密算法的支持,但未有指定所使用的曲线。
  • 从输入到 AEAD 密码的 AD 中删除不必要的长度字段。
  • 将 "KeyExchange"(密钥交换)更名为 "KeyShare"(密钥共享)。
  • 添加显式的 HelloRetryRequest。
  • 1-RTT 重握手模式。
  • 移除自定义 DHE 组合。
  • 移除对数据压缩的支持。
  • 移除对静态 RSA 和 Diffie–Hellman 密钥交换的支持。
  • 移除对非 AEAD 密码的支持。

算法[编辑]

密钥交换密钥协商[编辑]

在客户端和服务器开始交换 TLS 所保护的加密信息之前,他们必须安全地交换或协定加密密钥和加密数据时要使用的密码。用于密钥交换的方法包括:使用 RSA 算法生成公钥和私钥(在 TLS 握手协议中被称为 TLS_RSA),Diffie-Hellman(在 TLS 握手协议中被称为 TLS_DH),临时 Diffie-Hellman(在 TLS 握手协议中被称为 TLS_DHE),椭圆曲线 Diffie-Hellman (在 TLS 握手协议中被称为 TLS_ECDH),临时椭圆曲线 Diffie-Hellman(在 TLS 握手协议中被称为 TLS_ECDHE),匿名 Diffie-Hellman(在 TLS 握手协议中被称为 TLS_DH_anon[12]预共享密钥(在 TLS 握手协议中被称为 TLS_PSK)。[13]

TLS_DH_anon 和 TLS_ECDH_anon 的密钥协商协议不能验证服务器或用户,因为易受中间人攻击因此很少使用。只有 TLS_DHE 和 TLS_ECDHE 提供前向保密能力。

在交换过程中使用的公钥/私钥加密密钥的长度和在交换协议过程中使用的公钥证书也各不相同,因而提供的鲁棒性的安全。2013年7月Google 宣布向其用户提供的 TLS 加密将不再使用1024位公钥并切换到2048位,以提高安全性。[14]

身份验证和密钥交换协议列表
算法 SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 状态
RSA 1 1 1 1 1 在 TLS 1.2 的 RFCs 内定义
DH-RSA 0 1 1 1 1
DHE-RSA(具前向加密能力)
ECDH-RSA 0 0 1 1 1
ECDHE-RSA(具前向加密能力)
DH-DSS 0 1 1 1 1
DHE-DSS(具前向加密能力)
ECDH-ECDSA 0 0 1 1 1
ECDHE-ECDSA(具前向加密能力)
DH-ANON(不安全) 0 0 1 1 1
ECDH-ANON(不安全) 0 0 1 1 1
GOST R 34.10-94 / 34.10-2001[15] 0 0 1 1 1 RFC 草案

加密密码[编辑]

已知公开并可行的攻击方法列表
密码 协议版本 状态
类型 算法 长度(位) 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]
块密码 AES GCM[16][n 5] 256, 128 不適用 不適用 不適用 不適用 安全 在 TLS 1.2 的 RFCs 中定义
AES CCM[17][n 5] 不適用 不適用 不適用 不適用 安全
AES CBC[n 6] 不適用 不適用 依赖于后期加入的措施 安全 安全
Camellia GCM[18][n 5] 256, 128 不適用 不適用 不適用 不適用 安全
Camellia CBC[19][n 6] 不適用 不適用 依赖于后期加入的措施 安全 安全
ARIA GCM[20][n 5] 256, 128 不適用 不適用 不適用 不適用 安全
ARIA CBC[20][n 6] 不適用 不適用 依赖于后期加入的措施 安全 安全
SEED CBC[21][n 6] 128 不適用 不適用 依赖于后期加入的措施 安全 安全
3DES EDE CBC[n 6] 112

[n 7]

不安全 不安全 强度不足
依赖于后期加入的措施
强度不足 强度不足
GOST 28147-89 CNT[15] 256 不適用 不適用 安全 安全 安全 RFC 草案
IDEA CBC[n 6][n 8] 128 不安全 不安全 依赖于后期加入的措施 安全 不適用 在 TLS 1.2 中已被移除
DES CBC[n 6][n 8] 056 不安全 不安全 不安全 不安全 不適用
040[n 9] 不安全 不安全 不安全 不適用 不適用 在 TLS 1.1 及更高版本中被禁用
RC2 CBC[n 6] 040[n 9] 不安全 不安全 不安全 不適用 不適用
流密码 RC4[n 10] 128 不安全 不安全 不安全 不安全 不安全 在 TLS 1.2 的 RFCs 中定义
040[n 9] 不安全 不安全 不安全 不適用 不適用 在 TLS 1.1 以后的版本中被禁用
ChaCha20-Poly1305[25][n 5] 256 不適用 不適用 不適用 不適用 安全 RFC 草案
ChaCha20[26] 256 不適用 不適用 安全 安全 安全
不加密 [n 11] - 不適用 不安全 不安全 不安全 不安全 在 TLS 1.2 的 RFCs 中定义
标注
  1. ^ 1.0 1.1 1.2 1.3 RFC 5746 必须执行,修补重协商漏洞。
  2. ^ 如果库实现修复 RFC 5746 中列出的问题将违反 SSL 3.0 规范,与 TLS 不同的是 IETF 无法更改 SSL 协议的设计。幸运的是,最新的库实现已经修复并忽略违反规范的问题。
  3. ^ 3.0 3.1 除非服务器和客户端双方都已经修复,BEAST 能攻击所有使用 SSL 3.0 和 TLS 1.0 的 CBC 数据块。
  4. ^ 除非服务器和客户端双方都已经修复,POODLE 能攻击所有使用 SSL 3.0 的 CBC 数据块。
  5. ^ 5.0 5.1 5.2 5.3 5.4 AEAD 密码(例如 GCM 和 CCM 模式) 只能用于 TLS 1.2。
  6. ^ 6.0 6.1 6.2 6.3 6.4 6.5 6.6 6.7 如果库实现处理边缘计时器不严密,CBC 密码可以通过 Lucky 13 被攻击。
  7. ^ 虽然 3DES 的密钥长度是 168 位,但有效的安全强度只有 112 位,[22]而现在最低的安全要求是128位[23]
  8. ^ 8.0 8.1 IDEA 和 DES 在 TLS 1.2 中已被移除[24]
  9. ^ 9.0 9.1 9.2 40位强度的密码组合是为了减少密钥长度,以遵守包含某些功能强大的加密算法的加密软件在出口方面的规定,这些弱密码组合在 TLS 1.1 及更高版本中已被禁用。
  10. ^ RC4攻击削弱了 RC4 在 SSL/TLS 中的使用。
  11. ^ 只认证,不加密

数据完整性[编辑]

MAC用于对数据完整性进行认证。HMAC 用于 CBC 模式的块密码和流密码,AEAD 用于身份验证加密例如 GCM 模式和 CCM 模式。

数据完整性算法列表
算法 SSL 2.0 SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 状态
HMAC-MD5 1 1 1 1 1 在 TLS 1.2 的 RFCs 中定义
HMAC-SHA1 0 1 1 1 1
HMAC-SHA256/384 0 0 0 0 1
AEAD 0 0 0 0 1
GOST 28147-89 IMIT[15] 0 0 1 1 1 RFC 草案
GOST R 34.11-94[15] 0 0 1 1 1

过程[编辑]

双向证书认证的SSL握手过程。

以下简要介绍SSL协议的工作方式。客户端要收发几个握手信号:

  1. 发送一个「ClientHello」消息,内容包括:支持的协议版本,比如TLS1.0版,一个客户端生成的随机数(稍后用户生成“会话密钥”),支持的加密算法(如RSA公钥加密)和支持的压缩算法。
  2. 然后收到一个「ServerHello」消息,内容包括:确认使用的加密通信协议版本,比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致,服务器关闭加密通信,一个服务器生成的随机数,稍后用于生成"对话密钥",确认使用的加密方法,比如RSA公钥加密,服务器证书。
  3. 当双方知道了连接参数,客户端与服务器交换证书(依靠被选择的公钥系统)。这些证书通常基于X.509,不过已有草案支持以OpenPGP为基础的证书。
  4. 服务器请求客户端公钥。客户端有证书即双向身份认证,没证书时随机生成公钥。
  5. 客户端与服务器通过公钥保密协商共同的主私钥(双方随机协商),这通过精心谨慎设计的伪随机数功能实现。结果可能使用Diffie-Hellman交换,或简化的公钥加密,双方各自用私钥解密。所有其他关键数据的加密均使用这个「主密钥」。

数据传输中记录层(Record layer)用于封装更高层的HTTP等协议。记录层数据可以被随意压缩、加密,与消息验证码压缩在一起。每个记录层包都有一个Content-Type段用以记录更上层用的协议。

TLS[编辑]

TLS利用密钥算法互联网上提供端点身份认证通讯保密,其基础是公钥基础设施。不过在实现的典型例子中,只有网络服务者被可靠身份验证,而其客户端则不一定。这是因为公钥基础设施普遍商业运营,电子签名证书通常需要付费购买。协议的设计在某种程度上能够使主从架构应用程序通讯本身预防窃听干扰消息伪造

TLS包含三个基本阶段:

  1. 对等协商支援的密钥算法
  2. 基于非对称密钥的信息传输加密和身份认证、基于PKI证书的身份认证
  3. 基于对称密钥的数据传输保密

在第一阶段,客户端与服务器协商所用密码算法。 当前广泛实现的算法选择如下:

TLS/SSL有多样的安全保护措施:

  • 所有的记录层数据均被编号,用于消息验证码校验。

参考文献[编辑]

  1. ^ "SSL/TLS in Detail". Microsoft TechNet. Updated July 31, 2003.
  2. ^ Thomas Y. C. Woo, Raghuram Bindignavle, Shaowen Su and Simon S. Lam, SNP: An interface for secure network programming Proceedings USENIX Summer Technical Conference, June 1994
  3. ^ THE SSL PROTOCOL. Netscape Corporation. 2007. (原始内容存档于14 June 1997). 
  4. ^ Messmer, Ellen. Father of SSL, Dr. Taher Elgamal, Finds Fast-Moving IT Projects in the Middle East. Network World. [30 May 2014]. 
  5. ^ Greene, Tim. Father of SSL says despite attacks, the security linchpin has lots of life left. Network World. [30 May 2014]. 
  6. ^ POODLE: SSLv3 vulnerability (CVE-2014-3566). [21 October 2014]. 
  7. ^ Rescorla 2001
  8. ^ 8.0 8.1 8.2 Polk, Tim; McKay, Terry; Chokhani, Santosh. Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. National Institute of Standards and Technology. 67. April 2014 [2014-05-07]. 
  9. ^ Dierks, T. and E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.1, RFC 4346. April 2006. 
  10. ^ draft-ietf-tls-tls13-03 - The Transport Layer Security (TLS) Protocol Version 1.3
  11. ^ draft-ietf-tls-tls13-latest
  12. ^ RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2. Internet Engineering Task Force. [9 September 2013]. 
  13. ^ P. Eronen, Ed. RFC 4279: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). Internet Engineering Task Force. [9 September 2013]. 
  14. ^ Gothard, Peter. Google updates SSL certificates to 2048-bit encryption. Computing. Incisive Media. [9 September 2013]. 
  15. ^ RFC 5288
  16. ^ RFC 6655
  17. ^ RFC 6367
  18. ^ RFC 5932, RFC 6367
  19. ^ 20.0 20.1 RFC 6209
  20. ^ RFC 4162
  21. ^ NIST Special Publication 800-57 Recommendation for Key Management — Part 1: General (Revised). 2007-03-08 [2014-07-03]. 
  22. ^ Qualys SSL Labs. SSL/TLS Deployment Best Practices. [19 November 2013]. 
  23. ^ RFC 5469
  24. ^ draft-agl-tls-chacha20poly1305-04 - ChaCha20 and Poly1305 based Cipher Suites for TLS4, draft-mavrogiannopoulos-chacha-tls-03 - The ChaCha Stream Cipher for Transport Layer Security
  25. ^ draft-mavrogiannopoulos-chacha-tls-03 - The ChaCha Stream Cipher for Transport Layer Security

参见[编辑]

参考[编辑]