传输层的安全协议——SSL/TLS，及HTTPS的工作原理

一、SSL安全套接字层协议/TLS安全传输层协议

1. 概述

• SSL(Socket Secure Layer)是TLS(Transport Layer Security)的前身，TLS 1.0在SSL 3.0的基础上提出（SSL已被弃用，TLS是目前的主流，但TLS1.0和TLS1.1已不再安全，建议使用TLS1.2或更新版本）；
• TLS基于TCP，建立两个应用进程之间的安全传输连接，如下：
  • 完成身份鉴别（鉴别服务端或客户端）
  • 安全地共享一对协商密钥（主密钥）来进行实现对称加密
  • 保证报文的完整性，防篡改
  • 预防恶意的重放攻击

2. TLS协议结构

• TLS是一个协议簇，由多个子协议组成，其中最主要的协议有两个：
  • TLS握手协议：用于加密、身份鉴别。
  • TLS记录协议：用于保证报文的完整性和防重放攻击。

二、TLS的握手协议

TLS握手协议用于实现在进行安全传输之前必要的身份鉴别和安全参数协商（共享协商密钥）

1. 第一阶段（双方发包）：双方约定算法

在这一阶段，双方对压缩算法、加密算法、MAC算法和TLS版本达成一致。

• ①客户端Client（以下简称客户C）：

  客户C通过发送客户Hello消息，告知服务器自己支持的算法、TLS版本号以及一个客户随机数NonceC（在第四阶段再提及）。

• ②服务器端Server（以下简称服务器V）：

  服务器C通过发送服务器Hello消息，按照自己的优先度选择一种客户C支持的算法，在双方支持的TLS版本种选择较低的版本作为双方约定的TLS版本，并且发送一个服务器随机数NonceV（在第四阶段再提及）。

2. 第二阶段（服务器V发包）：让客户C能验证服务器证书

在这一阶段，客户C开始对服务器V做身份鉴别工作（实际存在多种鉴别服务器V身份的机制，本文仅以"证书+私钥"为例）。值得注意的是，实际上该阶段并没有完成对服务器V的身份鉴别。

关于公钥和私钥：终端A将公钥PK_A（Pulbic Key）公开，若想发送加密信息给终端A，则需先使用其提供的公钥PK_A来将信息加密，用PK_A加密的信息只有使用其对应的私钥SK_A（Secret Key）才能解密，而终端A从不曾分发过私钥SK_A，所以只有终端A自己能够解密信息。

• 让客户C能验证服务器证书：服务器V向客户C发送证书链，客户C可以据此来明确公钥PK_V（Public Key）和域名ID_V的绑定关系：即公钥PK_V对应域名ID_V；

  那服务器V应该怎么发证书链？

  ——服务器V根据客户C的信任点来发送对应的证书链。

  

  如上认证关系示意图，如果客户C的信任点是认证中心A，那么服务器V就应该发送（服务器V=>认证中心D=>认证中心A）的证书链：即A<<D>>，D<<服务器V>>

  但是，这还不足以鉴别服务器V的身份，只有证明服务器V拥有和公钥PK_V对应的私钥SK_V（Secret Key）时，才能证明服务器V拥有域名ID_V

• 此外，服务器V也可以选择在这时请求客户C发送对方的证书链（需要给出自己拥有的证书链，来供客户C发送能够使服务器V信服的证书链），以此来鉴别客户C的身份。
  

3. 第三阶段（客户C发包）：①让服务器V能鉴别客户C的身份&②生成主密钥

• ①仅当服务器V想要鉴别客户C的身份：

  • 如果在第二阶段时，服务器V请求鉴别客户C的身份，那么此时客户C将发送能够使服务器V信服的证书链。

    如下图，假如服务器V拥有的证书链是A<<D>>,D<<服务器V>>，那么客户C必须发送A<<B>>,B<<客户C>>

