【Web基础】HTTPS详解

目录

一. HTTPS是什么

二. 加密是什么

加密算法

三. HTTPS的工作过程

引入对称加密

引入非对称加密

为什么不只使用非对称加密传输数据？

中间人攻击

引入证书

证书是什么？

引入证书后的工作流程

常见问题

1. 黑客能否修改证书中的公钥？

2. 黑客能否把数据签名一起修改了？

3. 黑客能否针对公证机构的pub3进行中间人攻击？

4. 补充：安装Fiddler时，为什么要安装证书

5. SSL/TLS协议是在什么时候生效的

6. 为什么摘要内容在网络传输的时候一定要加密形成签名?

7. 为什么签名不直接加密，而是要先hash形成摘要？

完整流程

四. 总结

一. HTTPS是什么

HTTPS是一个应用层协议，是在HTTP协议的基础上，引入了一个加密层（名字叫SSL / TLS）.

关于SSL/TLS，这其实是同一个东西，只不过以前旧版本名字叫SSL，升级后新版叫TLS

这个加密层可以视作一个单独的协议，至于其是如何加密的，就是我们下面要探讨的内容。

由于HTTP协议内容本身都是按照文本的方式进行明文传输的，这就导致在传输过程中，可能会出现一些内容被篡改的情况。

比如臭名昭著的运营商劫持问题，简单来说就是，你点击下载网易云音乐的按钮，页面上会给你弹出一个下载链接，以及下载位置等，在没有被劫持的情况下，这些内容都是网易这个公司来提供的正确的内容，而这个过程如果被运营商劫持了，在下载链接位置，就可能会变成其他内容的下载链接，比如QQ浏览器等。

由于我们通过网络传输的任何数据都会经过运营商的网络设备（路由器，交换机等），那么运营商的网络设备就可以解析出你传输的数据内容，从而进行篡改。

点击"下载按钮"，其实本质上就是在给服务器发送一个HTTP请求，获取到的HTTP响应其实就包含了该APP的下载链接。在被运营商劫持之后，发现这个请求是要下载网易云音乐，那么就自动的把交给用户的响应给篡改成"QQ浏览器"的下载地址了。

运营商劫持其实还不是最关键的，更关键的是黑客也可以用类似的手段来进行劫持，窃取用户隐私信息，或者篡改内容。
试想一下，如果黑客在用户登录支付宝的时候就能够获取到用户的账户余额，甚至支付密码...

所以在互联网上，明文传输是比较危险的事情。
HTTPS就是在HTTP的基础上进行了加密，进一步来保证用户的信息安全。

二. 加密是什么

前面说了，要保证数据安全，就需要进行"加密"，安全与否防的是黑客。
加密后网络传输的数据不再是明文，而是密文，此时就提高了数据的安全性。

加密就是把明文(要传输的信息) 进行一系列变换，生成密文.
解密就是把密文再进行一系列变换，还原剩明文.

在这个加密和解密的过程中, 往往需要一个或者多个中间的数据, 辅助进行这个过程, 这样的数据称为密钥(正确发音 yue 四声, 不过大家平时都读作 yao 四声) .

而加密解密在如今已经发展成一个独立的学科：密码学.
而密码学的奠基人, 也正是计算机科学的祖师爷之一, 艾伦·麦席森·图灵
不过这里我们不过多展开。

加密算法

加密算法有多种分类的方式：
按照类型，可以分为：可逆加密算法 / 不可逆加密算法可逆：密文 -> 明文 不可逆：密文 ≠> 明文
按照用途，可以分为：对称加密算法 / 非对称加密算法 / 摘要算法
其中，对称加密和非对称加密算法都是可逆的，摘要算法是不可逆的

对称加密：

一个密钥key，既可以加密，又可以解密
特点：速度快，效率高，适合传输大量数据，但不安全。
非对称加密：

两个密钥，key1,key2
若用key1加密，就必须用key2解密
若用key2加密，就必须用key1解密
通常用法是把其中一个公开出去，称为"公钥"，另一个自己保存好，称为"私钥"
这里的一对公钥和私钥，有一定关联关系，底层有数学理论支撑。
特点：速度慢，不适合传输大量数据。用于比较安全的交换对称密钥和后续的数字签名。

摘要算法：
像数据的指纹，能够将任意数据转换为固定长度的"摘要"，且不可逆(无法从摘要还原出原文)，主要用于校验数据是否被篡改(如CRC循环冗余校验)

