漫画 HTTPS（多图说透过程和原理）— 密码学集大成者

到今天为止，这个专栏已经介绍了密码学中的对称加密、非对称加密、Diffie-hellman密钥交换、签名、证书。今天来讲一讲集这些知识为一身的 HTTPS。

先来看看 HTTP

HTTP 是计算机网络中的一种应用层协议。传统 HTTP 协议基于 TCP 传输层协议，构建可靠性传输。关于计算机网络的基本知识，可以参考我的文章《图文轻松理解计算机网络五层架构》，这里不做过多的描述。

TCP 协议为了构建可靠的传输，建立连接的时候会进行 3 次握手，这是因为通信双方建立连接都需要对方的确认（确保可靠），而 3 次是通信双方都要确认的最少次数（ Server 端在第 2 次握手中既确认 Client 的连接请求又发起连接）。为什么断开连接的时候需要 4 次挥手呢？因为 Client 发出断开连接的消息后（第1次），Server 由于可能传输未完成，无法马上断开连接，因此只能先回复确认（第2次）。待自己传输完成后，再发出断开连接的消息（第3次），Client收到后答复确认（第4次）。

HTTPS 在加密传输信息前需要 4 次握手。4 次握手在做交换秘钥、身份验证等工作，建立在3次握手建立连接的基础之上。

HTTPS 中的 “S”

HTTP 协议传输的文本是明文。这意味着在网络中传输的任何信息都在裸奔，包括登录时输入的用户名和密码。一旦有攻击者截获通信内容，后果不堪设想。要解决这个问题，需要综合运用之前我们讲过的密码学知识，我们来捋捋需要哪些知识。

对称加密

既然明文传输不安全， 那么很自然会想到对传输的信息加密。我们还知道非对称加密效率很低，并不适合做大量信息的加密。因此使用对称加密是一个合理的选择。关于对称加密，可以参考《加密就像玩魔方----图文详解对称加密》

非对称加密、Diffie-Hellman、椭圆曲线 Diffie-Hellman（ECDH）

对称加密面临密钥传递安全性问题，具体请参考《图文结合彻底理解非对称加密》。解决办法主要有两种，一种是使用非对称加密，对密钥加密后传递，还有一种是使用 Diffie-Hellman密钥交换。

签名、证书

加密能够确保信息在传输过程中的安全性，但无法验证通信方的身份。如果攻击者伪装成服务端和客户端通信，那么会骗取客户端所有信息。解决这个问题需要使用证书。证书又会使用到签名，用来验证证书的真伪。签名又会涉及到非对称加密。关于证书可以参考《证书-解决非对称加密的公钥信任问题》

SSL/TLS

综合上面说到的这些密码学工具，产生了SSL/TLS 协议。其实两者是一个协议，SSL 3.0 以后名称变为了 TLS 1.0。HTTPS 中的 “S” 指的就是 SSL/TLS。为了描述方便，后面我用 TLS 指代 SSL/TLS。TLS 是网络上对传输数据进行加密的协议，全称为 Transport Layer Security。可以认为 HTTPS 是在 HTTP 和 TCP 协议间增加了一层加密协议TLS。

TLS 工作流程

TLS 涉及到以下主要的工作流程

1. 沟通使用的加密套件
2. 服务端给客户端发送证书
3. 客户端验证服务端发过来的证书
4. 客户端和服务端安全传递对称加密的密钥（RSA 或者 Diffie-Hellman）
5. 尝试发送加密的信息验证加解密是否正常
6. 开始传输信息。

前4步是未加密通信。由于加密的算法众多，在对称加密通信前，双方需要先沟通加密算法、计算密钥。第4步后，通信双方均有了密钥，后续的通信将会采用对称加密。

详解 TLS 流程（握手协议）

上面讲解了 TLS 的大致流程，下面我们来详细讲解 TLS 构建加密通信的流程细节，也就是 TLS 协议中的握手协议。HTTPS 中的 4 次握手，便是对握手协议的实现。目的是达成安全的密钥交换。

4 次握手其实要干的事情远远不止 4 种，只不过出于效率考虑，将不同类型的信息放在 4 次通信中完成。我们可以忘记 4 次握手，只需要关心握手期间干了什么事情。

先来看握手流程图。

我们一步步来分析这个过程

（1）Client Hello（客户端）

客户端首先发起问候：哥们你好，我支持这些密码套件，你来选一种吧！对了，TLS协议版本太多，咱们也得商量一下，我把我支持的版本发给你。还有罐 “盐A”（随机数），生成密钥的时候记得撒上，你先拿好了。

由于不同的客户端支持的TLS版本、加密套件的种类不同，因此需要先进行沟通，客户端把自己支持的清单发给服务端。随机数是生成密码时的盐，提升强密钥度。

（2）Server Hello（服务端）

服务端回复：兄弟你好！咱们就使用xxx密码套件，TLS 1.2 版本吧。一罐盐不够安全，我也给你一罐 “盐B”，生成密钥的时候，记得都给撒上！

