为HTTP穿上盔甲：HTTPS

2020-11-04 本文已影响0人码农架构

HTTP，SSL/TLS 和 HTTPS

四大类安全问题:

Interception：拦截。传输的消息可以被中间人 C 截获，并泄露数据。
Spoofing：伪装。A 和 B 都可能被 C 冒名顶替，因此消息传输变成了 C 发送到 B，或者 A 发送到 C。
Falsification：篡改。C 改写了传输的消息，因此 B 收到了一条被篡改的消息而不知情。
Repudiation：否认。这一类没有 C 什么事，而是由于 A 或 B 不安好心。A 把消息成功发送了，但之后 A 否认这件事发生过；或者 B 其实收到了消息，但是否认他收到过。

与其重新设计一套安全传输方案，倒不如发挥一点拿来主义的精神，把已有的和成熟的安全协议直接拿过来套用，最好它位于呈现层（Presentation Layer），因此正好加塞在 HTTP 所在的应用层（Application Layer）下面，这样这个过程对于 HTTP 本身透明，也不影响原本 HTTP 以下的协议（例如 TCP）。

这个协议就是 SSL/TLS，它使得上面四大问题中，和传输本身密切相关的前三大问题都可以得到解决（第四个问题还需要引入数字签名来解决）。于是，HTTP 摇身一变成了 HTTPS：

<pre class="cm-s-default" style="color: rgb(89, 89, 89); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);">HTTP + SSL/TLS = HTTPS</pre>

SSL 和 TLS，下面简要说明下二者关系。

SSL 指的是 Secure Socket Layer，而 TLS 指的是 Transport Layer Security，事实上，一开始只有 SSL，但是在 3.0 版本之后，SSL 被标准化并通过 RFC 2246 以 SSL 为基础建立了 TLS 的第一个版本，因此可以简单地认为 SSL 和 TLS 是具备父子衍生关系的同一类安全协议。

动手捕获 TLS 报文

image.png

对称性和非对称性加密

对称性加密（Symmetric Cryptography），指的是加密和解密使用相同的密钥。

这种方式相对简单，加密解密速度快
由于加密和解密需要使用相同的密钥，如何安全地传递密钥，往往成为一个难题。

非对称性加密（Asymmetric Cryptography），指的是数据加密和解密需要使用不同的密钥。

通常一个被称为公钥（Public Key），另一个被称为私钥（Private Key），二者一般同时生成，但是公钥往往可以公开和传播，而私钥不能。经过公钥加密的数据，需要用私钥才能解密；反之亦然。
这种方法较为复杂，且性能较差，好处就是由于加密和解密的密钥具有相对独立性，公钥可以放心地传播出去，不用担心安全性问题。

TLS 连接建立原理

整个连接建立的握手过程了:

image.png

Step 1: Client Hello

客户端很有礼貌，先向服务端打了个招呼，并携带以下信息：

客户端产生的随机数 A；
客户端支持的加密方法列表。

Step 2: Server Hello

服务端也很有礼貌，向客户端回了个招呼：

服务端产生的随机数 B；
服务端根据客户端的支持情况确定出的加密方法组合（Cipher Suite）。

Step 3: Certificate, Server Key Exchange, Server Hello Done

服务端在招呼之后也紧跟着告知：

Certificate，证书信息，证书包含了服务端生成的公钥。

客户端收到消息后，验证确认证书真实有效，那么这个证书里面的公钥也就是可信的了。

接着客户端再生成一个随机数 C（Pre-master Secret），于是现在共有随机数 A、B 和 C，根据约好的加密方法组合，三者可生成新的密钥 X（Master Secret），而由 X 可继续生成真正用于后续数据进行加密和解密的对称密钥。

因为它是在本次 TLS 会话中生成的，所以也被称为会话密钥（Session Secret）。简言之：

<pre class="cm-s-default" style="color: rgb(89, 89, 89); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);">客户端随机数 A + 服务端随机数 B + 客户端 Pre-master Secret C → 会话密钥</pre>

实际这个 Pre-master Secret 的生成方法不是固定的，而会根据加密的具体算法不同而不同：

上述我介绍的是传统 RSA 方式，即 Pre-master Secret 由客户端独立生成，加密后再通过 Client Key Exchange 发回服务端。
还有一种是 ECDHE 方式，这种方式下无论在客户端还是服务端，Pre-master Secret 需要通过 Client Key Exchange 和 Server Key Exchange 两者承载的参数联合生成。

Step 4: Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message

接着客户端告诉服务端：

Client Key Exchange，本质上它就是上面说的这个 C，但使用了服务端通过证书发来的公钥加密；
Change Cipher Spec，客户端同意正式启用约好的加密方法和密钥了，后面的数据传输全部都使用密钥 X 来加密；
Encrypted Handshake Message，快速验证：这是客户端对于整个对话进行摘要并加密得到的串，如果经过服务端解密，和原串相等，就证明整个握手过程是成功的。

服务端收到消息后，用自己私钥解密上面的 Client Key Exchange，得到了 C，这样它和客户端一样，也得到了 A、B 和 C，继而到 X，以及最终的会话密钥。

TLS 是通过非对称加密技术来保证握手过程中的可靠性（公钥加密，私钥解密），再通过对称加密技术来保证数据传输过程中的可靠性的。

Step 5: Change Cipher Spec, Encrypted Handshake Message

服务端最后也告知客户端:

Change Cipher Spec，服务端也同意要正式启用约好的加密方法和密钥，后面的数据传输全部都使用 X 来加密。
Encrypted Handshake Message，快速验证：这是服务端对于整个对话进行摘要并加密得到的串，如果经过客户端解密，和原串相等，就证明整个握手过程是成功的。

选修课堂：证书有效验证的原理

证书发布机构对证书做摘要生成指纹，并使用它自己的私钥为该指纹加密，生成数字签名（Digital Signature），而这个数字签名也随证书一起发布。这个发布机构的私钥是它内部自己管理的，不会外泄。

验证过程则正好是发布过程的反向，即在客户端要对这个被检测证书做两件事：

对它 (证书中携带的网站的公钥) 用指定算法进行摘要，得到指纹 P1；
使用证书发布机构的公钥对它的数字签名进行解密，得到指纹 P2。

如果 P1 和 P2 一致，就说明证书未被篡改过，也说明这个服务端发来的证书是真实有效的，而不是仿冒的。

CA 是分级管理的，每一级 CA 都根据上述同样的原理，由它的上一级 CA 来加密证书和生成数字签名，来保证其真实性，从而形成一个单向的信任链。同时，标志着最高级别 CA 的根证书数量非常少，且一般在浏览器或操作系统安装的时候就被预置在里面了，因此它们是被我们完全信任的，这就使得真实性的鉴别递归有了最终出口。也就是说，递归自下而上验证的过程，如果一直正确，直至抵达了顶端——浏览器内置的根证书，就说明服务端送过来的证书是安全有效的。

扩展阅读

HOW HTTPS WORKS：漫画版介绍 HTTPS 前前后后，很有趣。
The First Few Milliseconds of an HTTPS Connection：如果你想深究你抓到的 TLS 连接建立的包中每一段报文的意思，这篇文章是一个很好的参考。
文中介绍了两种生成 Pre-master Secret 的方法，其中第二种的方法是 Diffie–Hellman 密钥交换的变种，这里蕴含的数学原理很有意思，如果你感兴趣，请参阅维基百科链接

公众号：码农架构.png