「HTTPS」-- 你所必须了解的东西

随着互联网的快速发展，安全性的问题越来越重要，加之人类是“贪婪”的，远远不满足对于 HTTP 的安全性，于是有了 HTTPS。而 HTTPS 在安全性上是怎样远远胜于 HTTP 的呢？

HTTP 存在的问题

• 数据没有加密：HTTP 的传递是明文，不会加密这些信息，只要攻击者能够获取到这些明文，用户的隐私就完全暴露了。解决的方法就是信息加密。

• 无法验证身份：在 HTTP 应用中，客户端和服务端并不能确认对方的身份，因为在 HTTP 标准中，没有校验对端身份的标准。解决的方法就是用证书来验证对方的身份。

• 数据容易被篡改：HTTP 数据在传输过程中，会经过很多节点，这些节点都可以修改原始数据，而对于客户端和服务端来说，没有任何技术来确保接受的数据就是发送者发送的原始数据。解决方法就是利用一些算法来检验数据。

HTTP 存在的这些问题，导致了很大的安全性问题。所以便有了 HTTPS 的诞生。

HTTPS

HTTPS 并不是一个新的协议，本质上还是 HTTP，只是 HTTPS 在 HTTP 的基础上 增加了一些网络安全的东西。HTTPS 是建立在安全 socket 层次上的超文本传输协议，可以认为 HTTPS = HTTP + SSL/TLS

SSL/TLS 是安全协议。SSL(Secure Sockets Layer)：安全套接字层协议；TLS(Transport Layer Security)：安全传输层协议。TLS 是 从 SSL 发展而来的，SSL 是最早期的安全层协议，后来发现了一些漏洞后，便有了 TLS。现阶段使用最多的版本是 TLS1.2、TLS1.3版本。

在讲浏览器使用 HTTPS 传输数据的流程之前，我们先来了解几个知识。

加密算法

在上面说 HTTP 存在「数据没有加密」这个问题的时候说到，要解决的方法就是信息加密。然而加密算法也有很多种。

1、对称算法

对称算法顾名思义，就是加密和解密数据时，使用相同的密钥。

优点：就是效率很高，可以对长数据进行加密。

缺点：最大的问题就是，通信双方难以确保拿到安全的密钥。因为第一步总是需要通过通信来协商密钥的，那么在这个协商的过程，也有可能被黑客监听、篡改。如果使用一个固定的密钥，那这个算法也失去了意义。

2、非对称算法

与对称算法不一样的是，非对称算法使用的是不用的密钥。

• 非对称算法有两把密钥：公钥与私钥。
• 公钥是公开给所有人的，私钥是自己保密的，不能给别人知道。
• 使用公钥加密，只有私钥才能解开。同样，使用私钥加密，只有公钥才能解开

优点：完美解决了对称算法存在“无法安全交换密钥”的问题

缺点：性能很差，效率远远不及对称算法。

3、对称 + 非对称算法

对称算法的效率高，但是无法安全交换密钥；而非对称算法可以安全交换密钥，但是效率非常低。所以我们可以：第一次通信协商的时候使用非对称算法来交换密钥，后面就使用对称算法来继续通话，那这样是不是取其优点整合呢？如下图所示：

• 1、客户端发起请求的时候，服务端首先明文返回一个公钥给客户端
• 2、客户端拿到了服务端的公钥后，利用服务端的公钥来加密客户端自己的密钥，然后发给服务端。
• 3、服务端拿到了客户端用自己公钥加密的数据后，用私钥进行解密，拿到了客户端的密钥
• 4、服务端用刚刚拿到的客户端密钥进行加密自己的密钥，然后发给客户端。
• 5、客户端拿到来服务端的密钥

这就是对称算法 + 非对称算法的通信过程。

数字证书

在上面说 HTTP 存在「无法验证对方身份」这个问题的时候说到，要解决的方法就是用证书来验证。那么什么是证书呢？ 又是如何利用证书来验证身份的呢？

1、什么是数字证书？

数字证书是指在互联网通讯中标志通讯各方身份信息的一个数字认证，人们可以在网上用它来识别对方的身份，是由电子商务认证中心（简称CA中心）所颁发的一种较为权威与公正的证书。

数字证书好比我们的身份证，用来验证信息的一个认证

数字证书里面包括服务器信息：公钥、证书签名、证书机构信息等等。客户端拿到服务端的证书，进行证书验证后，可以准备拿到服务器的公钥，利用这个公钥，就可以实现 对称 + 非对称算法加密了。

