1 TLS/SSL 发展历程

TLS/SSL 设计之初是为了达到身份验证、保密性、完整性的目的。到现在发展已经 20 多年了，也出现多许多严重的 BUG 和各种事件。现在主流的版本是是 TLS 1.1、TLS 1.2、1、TLS 1.3。 SSL Labs 这个网站可以查询某个网站支持的加密协议。

SSL 协议实现的安全机制包括：

• 数据传输的机密性：利用对称密钥算法对传输的数据进行加密。
• 身份验证机制：基于证书利用数字签名方法对服务器和客户端进行身份验证，其中客户端的身份验证是可选的。
• 消息完整性验证：消息传输过程中使用 MAC 算法来检验消息的完整性。

2 对称加密(AES)

对称加密是最快速、最简单的一种加密方式，加密（encryption）与解密（decryption）用的是同样的密钥（secret key）。对称加密有很多种算法，由于它效率很高，所以被广泛使用在很多加密协议的核心当中。

2.1 XOR 异或运算

对称加密最主要的操作是异或 XOR，从上图可以看出明文 XOR 密钥 = 密文、密文 XOR 密钥 = 明文，优点是只用遍历执行异或非常快。

2.2 分组、填充

对称加密、解密执行异或的密文和明文的长度必须要完全一致，一般密钥在 128、256 字节左右，但是密文可能到 KB、MB 级别，将明文分成多个等长的 Block 模块，对每个模块进行分组加密。但是明文不可能刚好是 128、256 的整数倍，所以需要对最后一个 BLock 进行填充，填充有以下两类方法。

• 位填充：以 bit 位为单位来填充
  • … | 1011 1001 1101 0100 0010 0111 0000 0000 |
• 字节填充：以字节为单位为填充
  • 补零：… | DD DD DD DD DD DD DD DD | DD DD DD DD 00 00 00 00 |
  • ANSI X9.23：… | DD DD DD DD DD DD DD DD | DD DD DD DD 00 00 00 04 |
  • ISO 10126：… | DD DD DD DD DD DD DD DD | DD DD DD DD 81 A6 23 04 |
  • PKCS7 （RFC 5652⁸）：… | DD DD DD DD DD DD DD DD | DD DD DD DD 04 04 04 04 |

现在 AES 主要是用 PKCS7 对明文进行填充。

2.3 分组工作模式

明文一般都会很大如果顺序加密会非常耗时，一般是对明文按照一定规则拆分出多个Block，再利用计算机多核优势同时对多个 Block 进行加密，Block cipher mode of operation⁹。

2.3.1 ECB（Electronic codebook）模式

因为是用同一个密文加密，加密后数据可能如中间的企鹅和左边边的企鹅有很高的相似性，攻击者很容易推导初明文的一些特征。我们更加希望加密后的数据如右边的企鹅全是噪点没有任何特征。

2.3.2 CBC（Cipher-block chaining）模式

CBC模式每组明文先和前一组密文进行异或后，再进行加密，这样密文就完全失去特征了。但是由于每个 Block 都需要等前一个加密完成后才能开始，所以只能串行化无法利用多核 CPU 性能，性能堪忧。

2.3.3 CTR（Counter）模式

CTP使用了一个 随机数+递增的计数器 来替换CBC的前一个密文，这样就可以减少特征的同时保证性能。但是不能验证密文的完整性的。

2.3.4 GCM Galois/counter

像在 CTR 中一样，对块进行顺序编号，然后将该块编号与 IV 组合并使用块密码 E（通常为 AES ）进行加密。然后，将这种加密的结果与明文进行 XOR 运算，以生成密文。像所有计数器模式一样，这本质上是流密码，因此对每个加密的流使用不同的 IV 至关重要。

2.4 AES 加密算法

AES(Advanced Encryption Standard¹⁰) 一般使用PKCS7来填充明文，使用GCM的分组工作模式来加密，分组长度是 128 位比特

• 把明文按照 128bit（16 字节）拆分成若干个明文块，每个明文块是 4*4 矩阵
• 按照选择的填充方式来填充最后一个明文块
• 每一个明文块利用 AES 加密器和密钥，加密成密文块
• 拼接所有的密文块，成为最终的密文结果

C = E(K,P)，E 为每一轮算法，每轮密钥皆不同

• 初始轮
  • AddRoundKey 轮密钥加
• 普通轮
  • AddRoundKey 轮密钥加
  • SubBytes 字节替代
  • ShiftRows 行移位
  • MixColumns 列混合