• 此时，服务器V已经能确定PK_C和ID_C之间的绑定关系，但仍然不能确定客户C拥有公钥PK_C的对应私钥SK_C，该怎么办呢？

  • 客户C将双方的握手协议消息P（因为此时双方都拥有相同的握手协议信息）通过报文摘要MD（Message Digest）后，用私钥SK_C进行D运算后发送给服务器V；

    （P=>MD（P）=>D_SKC（MD（P）））

  • 服务器V收到后用公钥PK_C来对其进行E运算后，将结果与自己之前保留着的握手协议消息的报文摘要值进行比较，若相同，则认为客户C通过身份鉴别，否则反之。

    （D_SKC（MD（P））=>E_PKC（D_SKC（MD（P）））=>MD（P））

    这里的D运算和E运算实际上就是“解密运算Decryption”和“加密运算Encryption”，那就奇怪了，为什么还能“先解密后加密”呢？。其实是因为公钥密码体制的特性，使用D运算和E运算的先后顺序并不会影响到最后明文的结果（即：D(E(明文))=明文=E(D(明文))），而且中间状态无论是D(明文)还是E(明文)，它们得到的结果都是不可读的，均可视作一种密文。

• ②生成主密钥：

  • 发送加密后的预主密钥

    • 客户C选择一个预主密钥PMK（Pre-Master Key）；

    • 用服务器V的公钥PK_V来加密PMK，得到Y，将其发送给服务器V；

      （Y = E_PKV（PMS））

    • 只有在服务器V拥有公钥PK_V对应的私钥SK_V时，才能得到PMK，。

      （PMS = D_SKV（Y） = D_SKV（E_PKV（PMS）））

  • 客户C和服务器V，根据手中的预主密钥、客户Hello、服务器Hello、客户随机数NonceC和服务器随机数NonceV来计算主密钥MK（Main Key），计算公式如下：

    MK = PRF（PMS，“Master-Secret”，NonceC||NonceV）

    其中，PRF（Pseudo Random Function）是伪随机数生成函数：

    PRF（密钥，标签，种子） = P_MD5（S1，标签||种子） ⊕ P_SHA-1（S2，标签||种子）；

    S1是密钥的前半部分，S2是密钥的后半部分；标签是任意的字符串；种子是限制报文摘要运算长度的字符串；||是连接符，拼接左右两边的内容；

    在主密钥计算公司中，将预主密钥PMS作为PRF中的密钥，"Master-Secret"作为PRF的标签，将客户随机数NonceC和服务器随机数NonceV连接起来作为PRF的种子。

4. 第四阶段（双方发包）：身份鉴别&改变密码规范

• 身份鉴别：

  ①只要服务器V有了预主密钥PMK，就说明其有了公钥PK_V对应的私钥SK_V，则可以认为服务器V的通过身份鉴别；
  ②而要想确认服务器V拥有了预主密钥PMK，只需要确认其拥有正确的（与客户C相同）主密钥MK即可。

  所以在第四阶段，服务器V向客户C发送结束消息，其中包含了"PRF（MK，“server finished”，MD5（握手协议消息）||SHA-1（握手协议消息））"；

  随后客户C按照同样的方式，用自己手中的MK和握手协议信息也进行PRK运算，并将运算结果与服务器V结束消息中的字段对比，若相同则则服务器V的身份得到确认。

• 改变密码规范：

  后续一段时间内，双方都可以比较放心地使用协商好的安全参数（如主密钥MK）来进行通信。

握手协议小结：

1. 利用非对称加密，通过加入唯有通信双方才有的参数来生成唯二的主密钥，这里的参数是：
   ① 一对来自双方的随机数(第一轮握手时已交换)
   ② 预主密钥(由客户端生成并用服务端的公钥加密，只有服务端能用对应私钥解密得到，所以这个预主密钥也只有通信的双方才拥有)
2. ① B发送被A信任的证书链=>让A可以确定发送方的公钥和域名的绑定关系（证明B分发的公钥PK_B的确属于该域名ID_B）；
   ② 只有A确认B拥有其公钥PK_B对应的私钥SK_B时（使用数字签名技术，B用自己的私钥SK_B对明文进行D操作得到“密文”，若A能用公钥PK_B用E操作来得到“可读的明文”，则证明B的确拥有对应的私钥SK_B），这时B才算通过身份鉴别。

所以，TLS握手协议主要实现了：
Ⅰ.加密(一开始是非对称加密，后面双方共用主密钥来实现对称加密)
Ⅱ.身份鉴别(借助权威第三方和数字证书技术)

