【网络】SSL/TLS介绍

一、SSL/TLS 概述

SSL（Secure Socket Layer） ：最初由网景（Netscape）开发，用于在客户端和服务器之间建立安全的加密连接，防止数据被窃取或篡改。后来逐步演进，最终被 TLS 取代。
TLS（Transport Layer Security） ： TLS 是 SSL 的后继协议，目前已经成为互联网安全通信的标准。它不仅实现了数据加密，还提供了身份验证和数据完整性保护，确保双方通信时的信息保密且未被篡改。

在这里插入图片描述

SSL/TLS协议提供的服务主要有：

认证用户和服务器，确保数据发送到正确的客户机和服务器；
加密数据以防止数据中途被窃取；
维护数据的完整性，确保数据在传输过程中不被改变。

在这里插入图片描述

TLS与SSL的差异

版本号：TLS记录格式与SSL记录格式相同，但版本号的值不同，TLS的版本1.0使用的版本号为SSLv3.1。
报文鉴别码：SSLv3.0和TLS的MAC算法及MAC计算的范围不同。TLS使用了RFC-2104定义的HMAC算法。SSLv3.0使用了相似的算法，两者差别在于SSLv3.0中，填充字节与密钥之间采用的是连接运算，而HMAC算法采用的是异或运算。但是两者的安全程度是相同的。
伪随机函数：TLS使用了称为PRF的伪随机函数来将密钥扩展成数据块，是更安全的方式。
报警代码：TLS支持几乎所有的SSLv3.0报警代码，而且TLS还补充定义了很多报警代码，如解密失败（decryption_failed）、记录溢出（record_overflow）、未知CA（unknown_ca）、拒绝访问（access_denied）等。
密文族和客户证书：SSLv3.0和TLS存在少量差别，即TLS不支持Fortezza密钥交换、加密算法和客户证书。
certificate_verify和finished消息：SSLv3.0和TLS在用certificate_verify和finished消息计算MD5和SHA-1散列码时，计算的输入有少许差别，但安全性相当。
加密计算：TLS与SSLv3.0在计算主密值（master secret）时采用的方式不同。
填充：用户数据加密之前需要增加的填充字节。在SSL中，填充后的数据长度要达到密文块长度的最小整数倍。而在TLS中，填充后的数据长度可以是密文块长度的任意整数倍（但填充的最大长度为255字节），这种方式可以防止基于对报文长度进行分析的攻击。

TLS的主要增强内容

TLS的主要目标是使SSL更安全，并使协议的规范更精确和完善。TLS 在SSL v3.0 的基础上，提供了以下增强内容：

更安全的MAC算法
更严密的警报
“灰色区域”规范的更明确的定义

TLS对于安全性的改进

对于消息认证使用密钥散列法：TLS 使用“消息认证代码的密钥散列法”（HMAC），当记录在开放的网络（如因特网）上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用的（消息认证代码）MAC 功能更安全。
增强的伪随机功能（PRF）：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。
改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。
一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。
特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

二、SSL/TLS 协议流程

2.1 对称加密

对称加密是指在加密和解密数据时使用相同的密钥。发送者使用该密钥将明文转换为密文，而接收者则使用同一密钥将密文还原为原始数据。

加密过程：发送方用密钥 K 加密明文 P，得到密文 C = Encrypt(K, P)
解密过程：接收方必须用相同的密钥 K 解密密文，得到 P = Decrypt(K, C)

关键点：双方必须共享同一个密钥 K，因此密钥必须从发送方传递给接收方。

优点

速度快：对称加密算法通常计算效率高，适合大数据量的加密。
实现简单：算法相对简单，资源占用较少。

缺点

密钥分发问题：双方必须共享同一个密钥，如何安全地传递这个密钥是一个关键问题。如果密钥在传输过程中被截获，数据安全就会受到严重威胁。

2.2 非对称加密

非对称加密（如 RSA、ECC）的核心特性是使用一对关联的密钥：公钥（公开） 和 私钥（私密）。在传输密钥时，其逻辑与对称加密完全不同，核心在于：公钥可公开传输，私钥绝不外传，且主要用于安全传输对称加密的密钥。

公钥：可以公开给任何人，用于加密数据或验证数字签名。
私钥：仅由持有者保管，用于解密数据或生成数字签名。

优点

安全的密钥分发：无需通过安全渠道传输私密密钥，公钥可以公开分发，极大降低了密钥泄露风险。
数字签名：可以使用私钥生成签名，别人可以用公钥验证数据的完整性和真实性。