至于加密解密的具体细节/算法，属于"数学问题"，计算机圈子中都有很多现成的库，供我们直接使用。我们这里主要说HTTPS加密的流程，是如何来使用的。

三. HTTPS的工作过程

引入对称加密

对称加密：一个密钥，既可加密，又可解密

思路：客户端 / 服务器生成一个密钥，让对方也持有这个密钥

客户端发送给服务器的数据，就用这个密钥来加密，服务器就使用这个密钥来解密。

上述过程过于理想，实际存在许多问题：

一个服务器，是要给很多客户端提供服务的，这么多客户端，是使用同一个密钥，还是不同的密钥？ 当然绝对不能是同一个，如果是同一个，黑客自己整个请求发过去就完事了。

所以可以让客户端生成一个随机的对称密钥，把对称密钥通过网络传输给服务器？
那么怎么传呢？这一传就会出问题。

所以上面我们用对称加密，问题是什么？

首先，一个服务器要给很多客户端提供服务，那么此时每个客户端使用的密钥就必须是不同的（如果相同，黑客随时能拿到）

既然每个客户端都使用不同密钥，那就意味着再通信前，都要先把密钥通过网络传输给对方（无论是客户端传给服务器还是反过来，都会有这么一个密钥传输的过程）
这样的密钥传输过程，如果"密钥是明文传输"，就可以被黑客截获！

如何对密钥安全传输？自然还是加密！
再搞对称密钥222，用222进行加密？这样还得传明文222，还是会被黑客拿到。

所以仅仅引入对称加密，不足以解决安全问题。

引入非对称加密

非对称加密：两个密钥，一个用来加密，就必须用另一个来解密

思路：服务器生成一对公钥和私钥，私钥只有服务器自己知道，公钥直接公开出去，任何人都能拿到。 服务器生成的公钥和私钥对，每次也是不同的。
客户端决定对称密钥是什么，通过公钥进行加密。后续数据再用对称密钥进行传输。

此时黑客即使拿到数据，也无法进行解密，因为他手里只有公钥，没有私钥
公钥是一把锁头，私钥是对应的钥匙
此时就保证了数据传输的安全性。

为什么不只使用非对称加密传输数据？

因为对称加密效率比较高，占用的系统资源少.
非对称加密效率比较低，占用的系统资源多.

我们只使用非对称加密，传输对称密钥，规避非对称加密开销大的问题.
使用对称加密加密数据. 由于对称密钥已经安全的到达对方了，对称加密此时也是一样安全的。

由于对称加密效率比非对称加密高得多，所以只是在开始阶段协商对称密钥时，采用非对称加密，后续传输仍然使用对称加密。

PS：黑客能否黑入服务器，拿到私钥？ - 理论上当然可以，但凡事讲究成本。
没有绝对的安全，尤其是大公司的服务器，都会有专业的安全团队，做安全相关的措施。

至此，引入非对称加密后，数据看起来就安全多了
但是，黑客真的就无法获取到我们的数据了吗？

中间人攻击

思路：由于生成公钥 / 私钥的算法都是开源的，所以黑客自己也可以生成一个公钥 / 私钥对。
对客户端，黑客把自己的设备伪装成服务器。
对服务器，黑客把自己的设备伪裝成客户端。
具体中间人攻击过程如下：

整个中间人攻击过程梳理：

客户端经过黑客向服务器索要公钥

服务器给客户端公钥，中间的这个公钥是通过明文传输的，没有被加密

黑客自己也去生成一个公钥/私钥对，把上面服务器给客户端的这个公钥给截获到，替换为自己生成的，交给客户端.此时相当于黑客伪装成服务器，与客户端进行交互

客户端生成对称密钥，使用黑客给的公钥进行加密，发送给服务器

黑客截获到这个数据后，由于黑客持有对应的私钥，进行解密出对称密钥，然后再拿着服务器给的公钥，对对称密钥再进行加密，给服务器.此时相当于黑客伪装成客户端，与服务器进行交互

最后的结果就是客户端与服务器的对称密钥也被黑客获取到了，数据完全泄露。

这就是中间人攻击

所以，即使在引入对称加密和非对称加密的情况下，也会在黑客的中间人攻击的情况下，丧失数据安全性。

引入证书