（3）Certification（服务端）

服务端：为了证明我就是我，把我的身份证（证书）发给你。你可以去帽子叔叔那里验证一下真伪。

服务器端为了证明自己的身份，会发送自己的证书，以及证书认证机构的证书链。

（4）Sever Key Exchange（服务端）

服务端：咱们不是得密钥交换吗？相关的信息我已经生成好了，发给你来用。

我们以 ECDH 为例，这一步服务器端会先生成基点G和PrivateKey，然后将基点 G 和 PublicKey（根据 G 和PrivateKey 生成）发送给客户端。

（5）Client Key Exchange（客户端）

客户端：我已经验证了你的身份证，没有问题。这是用你发给我的密钥交换信息生成的我的 PublicKey，你收好。

客户端在收到服务端的证书后，会对证书及证书链进行验证。然后用服务端发过来的生成密钥信息来生成自己的PublicKey 和 PrivateKey（以 ECDH 为例），并把 PublicKey 发给服务端。

此时，客户端和服务端可以根据自己的 ECDH 私钥和来自对方的公钥，计算出一样的 Pre Master Key。然后使用双方随机数 A、B、Pre Master Key 计算出 Master key，再根据 Master Key 计算如下密钥。

1. 对称加密密钥
2. 认证码密钥
3. CBC模式初始化向量

（6）Change Cipher Spec（客户端）

客户端：我已经计算好密钥了，咱们后面的通信开始采用对称加密！

（7）Finished（客户端）

客户端：握手结束！（此信息加密发送）

既然客户端已经通知客户端切换为对称加密方式通信，那么Finished信息需要加密发送。服务端收到Finished

信息后进行解密，和标准内容对比，验证加解密工作正常。

（8）Change Cipher Spec（服务端）

服务端：我也已经计算好了密钥，咱们后面的通信开始采用对称加密！

（9）Finished（服务端）

服务端：握手结束！（此信息加密发送）

至此，通信双方在安全的方式下完成了密钥交换。这里的安全指：

1. 客户端对服务端证书的验证（如有必要，服务端也会验证客户端证书）
2. 安全交换对称加密使用的密钥

后续的通信将会以对称加密的方式进行。

虽然我已经简化了交换密钥的过程，但需要交换的信息仍旧非常的多。TLS 通过合并可以合并的通信，通过 4 次握手实现了上述信息的交换。

一些问题

客户端和服务端生成随机数 A、B 的作用

客户端和服务端均提供随机数用于计算 Master Key，这是为了增加密钥的随机性，降低被破解的可能性。

在 ECDHE 中，双方都会计算各自的 Private Key，也就是说 Pre Master Key 的计算已经引入了双方的随机性。所以使得随机数 A、B 看起来不是十分重要。

但是考虑使用 RSA 方式传递密钥，客户端生成 Pre Master key 时，没有服务端的任何参与。随机数是伪随机数，攻击者可以通过攻破随机数计算方式来破解密钥。

使用 Pre Master Key 计算 Master Key 时，同时引入客户端和服务端的随机性，能够降低密钥被破解的可能性，不会被攻击者轻易摸到规律。并且能有效预防重放攻击。

RSA传递对称加密秘钥的方式已经被淘汰

在 TLS 1.2 及以前的版本中，存在加密套件使用 RSA 方式传递对称加密的密钥。客户端会使用服务端的公钥对自己生成的密钥进行加密，然后传递给服务端。

但在 TLS 1.2 以后的版本中，RSA 传递密钥的方式已经被淘汰，现在主流的方式是椭圆曲线 Diffie-Hellman 密钥交换（ECDHE）。

RSA 被淘汰的原因一是性能。ECDHE 以更少的密码位数达到相同的安全性。二是 RSA 不支持向前保密。RSA 的公钥和私钥在生成后，会在服务端长期保留，一旦私钥泄露，之前通信的信息也会被解密。而 ECDHE 由于每次密钥交换时用到的 G、PublicKey、PrivateKey 都会重新生成，所以即使泄露，之前加密过得信息也是安全的。

总结

HTTPS 协议在 HTTP 协议和 TCP 协议之间加入了一层加密协议 TLS。该协议用来在客户端和服务端间安全的交互密钥，支持加密传输。HTTPS 不会改变 HTTP 协议，也不会改变 TCP 协议。因此，HTTP 协议建立连接和断开连接的过程并不会产生变化。在 HTTP 3 次握手建立连接后，再通过4次握手交换秘钥、验证证书，实现加密通信。HTTPS 集密码学多种工具于一身，如果你能清楚的讲解 HTTPS，说明你已经掌握了密码学大部分知识点。

最后，附上一张HTTPS的全景知识点图，建议收藏。

最后插播广告！！！我编写的《漫画设计模式》已经出版上市，欢迎选购！购买链接点这里。