缺点

计算速度较慢：相比对称加密，非对称加密在计算上更为复杂，因此通常只用于加密小数据量或者用来交换对称加密所使用的密钥。

常见算法 如 RSA、ECC（椭圆曲线加密）等。

2.3 公钥和私钥

公钥（Public Key）

定义：可以公开传播的密钥，任何人都能获取。
特性：
- 用于加密数据或验证数字签名，但无法解密自己加密的内容。
- 相当于一把 “公开的锁”，任何人都能用这把锁加密信息，但只有持有对应钥匙的人才能打开。

私钥（Private Key）

定义：必须严格保密的密钥，仅由所有者持有。
特性：
- 用于解密公钥加密的数据或生成数字签名，是加密体系的安全核心。
- 相当于 “唯一的钥匙”，一旦泄露，整个加密体系将失效。

公钥的用途

加密数据：发送方用接收方的公钥加密信息，确保只有接收方（持有私钥）能解密。
（例：HTTPS 中客户端用服务器公钥加密对称密钥）。
验证签名：用于验证某段数据是否由对应的私钥持有者生成（数字签名的核心逻辑）。

私钥的用途

解密数据：解公钥加密的信息，获取原始内容。
生成签名：对数据进行签名，证明数据由私钥持有者发出，且未被篡改（如 SSL 证书签名、Git commit 签名）

2.4 TLS证书

TLS 证书的本质与核心作用

定义：TLS 证书是一种遵循 X.509 标准 的数字文档，用于证明 “网络实体（如服务器、客户端）的身份” 与 “其公钥的合法性”，本质是 公钥与身份的绑定凭证

TLS 证书的关键组成部分（X.509 格式）

一张标准的 TLS 证书包含以下核心字段（以服务器证书为例）：

主体信息（Subject）：
- 证书持有者的身份标识，如域名（www.example.com）、组织名称（企业）、国家 / 地区等。
- 关键字段：Common Name (CN) 或 Subject Alternative Name (SAN)，必须与访问的域名严格匹配（如证书 CN 为example.com，无法用于www.example.com，会触发浏览器警告）。
公钥（Public Key）：
- 服务器用于非对称加密的公钥（如 RSA 2048 位或 ECC 密钥），客户端通过证书获取该公钥。
颁发机构（Issuer）：
- 签发证书的 CA（Certificate Authority，证书权威机构）名称，如 DigiCert、Let’s Encrypt。
有效期（Validity）：
- 证书生效的起止时间，过期后客户端会拒绝连接（需重新申请证书）。
数字签名（Signature）：
- CA 使用自身私钥对证书内容（除签名外的所有字段）进行哈希和加密，形成签名。客户端用 CA 的公钥验证签名，确保证书未被篡改。
序列号（Serial Number）：
- CA 为证书分配的唯一标识符，用于吊销时标识证书。

证书的颁发流程：CA 如何 “盖章认证”？

服务器申请证书（CSR 生成）：
- 服务器生成密钥对（公钥 + 私钥），并使用公钥和身份信息生成证书签名请求（CSR），包含域名、组织信息等。
CA 审核与签名：
- CA 对服务器身份进行验证（如域名所有权、企业合法性），审核通过后，用自身私钥对 CSR 内容签名，生成最终的 TLS 证书。
- CA 的信任基础：CA 的根证书已预装在操作系统、浏览器中（如 Windows、Chrome 内置数百个根 CA 证书），客户端信任 CA 的签名。
证书分发：
- 服务器将证书部署到服务器端，供客户端在 TLS 握手时获取。

2.5 SSL/TLS 握手过程

TLS（Transport Layer Security，传输层安全）握手是客户端与服务器建立安全通信的核心过程，其目标是：协商加密算法、验证身份、生成共享密钥，确保后续数据传输的机密性和完整性
在这里插入图片描述

第一阶段：客户端发起握手（ClientHello）

客户端发送的关键信息：
- 版本号：声明支持的 TLS 最高版本（如 TLS 1.2）。
- 随机数（Client Random）：一个 32 字节的随机数，用于后续生成密钥。
- 密码套件列表：客户端支持的加密算法组合（如TLS_RSA_WITH_AES_256_GCM_SHA384，包含密钥交换算法、对称加密算法、哈希算法）。
- 扩展字段：可选信息（如 SNI 域名、压缩算法等）。
核心目的：
告知服务器 “我想建立安全连接，并提供了可选的加密方案”。

