SSL协议

一、体系结构

                                

（1）底层

        SSL 记录协议，它直接建立在 TCP 之上 。

        作用：负责对上层的数据进行封装。它提供两种基本服务：机密性（通过加密）和完整性（通过 MAC 校验） 。

 （2）上层

        SSL 握手协议 ：最核心部分，用于双方相互认证、协商加密算法和交换密钥 。

        SSL 密码变更规格协议 ：非常简单，用于告知对端“接下来的数据将使用我们刚协商好的加密策略进行加密” 。

         SSL 报警协议：用于指示安全错误或关闭连接 。

二、基本概念

理解 SSL 的关键在于区分 连接 和 会话  。

        连接 ：是点对点的、暂时的传输通道 。每次你打开一个网页可能就会建立一个 TCP 连接。        

        • 状态参数：包含随机数、写密钥 、写 MAC 密钥、初始化向量 (IV) 和序列号 。这些参数是每次连接都不同的        

        会话 ：是客户端和服务器之间的一种长期存在的关联关系 。一个会话可以派生出多个连接 。这样做是为了避免频繁进行昂贵的握手协商 。

        •  状态参数：包含 会话 ID、对等实体证书、主密钥 、加密规格等 。这些参数在多个连接间是共享的。

                      

三、握手协议

（1）第一阶段：建立安全能力

        Client Hello：客户端发送支持的 SSL 版本、随机数 (Client Random)、会话 ID、支持的密码套件列表 。

        Server Hello：服务器从客户端的列表中选定一个加密算法和压缩方法，生成随机数 (Server Random)，并确定会话 ID

        结果：双方确认了算法，并各自持有两个明文随机数

（2）第二阶段：服务器认证

        Certificate：服务器发送自己的数字证书（包含公钥）给客户端验证身份

        Server Key Exchange (可选)：如果公钥不足以进行密钥交换（如使用 DH 算法），服务器会发送此消息

        Server Hello Done：通知客户端“我说完了”

（3）第三阶段：客户端认证与密钥交换

        Client Key Exchange：这是关键一步。客户端生成一个 Pre-Master Secret (预主密钥)，用服务器的公钥加密后发给服务器 。

        此时：客户端和服务器都拥有了三个关键数据：
Client Random、
Server Random 和
Pre-Master Secret。双方利用这三个数，通过相同的算法计算出 Master Secret (主密钥) 。

        密钥衍生：利用主密钥，双方各自生成一套包括 MAC 密钥、加密密钥和 IV 在内的密码参数

（4）第四阶段：完成握手

        双方互发 Change Cipher Spec（表示“后面开始加密了”）和 Finished（包含握手消息的校验值，用于防篡改）

四、记录协议

一旦握手完成，应用层数据（如 HTTP）就会通过记录协议进行传输。处理流程如下：
（1）分段：将上层消息分割成不大于 16KB 的块 。

（2）压缩 ：进行无损压缩（可选，SSL v3 默认很少用） 。

（3）添加 MAC ：利用握手时生成的 MAC 密钥计算数据的哈希值，附在数据后面，用于保证完整性 。

（4）加密 ：对“数据 + MAC”作为一个整体进行加密

（5）添加头部 ：加上 SSL 记录头（包含内容类型、版本号、长度）

五、会话重用

 由于公钥加密（非对称加密）计算开销很大，SSL 提供了会话重用机制来提升性能

原理：基于 Session ID 。

（1）服务器和客户端在本地缓存
Session ID 和对应的
Master Secret

（2）当客户端发起新连接时，在
Client Hello 中带上之前的
Session ID

（3）服务器收到后，查找本地缓存。如果找到了，就直接复用之前的
Master Secret 生成新的会话密钥，跳过繁琐的证书验证和非对称密钥交换阶段 。

（4）双方直接进入 Change Cipher Spec 和 Finished 阶段。

六、形象化比喻

通过不安全的快递系统运送机密文件

体系结构：

记录协议就像防篡改的保险箱。不管里面装什么，都塞进箱子锁好再寄。