要想应对中间人攻击，首先要找到问题出在哪
在中间人攻击的流程中，最关键的问题在于，客户端并不知道对方是黑客伪造的，还是真实的服务器。
所以我们要有手段，让客户端识别出真伪，能够识别出这个公钥就是服务器提供的真实的公钥，而不是黑客伪造的。

此时就需要引入证书
服务器在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性

证书是什么？

证书是一个结构化字符串，是第三方机构给服务器颁发的，证明服务器身份的一个东西。
结构化字符串：即字符串里面包含了许多属性，类似于一个结构体，只不过变成了字符串的方式。

服务器需要把自己的域名和公钥，向公证机构（CA）提交资质（申请数字证书），然后公证机构验证通过后，给服务器颁发证书。（确保你访问的是真实合法的服务器，而不是钓鱼网站等）

这个证书（结构化字符串）中，包含明文信息和签名信息两大部分。

被签名的明文信息（待签证书）：

主体信息：证书持有者的身份（比如域名，公司名称等）

公钥：持有者的非对称加密公钥（服务器的公钥）

颁发者：签发这张证书的 CA 机构名称

有效期：证书的起始和结束时间

序列号：该 CA 颁发的唯一编号，用于吊销列表查询。

签名算法标识：告诉你 CA 使用了哪种算法来签名。（如sha256RSA）

签名信息：

本质是"加密后的校验和"，它是 CA 用自己生成的非对称加密私钥生成的最终密文，附在证书末尾.

证书中，最重要的就是这个签名信息，这部分确保了证书不可伪造

证书中的签名信息，正是根据上面提到的"被签名的明文信息"来计算出来的

CA将所有上述信息，按固定格式排列，使用摘要算法（不可逆算法）中的哈希算法（如SHA-256）计算出一个固定长度的"数字摘要"，生成校验和。
然后对这个校验和使用CA自己的非对称加密私钥来加密。

引入证书后的工作流程

客户端拿到证书后，就可以对证书的真实性进行验证！

客户端校验证书真实性：

上面证书部分说了，除了签名外，其余部分都是证书上的明文部分。
1. 客户端使用证书中标记的哈希算法，计算校验和check1
2. 客户端拿着公证机构的公钥，对签名进行解密，得到校验和check2
3. 对比check1和check2的值，如果校验和相等，说明证书真实有效。否则说明证书是假的。
此处校验和相等说明两点：1. 证书正文内容，在传输中没有被篡改。 2. 该证书确实是由持有该私钥的 CA 签发的，因为只有CA的私钥，才能加密出能被CA公钥正确解密的签名。
此时浏览器会直接弹一个红色页面，提示你访问的网站存在安全风险！此时用户停止访问，就可以避免数据发生泄漏了。

由于证书中的明文信息部分，包含的有服务器的公钥，所以后续就是，客户端生成对称密钥，使用服务器公钥进行加密，由于只有服务器拥有对应的私钥，所以只有服务器能成功解密获得私钥。
后续所有的数据传输信息，都使用对称密钥来加密传输。

常见问题

1. 黑客能否修改证书中的公钥？

当然是不能！

假设黑客把证书中服务器的公钥pub1换成了自己的pub2

客户端校验证书真实性时，从证书中解密出来的校验和也是用原始的pub1计算出来的，而不是黑客的pub2，此时就会导致客户端自己计算出的校验和和解密出的校验和不同。

2. 黑客能否把数据签名一起修改了？

还是不行！

因为证书中的数字签名需要使用公证机构自己的非对称加密私钥 pri3来进行加密，黑客最多算校验和，绝对无法生成数字签名（除非黑客把公证机构黑了）

3. 黑客能否针对公证机构的pub3进行中间人攻击？

更不可能！

因为公证机构的pub3就不是通过网络传输的。

而是用户的操作系统内置的。

全世界的公证机构，也没有很多。主流的操作系统中都内置了主流公证机构的公钥
（如果你使用的是盗版系统，提前内置好黑客的公钥... 此时黑客是可以伪造整个数字签名的...）

所以引入证书的方式是能彻底实现数据安全的。
黑客既不能篡改公钥（改变校验和，客户端认证失败）
也无法伪造数字签名（黑客无CA公钥，无法生成有效签名，客户端解密失败/校验和不匹配）
更无法冒充CA机构（客户端只信任预置根证书，黑客伪造的CA证书不在信任列表，仍然导致校验和不匹配）

4. 补充：安装Fiddler时，为什么要安装证书