三、TLS记录协议

在客户端和服务端成功建立了TLS连接后，由TLS记录协议来封装上层的HTTP报文数据，是直接保证报文不被篡改和预防重放攻击的协议。
（可以这样理解：TLS握手协议是“销售人员”，负责对接客户，TLS记录协议是“售后工程师”，负责干活）

• TLS记录协议在发送方的工作流程一般如下：
  ① 分段
  ② 压缩
  ③ 计算MAC
  ④ 加密（此处算法不一定是示意图中的3DES，具体算法由双方在握手协议中协商）
  ⑤ 添加首部封装
  
• 接收方只需要对TLS记录协议采取上述的逆过程即可：
  ① 去掉首部拆封
  ② 解密（具体算法由握手阶段协商）
  ③ 检测数据完整性（计算比对MAC值）
  ④ 解压缩
  ⑤ 按序号重组HTTP报文
• 关于计算MAC：
  
  • 如上的情景能够确保报文不被篡改：
    发送方对数据进行消息摘要后得到一个哈希值A，并用接收方的公钥加密哈希值A。接收方收到后对数据也用相同的方法进行消息摘要得到哈希值A^’，并用私钥解密得到哈希值A，对比A^’与A，若不相同则相信报文已被篡改，不予采用。
  • 对哈希值再进行加密得到的值又称为MAC(消息校验码Message Authentication Code，注意：不是数据链路层的MAC“媒介访问控制”)，如上图中的E_PK(哈希值A)。
  • 封装好的TLS握手协议中包含一个序号字段，随着每次TLS记录协议报文的发送而自增1，将序号参与MAC计算，则可以预防重放攻击(及TLS记录报文的丢失)。

四、HTTPS的工作流程

基于SSL/TLS的HTTP，就叫HTTP over SSL或HTTP over TLS，统称为HTTPS（HTTP Secure）

• HTTPS的工作流程一般如下：
  ① 建立TCP连接
  ② 进行TLS握手，双方共享后续加密过程中涉及的密钥、参数等
  ③ TLS记录协议对HTTP报文进行处理，得到密文，实现安全传输

五、总结

HTTPS是在HTTP和TCP之间加了一个TLS协议簇（替代了先前的SSL）。

TLS协议簇主要包含了：
①TLS握手协议（帮助双方协商参数信息的协议，其中最重要的参数是主密钥：通过第三方权威机构验证身份并基于非对称密钥体制（公钥体制）协商得到一个只有你知我知的主密钥，后续一段时间内就可以使用该主密钥来使用对称密钥体制进行加解密了）

(i)非对称密钥体制（即公钥体制，加解密使用公钥和私钥）延伸难解的数学问题，从计算可行性上阻断攻击者破解出密钥（优点和缺点都是特别难算：别人难以破解，但自己加解密也很耗时）

（著名的公钥密码体制都基于了经典的数学难题，Diffie-Hellman密钥交换算法基于有限域上离散对数的难解性，RSA算法基于大整数素因子分解的困难性。不过公钥体制不能防御中间人攻击，所以应当辅以身份鉴别机制，如这里借助权威第三方CA颁发的电子证书来帮助鉴别）。

(ii)对称密钥体制（加解密使用同一密钥，这里就是主密钥）则通过精心设计加解密的算法结构保证了较高的计算效率，同时让人们难以通过分析算法来破解出密钥（优点是计算快，缺点是难以在通信双方间安全地共享一个密钥）

若您想了解更多关于公钥体制、对称密钥体制以及加解密相关的内容，欢迎阅读这篇：密码学——现代密码体制总结（别再管哈希叫加密了噢~）

TLS将两种密钥体制进行结合实现了互补：

TLS先用身份认证机制和公钥体制来在双方间安全地共享一个主密钥（公钥体制实现在通信双方间安全地协商、共享一个主密钥），
然后在后续一段时间内就可以用这个主密钥进行快速的对称加解密（对称密钥体制实现快速加解密，保证加解密效率）。

②TLS记录协议（实际对HTTP报文进行处理的协议：分段、压缩、计算MAC和加密——这里计算消息验证码MAC时可以加入序号来防止重放攻击）