握手协议就像商量保险箱密码的过程。

握手过程：

Hello 阶段：你（客户端）给银行（服务器）打电话：“我要寄东西，我支持这些防盗锁（密码套件），这是我的临时编号（随机数）。”银行说：“好，我们就用这种锁，这是我的临时编号（随机数）。”

认证阶段：银行把它的**营业执照（证书）**寄给你。你找工商局（CA）核实执照是真的，从而确认银行身份。

密钥交换：你生成一个临时密码（Pre-Master Secret），用银行执照上的公钥（相当于银行的公开邮箱）锁起来寄给银行。只有银行有私钥能打开。

生成主密钥：现在你和银行都有了临时编号和临时密码，你们各自在计算器上按一套公式，算出了最终的保险箱密码（Master Secret）。

完成：你发短信说：“以后我都用保险箱了（Change Cipher Spec）”，然后用保险箱寄了一封信（Finished）测试一下。

记录协议：

你要寄文件（应用数据）。先把文件切碎（分段），挤出空气（压缩），在每页纸上签个名防替换（MAC），然后放进保险箱锁上（加密），最后贴上快递单（头部）。

会话重用：

下次你再来寄东西，直接报上次的会员卡号（Session ID）。银行一查：“哦，是老客户，上次约定的那个根密码我们还没忘，直接用它生成新钥匙吧。”这样就不用再查营业执照和寄临时密码了。

七、TLS与SSL的差异

TLS 修复了 SSL 中一些非标准的设计（如 MAC 算法），移除了一些过时的特性，并增强了抗分析能力（如可变填充）。

(1)版本号 

这是最直观的区别。虽然名字变了，但在协议记录格式中，TLS 1.0 的版本号实际上被定义为 SSL 3.1 。这体现了 TLS 是 SSL 的直接后续版本 。

(2)消息认证码 (MAC) 算法

两者都用于保证数据的完整性，但在算法实现上有细微差别：

 • TLS：使用了标准化的 HMAC 算法（定义在 RFC 2104 中）。

 • SSL v3.0：使用了一种相似但在填充字节和密钥拼接方式上不同的算法（采用连接运算，而 TLS 采用异或运算）。

 • 虽然计算方式不同，但两者的安全程度被认为是相当的 。

(3)伪随机函数 (PRF)

TLS：引入了称为 PRF 的伪随机函数，用于将密钥扩展成数据块 。

(4)填充机制 (Padding)

在使用分组加密（如 CBC 模式）时，需要对数据进行填充。

SSL：填充后的数据长度必须是密文块长度的最小整数倍 。这意味着攻击者可能通过密文长度推测出明文的大致长度。

TLS：填充后的长度可以是密文块长度的任意整数倍（最大填充长度可达 255 字节）。

意义：TLS 这种灵活的填充方式可以混淆实际数据长度，从而防止基于报文长度分析的攻击

(5)告警代码

TLS：支持几乎所有 SSL v3.0 的报警代码，并且为了更精确地报告错误，还补充定义了很多新的报警代码 。

(6)密码套件与证书

差异：TLS 不支持 Fortezza 密钥交换、加密算法和客户证书 。这是因为 Fortezza 是一种较老的、特定于硬件的安全机制，TLS 选择将其剔除以保持协议的通用性。

(7)关键消息的计算

在握手结束阶段，
CertificateVerify 和
Finished 消息用于验证握手过程是否被篡改。

差异：SSL v3.0 和 TLS 在使用 MD5 和 SHA-1 计算这些消息的 HMAC 时，输入的参数有少许差别 。

(8)主密钥计算 (Master Secret)

差异：TLS 和 SSL v3.0 在计算最终的 Master_Secret 时采用了不同的计算公式

八、安全威胁

1. Strip 攻击 (SSL 剥离)

这是一种利用用户习惯进行的中间人攻击。

根本原因：绝大多数用户在访问网站时（例如访问银行），习惯直接输入域名（如
www.bank.com）而不输入
https://。浏览器默认会先发起一个 HTTP 请求 。