• 最终轮
  • SubBytes 字节替代
  • ShiftRows 行移位
  • AddRoundKey 轮密钥加

3 非对称加密(RSA)

RSA¹¹算法是一种非对称密码算法； 这意味着它使用了公共密钥和私有密钥（即两个不同的，数学上链接的密钥）。 顾名思义，公钥是公开共享的，而私钥是秘密的，不能与任何人共享。其原理如下图。

3.1 公私钥的产生

• 随机选择两个不相等的质数 p 和 q
• 计算 p 和 q 的乘积 n（明文小于 n）
• 计算 n 的欧拉函数 v=φ(n)
• 随机选择一个整数 k 满足：1< k < v，且 k 与 v 互质
• 计算 k 对于 v 的模反元素 d
• 公钥：(k,n)
• 私钥： (d,n)

3.2 加解密的流程

• 加密：c ≡ mk (mod n)
  • m 是明文，c 是密文
• 解密：m ≡ cd (mod n)
• 举例：对明文数字 123 加解密
  • 公钥（3,319）加密
    • 123^3 mod 319 = 140
    • 对 140 密文用私钥（187,319）解密
      • 140^187 mod 319 = 123
• 私钥（187,319）加密
  • 123^187 mod 319 = 161
  • 公钥（3,319）解密
    • 161^3 mod 319 = 123

假定一个第三方的攻击者，拿到了共钥需要对n进行因式分解，然而n是 2 个大质数的乘积，所以对n进行因式分解是很难的，也就认为 RSA 是安全的。

4 PKI 证书体系

PKI(Public key infrastructure)¹² 是一组角色，策略，硬件，软件和创建，管理，分发所需的程序，使用，储存和吊销数字证书和管理公共密钥加密。PKI 的目的是为一系列网络活动（如电子商务，互联网银行和机密电子邮件）促进安全的信息电子传输。对于简单的密码不足以进行身份 ​​ 验证的活动，并且需要更严格的证据来确认通信中有关各方的身份并验证所传输的信息，这是必需的。

证书生成流程¹³:

• 签名
  • 对用户信息进行 HASH 加密得到HASH值
  • CA 机构的私钥加密HASH值得到一串密文
  • 用户信息(明文)、密文、 HASH 值、网站共钥打包后得到证书
• 验证签名
  • 将证书中的用户信息(明文)按照证书中的 HASH 算法加密得到HASH值1
  • 用 ROOT 证书中的共钥解密密文得到 HASH值2
  • 比较HASH值1于HASH值2是否相等

由于 ROOT 证书较少，但是用户证书数量较为庞大，不便管理。所以诞生了一个中间商(权威证书机构)

现在证书申请机构变成了这样。

4 DH 密钥交换

DH(Diffie–Hellman key exchange)¹⁴ 它可以让双方在完全没有对方任何预先信息的条件下通过不安全信道创建起一个密钥。

如果图所示，在双发有密钥对的情况下，用某种算法 对方公钥与己方私钥 生成相同的一个密钥，然后以这种密钥对称加密数据后进行通信。

这种也有一个问题，如果恶意的中间人最开始将双方共钥拿到收，还是可以做伪造数据。所以实际上会用根证书对server的公钥进行验证，有权威机构进行背书中间人攻击时会验证不通过。

5 TLS 1.2 vs TLS 1.3

TLS1.2 与 TLS1.3 做了许多优化， 可以先用Wireshark抓包分析下数据包下载地址。

TLS1.2

1. Client 发送 Client Hello 消息包含以下重要信息 - NO.24
   1. TLS 版本 1.1、1.2、1.2 - tls.handshake.version
   2. CLient 随机数 - tls.handshake.random
   3. Client 支持的加密算法列表 - tls.handshake.ciphersuites
   4. Client 请求 Server 的 HostName - tls.handshake.extensions_server_name
   5. CLient 支持的分组加密模式列表 - tls.handshake.extensions_supported_groups
2. Server 回复 Sserver Hello 消息包含以下重要信息 - NO.26
   1. TLS 版本 TLS 1.2 - tls.handshake.version
   2. Server 随机数 - tls.handshake.random
   3. 协商后确定使用的加密算法 - tls.handshake.ciphersuite
3. Server 回复 证书信息 消息包含以下重要信息 - NO.27
   1. TLS 版本 TLS 1.2 - tls.handshake.version
   2. 证书列表 - tls.handshake.certificates
4. Server 回复 Server Key Exchange 消息包含以下重要信息 - NO.27
   1. TLS 版本 TLS 1.2 - tls.handshake.version
   2. 公钥 - tls.handshake.server_point
   3. 签名算法 - tls.handshake.sig_hash_alg
   4. 密文 - tls.handshake.sig