第二阶段：服务器响应（ServerHello + 证书 + 密钥交换）

ServerHello 消息：
- 选择版本：服务器从客户端支持的版本中选择最高兼容版本。
- 随机数（Server Random）：另一个 32 字节随机数，与 Client Random 共同构成密钥生成的基础。
- 选定密码套件：从客户端列表中选择一个具体的加密方案。
- 扩展字段：返回服务器配置（如证书类型）。
服务器证书（Certificate）：
- 服务器发送自己的数字证书（含公钥），证书由 CA（证书颁发机构）签名，用于证明服务器身份。
- 客户端验证证书：检查证书是否过期、CA 是否可信、域名是否匹配（防止中间人攻击）。
密钥交换相关消息（如 ServerKeyExchange）：
- 若密码套件使用 RSA 等算法，服务器直接在证书中提供公钥；若使用 DH（Diffie-Hellman）等算法，服务器会发送用于密钥协商的参数。
ServerHelloDone：
服务器告知客户端 “握手参数已发送完毕”。

第三阶段：客户端验证与密钥生成

客户端验证服务器身份：
- 通过服务器证书中的公钥，验证证书签名是否有效（使用 CA 的根公钥），确认服务器合法性。
生成预主密钥（Pre-Master Secret）：
- 客户端生成一个 48 字节的随机数，用服务器公钥加密（非对称加密），发送给服务器（即ClientKeyExchange 消息）。
- 只有服务器能用私钥解密该数据，获取预主密钥。
计算主密钥（Master Secret）：
- 客户端和服务器分别用以下数据生成相同的主密钥：
  Master Secret = PRF(Pre-Master Secret, "master secret", Client Random + Server Random)
  其中 PRF 是伪随机函数，确保输出的密钥随机性。
生成会话密钥（Session Keys）：
- 主密钥进一步衍生出多组密钥，用于后续通信：
  - 加密密钥：客户端和服务器各一套，用于数据加密。
  - MAC 密钥：用于计算消息认证码（HMAC），确保数据完整性。

第四阶段：密钥验证与握手完成

客户端发送 ChangeCipherSpec：
告知服务器 “后续通信将使用新协商的加密算法和密钥”。
客户端发送 Finished 消息：
- 用刚生成的加密密钥，对握手过程中的所有消息哈希值进行加密，发送给服务器（用于验证密钥正确性和握手完整性）。
服务器响应 ChangeCipherSpec：
确认切换到新的加密机制。
服务器发送 Finished 消息：
同样用加密密钥对握手消息哈希加密，回传给客户端，完成双向验证。

2.6 握手后的通信

握手完成后，客户端与服务器用对称加密算法（如 AES）和会话密钥进行数据传输，每次通信都附带 HMAC 确保完整性。
非对称加密仅在握手阶段用于密钥交换，避免了大量数据加密的性能损耗。

密钥生成：双方协商，不对外暴露

TLS 握手时，对称加密的会话密钥由以下步骤生成（以 RSA 握手为例）：
1. 客户端生成预主密钥（随机数），用服务器公钥加密后发送（此时公钥仅用于保护预主密钥的传输）。
2. 服务器用私钥解密得到预主密钥，双方再结合各自的随机数（Client Random + Server Random），通过伪随机函数（PRF）生成主密钥（Master Secret）。
3. 主密钥进一步衍生出对称加密所需的会话密钥（如客户端发送密钥、服务器发送密钥等）。

整个过程中，会话密钥的生成依赖于双方的随机数和预主密钥，而预主密钥在传输时被服务器公钥加密，中间人无法破解（因无服务器私钥），因此会话密钥仅双方可知

密钥保密：不公开传输，仅内存持有

会话密钥从未通过网络公开传输，仅存在于客户端和服务器的内存中，用于数据加密 / 解密。
即使网络中截获密文，由于不知道会话密钥，也无法解密数据（对称加密的安全性依赖于密钥的保密性）。

在这里插入图片描述

三、总结

TLS 的安全性与实践要点

安全增强：
- 前向保密（FS）：使用 ECDHE 等算法，即使服务器私钥泄露，历史会话也无法解密。
- 证书透明度：强制 CA 将证书记录在公开日志，防止伪造证书。
常见问题：
- 证书过期 / 域名不匹配：浏览器会提示 “连接不安全”，需及时更新证书或确保域名与证书 CN/SAN 一致。
- 中间人攻击：若 CA 私钥泄露或证书链验证失败，可能导致加密失效，需依赖浏览器内置的根 CA 信任机制防范。