正常流程：服务器收到 HTTP 请求后，会返回一个重定向，告诉浏览器“请用 HTTPS 访问”，然后浏览器再发起 HTTPS 连接 。

攻击原理：

中间人拦截：攻击者处于用户和服务器之间。

劫持重定向：当用户发起 HTTP 请求时，攻击者拦截该请求并转发给服务器。

剥离 SSL：服务器返回 HTTPS 重定向链接，攻击者拦截这个响应，自己和服务器建立 HTTPS 连接，但给用户返回一个 HTTP 链接 。

结果：用户 <–> 攻击者（明文 HTTP）；攻击者 <–> 服务器（加密 HTTPS）。攻击者可以看到用户的所有明文流量（密码、账号等）。

2. 重协商攻击 

这是一个基于协议逻辑漏洞的攻击。

背景：SSL 支持“重协商”，即在连接建立后，双方可以重新协商密钥或证书（比如浏览到某个页面需要验证客户端证书时）。

漏洞点：早期的 SSL 协议中，首次协商和重协商之间没有任何关联性验证 。服务器无法区分这两次协商是否来自同一个真实的客户端。

攻击流程（数据注入攻击）：

拦截与缓存：中间人拦截了受害者发出的
ClientHello，先存着不发 。

伪造连接：中间人自己向服务器发起握手（首次协商），建立连接。

发送恶意数据：中间人在加密通道里发送一段恶意请求，但故意不发完，或者利用 HTTP Keep-Alive 保持连接。

嫁接受害者：中间人现在把受害者的
ClientHello 发给服务器。服务器认为这是同一个连接上的“重协商”请求 。

拼接执行：重协商完成后，受害者的真实数据发过来了。服务器的应用层会将之前的恶意数据和现在的真实数据拼接在一起处理 。

后果：攻击者成功将恶意指令插入到了受害者的身份认证信息之前。

防御：安全重协商机制 (RFC 5746)。强制要求在重协商时，必须携带上次协商结束时的验证数据（Verify Data），证明两次协商是连续的 。

3. 三次握手攻击 

这是重协商攻击的“进阶版”，非常精妙，它利用了会话重用机制来绕过安全重协商的检查。

核心思想：攻击者通过精心构造，让受害者和攻击者、攻击者和服务器之间协商出完全相同的主密钥 。

攻击阶段：

阶段一（未知密钥共享）：攻击者让受害者访问恶意网站。通过恶意转发，攻击者在两个连接（受害者-攻击者，攻击者-服务器）中复用了相同的随机数和 Pre-Master Secret。导致三方拥有了相同的主密钥 。

阶段二（全同步）：利用会话重用。因为主密钥相同，攻击者可以让受害者的连接复用到攻击者与服务器的连接上。会话重用不需要证书验证，仅基于 Session ID 和主密钥。此时，两个连接的
Verify Data 也变得完全一致了 。

阶段三（身份仿冒）：攻击者发起重协商。因为
Verify Data 一致，安全重协商机制被绕过。受害者的客户端证书被用来验证这个“拼接”的连接，导致攻击者的恶意请求被以受害者的身份执行 。

4.心脏滴血漏洞 (Heartbleed)

这是一个基于代码实现缺陷（OpenSSL 库）的灾难级漏洞。

机制背景：TLS 引入了心跳扩展，用来保持连接活跃。客户端发一个包，服务器原样弹回来。

漏洞原理：

客户端发出的心跳包包含两个字段：Payload 内容 和 Payload 长度。

Bug：OpenSSL 代码没有检查 Payload 的实际长度是否真的等于声称的长度 。

攻击：攻击者发一个只有 1KB 数据的包，但声称长度是 64KB 。

后果：服务器程序会老实地把内存里紧接着这 1KB 数据后面的 63KB 数据都读出来，作为响应发回去 。

危害：这 63KB 内存数据是随机的，可能包含私钥、用户密码、Session ID 等极其敏感的信息 。因为可以无限次攻击，就像心脏在滴血一样，最终能把服务器掏空。