数字证书的作用就是：验证数据来源，安全获取服务器的公钥进行加密通信。

2、证书的生成

数字证书是由认证中心（CA）或者认证中心的下级认证中心颁发的。根证书是认证中心与用户建立信任关系的基础。在用户使用数字证书之前必须先下载和安装。

证书的产生：认证中心把用户证书的基本信息做哈希算法，然后用自己的私钥对哈希值进行加密。如下图所示：

• 服务端产生了自己的密钥对，并将公共密钥及部分服务器身份信息传送给一家认证中心（CA机构认证）。
• 证书机构对服务器的信息使用 hash 算法得出一份128位的摘要，并对这份摘要使用自己的私钥进行非对称加密得到证书数字签名。
• 证书机构把服务器信息（明文）+数字签名+证书机构信息（包含证书机构公钥）发送给服务器
• 客户端请求服务器时，服务器把证书返回给客户端。

3、证书的分发

CA 将证书分发给用户的途径有多种。

• 带外分发(Out-of-band Distribution)，即离线方式。例如，密钥对是由软件运营商代替客户生成，证书也是由运营商代替客户从 CA 下载，然后把私钥和下载的证书一起储存在软盘里，再交给用户的。这样做的好处是免去了用户上网下载证书的麻烦。
• 带内分发(In-band distribution)，即用户从网上下载数字证书到自己的电脑中。下载时，用户要向CA出示“参考号”和“授权码”，以向CA证明自己的身份。这样做成本较低。
• 查询公共数据库。CA 还把证书集中放置在公共的数据库中公布，用户可以随用随查询随调用。

4、如何验证数字证书？？？

举个例子：

A 同学验证 B 同学的证书

• A 同学拿到了 B 同学的证书（B 同学的证书、CA 签发 B 同学的证书、证书机构信息）
• A 同学用 CA 的公钥解密对 CA 签发 B 同学的证书进行解密，得到一份摘要 S1
• A 同学对 B 同学的信息用 hash 算法得到一份摘要S2
• 对比S1、S2，看看信息是否被篡改过
• 校验 B 同学证书的有效期、证书作废列表（CRL,OCSP）以及签发者签名（证书链）

5、证书链

刚刚在验证数字证书的时候，我们提到了证书链，那么什么是证书链呢？ 证书链又有什么作用呢？

回忆一下刚刚数字签名的生成与验证过程：CA 利用自己的私钥加密生产证书，然后用户用 CA 公钥去解密验证。过程中是拿不到 CA 的密钥的。如果中途被劫持了（黑客使用自己的私钥加密，同时把证书机构的公钥修改成自己的公钥），我们怎么得知呢？ 这时候就需要证书链了！！

随便打开一个 HTTPS 的网站，在地址栏的左侧有一个小锁，点开可以看到里面的证书信息。

可以看到证书的层次是 GlobalSign Root CA --> GlobalSign Organization Validation CA --> baidu.com

• end-user：即 baidu.com，该证书包含百度的公钥，访问者就是使用该公钥将数据加密后再传输给百度，即在 HTTPS 中使用的证书
• intermediates：即上文提到的 签发人 Issuer，用来认证公钥持有者身份的证书，负责确认 HTTPS 使用的 end-user 证书确实是来源于百度。这类 intermediates 证书可以有很多级，也就是说 签发人 Issuer 可能会有很多级
• root：可以理解为 最高级别的签发人 Issuer，负责认证 intermediates 身份的合法性

这其实代表了一个信任链条，最终的目的就是为了保证 end-user 证书是可信的，该证书的公钥也就是可信的。证书链如下图所示：

前面说了证书的验证过程，那么证书链又是怎么个验证流程呢？

• 获取 end-user 的公钥，需要获取 end-user 的证书，因为公钥就保存在该证书中
• 为了证明获取到的 end-user 证书是可信的，就要看该证书是否被 intermediate 权威机构认证，等价于是否有权威机构的数字签名
• 有了权威机构的数字签名，而权威机构就是可信的吗？需要继续往上验证，即查看是否存在上一级权威认证机构的数字签名
• 信任链条的最终是Root CA，他采用自签名，对他的签名只能无条件的信任

以上就是关于证书链的基本知识了，这里有一篇外文是关于证书链的，有兴趣的可以观看一下 点一点

