SSL 杂谈 | 易学教程

什么是 SSL

SSL (Secure Sockets Layer) 是一种在应用层和传输层之间的协议，对传输层（TCP）到应用层（HTTP）的数据进行加密，主要是为了保证 Internet 上数据传输的安全性，确保数据在传输过程中不被截取或监听

SSL 在技术上位与应用层，但从开发者的角度来看，它是一个提供 TCP 服务的传输层协议

TLS（Transport Layer Security）是 SSL 的继任者，在很多场合还是用 SSL 来指代 SSL/TLS

基本大部分支持 SSL 加密数据的服务器，都是采用 OpenSSL 库来实现的

OpenSSL是一个强大的安全套接字层密码库，Apache使用它加密HTTPS，OpenSSH使用它加密SSH，它还是一个多用途的、跨平台的密码工具

SSL 协议的安全机制

SSL 通过以下三种机制，实现了网络通信的安全性

1. 数据传输的机密性
通过对称/非对称加密算法，在通信双方之间建立加密通道，保证数据传输的机密性
2. 身份验证机制
使用数字签名来验证通信对端的身份
3. 消息完整性验证
基于 md5/sha 等 hash 算法来保证消息的完整性，避免网络中传输的数据被非法篡改

SSL 的工作原理

简单了解下网络通信加密的发展过程，假设 A 和 B 之间需要网络通信

远古

远古时期民风淳朴，路不拾遗、夜不闭户，A 要发数据给 B，直接发就好，根本用不担心数据会被窃听和篡改

上古

上古时期出现了这样一类人 C，C 不但窃听 A 和 B 之间的网络数据，还会拦截 A 与 B 之间的信息，然后伪造后再发会给 A/B，C 就是中间人攻击（Man In The Middle Attack）

为了应对 C 的攻击，A 和 B 开始对自己的数据进行加密

A 和 B 会使用一个共享的密钥，A 在发送数据之前使用这个密钥加密，B 在收到数据之后，会用这个密钥进行解密
由于加解密使用的是同一个密钥，所以这类加密算法被称为对称加密算法

对称加密算法

在 1981 年，DES（Data Encryption Standard）被提出，这是一种对称加密算法
DES 使用一个 56 bit 的密钥来完成数据的加解密，尽管看起来有点短，但是在上古时代 56 bit 已经够用了

但是又引发了一个新的问题，A 和 B 需要共享一个 56 bit 的密钥，并且这个密钥需要保持私密，否则让 C 拿到这个密钥就失去了加密的意义
首先 A 和 B 不能通过网络来传递密钥，在密钥确定前所有的通信都是不安全的，密钥有可能被 C 拦截；A 和 B 必须见面约定好密钥，如果因为任何原因该密钥泄漏了，A 和 B 必须再重新见面约定一个新的密钥

现在 A B 之间，只要保证了密钥的安全，那么整个网络通信就是安全的

中古

随着技术的发展，计算机速度变的越来越快，快到可以通过暴力破解的方法来解密经过 DES 加密的信息
在上古时代，破解 56 bit 密钥需要的时间非常长，而在中古时代可能只需要几天就可以破解 56 bit 的密钥

为了应对这个情况提出了新的协议，例如 AES（Advanced Encryption Standard）将使用 256 bit 的密钥来进行加解密，至少在可预见的将来，计算机无法在有限的时间内来破解这个密钥
所以在中古时代，主要应用将对称加密算法的密钥长度变长，来应对中间人攻击；A 和 B 仍需要见面约定一个密钥

现代

到了现代，网络通信十分发达，A 不止和 B 通信，还同时和 N 个人进行网络通信，A 不可能跑去和每个人都见面商量一个密钥

所以一种新的加密算法被提出，就是非对称加密算法
非对称加密算法使用两个密钥，一个 Public Key 和一个 Private Key，通过特殊的算法来实现加解密使用不同的密钥，所以称为非对称加密算法

非对称加密算法

非对称加密算法最著名的是 RSA 算法，其中 Public Key 和 Private Key 是数学相关的，但是现有的算法无法从一个密钥来推导出另一个密钥