5. Server 回复 Server Hello Done 消息包含以下重要信息 - NO.27
   1. TLS 版本 TLS 1.2 - tls.handshake.version
   2. 类型 - tls.handshake.type
6. Client 向 Server 发送 Cleint Key Exchange 消息包含以下重要信息 - NO.27
   1. TLS 版本 TLS 1.2 - tls.handshake.version
   2. Client 共钥 - tls.handshake.client_point
7. Client 向 Server 发送 Change Cipher Spec 消息包含以下重要信息 - NO.27
   1. TLS 版本 TLS 1.2 - tls.handshake.version
8. Client 向 Server 发送 Encrypted Handshake Message 消息包含以下重要信息 - NO.27
   1. TLS 版本 TLS 1.2 - tls.handshake.version
   2. 数据类型 - tls.record.content_type
   3. 加密后的信息 - tls.handshake
9. Server 向 CLient 发送 New Session Ticket, Change Cipher Spec, Encrypted Handshake Message 消息包含以下重要信息 - NO.27
   1. Session Ticket tls.handshake.session_ticket
   2. 更换加密数据 - tls.change_cipher_spec
   3. 加密后的数据 - tls.handshake

31 17m 53.445508s 47.242.88.10 192.168.130.143 TLSv1.2 340 New Session Ticket, Change Cipher Spec, Encrypted Handshake Message

http://apps.identrust.com/roots/dstrootcax3.p7c 400175048314a4c8218c84a90c16cddf x509af.serialNumber

5.1 更快的 TLS 握手

TLS(Transport Layer Security)加密和 SSL 解密需要 CPU 时间，并增加了网络通信的延迟，从而在一定程度上降低了性能。在 TLS 1.2 中，初始握手是以明文形式进行的，这意味着即使是握手也需要进行加密和解密。考虑到典型的握手过程涉及客户端与服务器之间交换 5 到 7 个数据包，因此这增加了连接的开销。在版本 1.3 下，默认情况下采用服务器证书加密，从而可以使用 0 – 3 个数据包执行 TLS 握手，从而减少或消除了这种开销，并允许更快，响应更快的连接。

5.2 更简单，更强大的密码套件

除了减少 TLS 握手期间要交换的数据包数量之外，1.3 版还缩小了用于加密的密码套件的大小。在 TLS 1.2 和更早版本中，使用具有加密漏洞的密码会带来潜在的安全漏洞。TLS 1.3 仅支持当前没有已知漏洞的算法，包括不支持完全前向保密（PFS）的算法。此更新还删除了执行“重新协商”的功能，在该功能中，已经具有 TLS 连接的客户端和服务器可以协商新参数并生成新密钥，此功能可能会增加风险。

TLS 1.3 支持的加密算法:

• TLS13-AES-256-GCM-SHA384
• TLS13-CHACHA20-POLY1305-SHA256
• TLS13-AES-128-GCM-SHA256
• TLS13-AES-128-CCM-8-SHA256
• TLS13-AES-128-CCM-SHA256

5.3 零往返时间（0-RTT）

与 SSL 一样，TLS 依靠密钥交换来建立安全会话。在早期版本中，可以在握手期间使用以下两种机制之一交换密钥：静态 RSA 密钥或 Diffie-Hellman 密钥。在 TLS 1.3 中，已删除 RSA，以及所有静态（非 PFS）密钥交换，同时保留了短暂的 Diffie-Hellman 密钥。除了消除静态密钥带来的安全风险（如果非法访问会损害安全性）之外，它完全依赖于 Diffie-Hellman 系列，允许客户端在其“ hello”期间发送生成密钥所需的必要随机数和输入。通过消除整个握手过程，可以节省时间并提高站点的整体性能。此外，在访问以前访问过的站点时，客户端可以利用先前会话中的预共享密钥（PSK）将第一条消息上的数据发送到服务器，因此“零往返时间”（0- RTT）。

Experimenting with Post-Quantum Cryptography ¹⁵ An overview of TLS 1.3¹⁶

6 哪些情况下 HTTPS 也不安全

6.1 流氓 VPN 预装根证书

最直接了莫过于从源头打击，任你各种牛叉的算法，我直接强制把根证书安装到你的电脑，你的流量还都经过我的的节点，在我面前被看的什么都不剩。最典型的就是国内某信开发的 EC 软件。

6.2 权威证书机构作死

…

7 参考