fiddler 抓取 HTTPS 的时候，其实就是在进行中间人攻击！
如果你想用fiddler抓HTTPS，需要先信任fiddler的证书（勾选的那几个选项），此时其实就相当于信任了fiddler的公钥。
我们信任了fiddler的证书，此时fiddler就相当于一个公证机构。

fiddler拦截服务器返回的真实证书后，替换其中服务器公钥为fiddler自己的公钥，并基于fiddler根证书重新生成数字签名，形成伪造证书
篡改后的证书，域名等信息与真实证书一致，公钥替换为fiddler公钥，数字签名由fiddler根证书私钥生成（非原始CA签名）

由于客户端已经信任fiddler根证书，所以会认为伪造的证书是合法的.（验证签名时，使用fiddler公钥解密成功）

5. SSL/TLS协议是在什么时候生效的

前提：最开头部分已经提到，HTTPS是在HTTP的基础上，引入了加密层，加密层的名字叫SSL/TLS。上面我们所说的内容，就是这个加密层做的工作（如何加密的）

1. SSL/TLS是在哪里生效的？

SSL/TLS协议是在传输层与应用层之间建立的加密通道。

并不是在传输层，可以理解为传输层（TCP/UDP），应用层（HTTPS），这两层中间，还有独立的安全层，SSL/TLS就作用在这里。（一般来说，在TCP/IP四层模型中，SSL/TLS被归为应用层（作为HTTP的扩展），在OSI七层模型中，被归为会话层/表示层（安全抽象层））

HTTP ——> TLS/SSL ——> TCP

6. 为什么摘要内容在网络传输的时候一定要加密形成签名?

常见的摘要算法有: MD5 和 SHA 系列
以 MD5 为例, 我们不需要研究具体的计算签名的过程, 只需要了解 MD5 的特点:
• 定长: 无论多长的字符串, 计算出来的 MD5 值都是固定长度 (16字节版本或者32字节版本)
• 分散: 源字符串只要改变一点点, 最终得到的 MD5 值都会差别很大.
• 不可逆: 通过源字符串生成 MD5 很容易, 但是通过 MD5 还原成原串理论上是不可能的.
正因为 MD5 有这样的特性, 我们可以认为如果两个字符串的 MD5 值相同, 则认为这两个字符串相同.

理解判定证书篡改的过程：（类似于判定一个身份证是不是伪造的）

假设我们的证书只是一个简单的字符串test，对这个字符串计算hash值（假设用md5），结果为098F6BCD4621D373CADE4E832627B4F6

若test中有任何一个字符被篡改了，比如teat，此时计算出的md5值就会变化很大：55CAEB5DE0B558FB7836F5346D35D67E

然后我们可以把这个字符串 test 和 哈希值 098F6BCD4621D373CADE4E832627B4F6从服务器返回给客户端, 此时客户端如何验证 test 是否是被篡改过?

那么就只要计算 test 的哈希值, 看看是不是 098F6BCD4621D373CADE4E832627B4F6即可.

这里就涉及一个问题，如果黑客把test篡改了，并且把哈希值也重新计算，此时客户端就无从分辨了。(连着字符串和哈希值一起改)

所以被传输的哈希值不能是明文，必须是密文。

所以，对于证书明文形成的哈希值，CA要用自己的私钥来进行加密，将test和加密后的签名合起来形成CA证书，此时黑客就无法进行更改或整体掉包，就能安全的证明证书的合法性。

最后，客户端通过操作系统里已经存的了的证书发布机构的公钥进行解密, 还原出原始的哈希值, 再进行校验.

7. 为什么签名不直接加密，而是要先hash形成摘要？

缩小签名密文的长度,加快数字签名的验证签名的运算速度

完整流程

四. 总结

关于HTTPS的加密，同时涉及对称加密和非对称加密，同时还引入了数字证书来防伪.

HTTPS的工作过程中，涉及到的密钥有三组.

第一组（非对称加密）:用于校验证书是否被篡改. 服务器持有私钥(私钥在注册证书时获得), 客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器使用这个私钥对证书的签名进行加密. 客户端通过这个公钥解密获取到证书的签名, 从而校验证书内容是否是篡改过.

第二组(非对称加密): 用于协商生成对称加密的密钥. 服务器生成这组 私钥-公钥 对, 然后通过证书把公钥传递给客户端. 然后客户端用这个公钥给生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.

第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密.

其实一切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥工作的.
第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器.
第一组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