非对称加解密流程：

A 和 B 在本地生成配对的 Public Key 和 Private Key，保留 Private Key 并通过网络交换 Public Key
假设 A 要给 B 发送数据，A 先把数据经过 Hash 处理后生成摘要信息 Digest 1，并使用自己的 Private Key 加密数据的 Digest 生成数字签名
然后再用 B 的 Public Key 加密数据本身，A 将数字签名和加密后的数据，再加上一些其他信息（如 nonce 等注1 ）通过网络发送给 B
B 收到数据后，使用 A 的 Public Key 解密数字签名，如果能成功解密获取 Digest 1，则说明该数据是 A 发来的
B 使用自己的 Private Key 解密数据后，做同样的 Hash 处理生成 Digest 2，与 Digest 1 对比；
如果两者相等，表示数据没有被篡改，否则该数据则被视为无效丢弃

非对称加密算法的优点在于，A 可以保留 Private Key，通过网络传递 Public Key；即使 Public Key 被 C 拦截了，因为没有 Private Key，C 还是没有办法完成信息的破解
既然不怕 C 知道 Public Key，那么 A 和 B 通信不需要再见面商量密钥，直接通过网络传递 Public Key 即可
并且通过数字签名，可以确保数据来源的安全性，且不会被篡改

非对称加密的安全隐患

按照非对称加密的方案，在 A 与 B 通信的最开始，需要通过网络交换 Public Key，但是如果 C 在中间拦截了呢？
假设有这种情况：

当 A 给 B 发消息，A 生成数字签名后，使用 C 传来的 Public Key (Fake) 加密了数据
C 拦截了数据包，使用 C 的 Private Key 解密，得到原始数据
C 使用自己的 Private Key 生成数字签名，再用 B 的 Public Key 加密数据，发送给 B
B 收到数据后，使用 C 的 Public Key (Fake) 解密数字签名，对比 Digest 后发现匹配，以为该数据是 A 发来的，中间人攻击仍可能存在

这一下又回到了上古时代，为了保证 Public Key 不被拦截，A 和 B 仍需要见面交换 Public Key
但是和上古时代不一样，见面的实质已经变了
在上古时代，见面是为了商量一个密钥，密钥的内容很重要，不能泄露；而在现代，见面是为了确认 Public Key 的真实性，Public Key 的内容是可以公开的

那么如果有其他方法能保证 Public Key 的真实性，A 和 B 是可以不用见面的

CA

现实中，通过 CA（Certificate Authority）来保证 Public Key 的真实性

CA 在数字世界里是一个权威的机构，CA 签发证书是很严肃的，它有一系列手段来检查申请签发的是不是某个人（或机构 / 组织 / 企业）

一个网站有了 CA 签发的证书

A/B 会把自己的 Public Key 交给 CA，CA 用自己的 Private Key 加密，加密完成的数据称为数字证书
现在 A 要给 B 传递 Public Key，B 传递的是 CA 加密后的数字证书；A 收到以后，会通过 CA 颁发的 CA 证书（包含了 CA 的 Public Key）来解密 B 的数字证书，从而安全的得到 B 的 Public Key

那么如何确保 CA 证书不被劫持呢？中间人 C 可以把一个假的 CA 证书发给 B，从而欺骗 B ？
不存在的，CA 把自己的 CA 证书集成在了浏览器和操作系统里面，当 B 使用浏览器或者操作系统的时候，已经获得了 CA 证书，不必再从网络获取，自然不存在劫持的问题

现在 A 和 B 都有了 CA 证书，在交换 Public Key 的阶段，直接交换彼此的数字证书即可
中间人 C 可以拦截 A 和 B 的数字证书，也可以通过 CA 证书解密获得 A 和 B 的 Public Key，但是 C 因为 C 不在 CA 体系中，没有 CA 的 Private Key，无法伪造出一个可以通过 CA 认证的数字证书，A 和 B 自然也不会相信伪造的证书
所以采用 CA 认证后，A 和 B 的 Public Key 真实性得到了保证，A 和 B 可以通过网络来交换 Public Key（实际上是被 CA 加密后的数字证书）