6、散列算法

散列算法，也称之为摘要算法或哈希算法，可以将任一数据对象压缩成数据摘要，对于同一散列算法，压缩后的数据摘要具有特定的长度和格式，以此形成数据的"指纹"。原始数据对象的任一细小的改动，都可能使得新的"数字指纹"有着很大不同。

往往通过散列算法，可以判断两个数据对象是否相同，因为相同的数据对象，通过散列算法形成的"数字指纹"必定是相同的，但是相同的"数字指纹"，对应的原始数据对象不一定是相同，因为可能存在散列冲突问题。在现实中就有广泛的使用场景，例如最常用的对两个文件对象进行MD5，判断其内容是否相同。

散列算法与加密算法区别：

• 加密算法：对应的是可以解密的，目的是进行数据加密后的安全存储或传输，是可以通过密钥得到原文的，是可逆的过程。
• 散列算法：本质上"数字指纹"的范畴，通过散列算法形成的"数字签名"，直接在算法层面是不能得到原文的，是不可逆的。当然，通过彩虹表和数据字典这种形式的所谓解密，本质上只是暴力破解的过程。

HTTPS 连接过程

有了上面的知识了解后，我们来看看 HTTPS 连接的过程。

由上图的可知流程：

• 1、首先客户端（client）发起请求，并带上本地的 TLS 版本，客户端支持的加密算法套件，并生成一个客户端的随机数 R1 也一同发送过去
• 2、服务端（server）收到请求后，确认了 TLS 版本，并从客户端支持的算法套件中选择一个，并生成一个服务端的随机数 R2，然后返回给客户端选择的加密套件，随机数 R2，还有 CA 证书（包括公钥）以及证书签名。
• 3、客户端（client）收到了服务端的证书后，验证证书的合法性（具体可以往上看如何验证证书的合法性）。利用两个随机数R1、R2，生成pre-master secret，并使用服务器的公钥加密发送给服务器。并且客户端生成会话密钥和p1-p6
• 4、服务端（server）利用私钥解密得到pre-master secret。并生成会话密钥和p1-p6
• 5、客户端（client）利用第三步生成的 p1 对握手信息的 hash 加密生成 Encrypted handshake message，然后发送给服务端，并发送FIN报文，表示结束。
• 6、服务端（server）利用第四步生成的 p1 验证客户端的 Encrypted handshake message。
• 7、验证通过后，利用 p2 对握手信息的 hash 加密生成 Encrypted handshake message，然后发送给服务端，并发送FIN报文，表示结束。
• 8、客户端（client）利用 p2 验证完服务端的 Encrypted handshake message后，HTTPS 的连接流程结束

至此、双方可以安全进行通信了。

疑惑点：

1、客户端的随机数 R1、服务端的随机数 R2 的作用是什么？
答：双方通过交互各自的随机数后，双方都拥有了 R1、R2。客户端（client）利用 R1、R2 生成一个 pre-master secret，然后利用这三个数，生成会话密钥。
同样的服务端（server）也是利用这三个数生成会话密钥。

2、p1-p6 的作用是什么？
答：6个密钥 p1-p6 是用作后续的身份认证

3、Encrypted handshake message 是什么？ 有什么用？
答：Encrypted handshake message 把当前自己收到的数据和发送的数据进行一次简单运算（hash+加密）。

这个报文的目的就是告诉对端自己在整个握手过程中收到了什么数据，发送了什么数据。来保证中间没人篡改报文。
其次，这个报文作用就是确认秘钥的正确性。因为Encrypted handshake message是使用对称秘钥进行加密的第一个报文，如果这个报文加解密校验成功，那么就说明对称秘钥是正确的。

Charles 抓取 HTTPS 原理

做个小拓展，说一下 Charles 抓包工具抓 HTTPS 的原理

Charles 相当于一个中间人，对于客户端（client）来说，服务端是 Charles。而对于服务端（server）来说，客户端是 Charles。如下图所示：

简单来说，就是 Charles 作为“中间人代理”，拿到了 服务器证书公钥 和 HTTPS 连接的对称密钥，前提是客户端选择信任并安装 Charles 的 CA 证书，否则客户端就会“报警”并中止连接。这样看来，HTTPS 还是很安全的。

参考连接

HTTPS流程详解

浅谈Charles抓取HTTPS原理

TLS/SSL 协议详解 (19) Encrypted handshake message