【计算机网络】HTTPS协议

---

1. HTTPS介绍

HTTP协议解决了超文本数据在网络中传输的问题，但同时又面临这另外一个问题——如何保证数据在传输过程中的安全？有了一定的网络基础我们知道，在网络中传输的数据要经过多个设备，如果不采取一定的安全措施，数据可以就会被篡改甚至盗用！HTTPS就是网络安全的“守护者”之一。

⭕ HTTPS（hypertext transfer protocol secure）也是一种应用层协议，它是在HTTP协议基础上，增加了一层用于为数据加密的软件层（SSL/TLS），目的是保证网络传输过程中数据的安全。 应用HTTPS协议的通信中，发送给对端的数据需先经加密再发出，而接收的数据需先经解密再进行处理。

---

2. 理解“加密”、“解密”、“密钥”

加密，是把要传输的数据（明文）经过一系列转换，生成密文。

解密，是把密文再经过一系列转换，变成明文。

加密解密过程中的“一系列转换”，往往需要一个或多个额外的数据加以辅助，这样的数据称之为密钥。 加密和解密的密钥可以相同，也可以不同。

加密解密过程中的“一系列转换”通常指某个特定的加密算法，加密算法是有限的，而“密钥”是无限的。相同的加密算法，以不同的密钥为辅，即可满足不同主机对数据加密解密的需求。

---

3. 常见的加密方式

PS: 加密算法包括加密和解密的功能

3.1 对称加密

1. 概念：对称加密采用单密钥的方式加密，即对数据的加密和解密用到的密钥数据是相同的。
2. 常见的对称加密算法：DES、3DES、AES、TDEA、Blowfish、RC2等。
3. 特点：算法公开，计算量较小，加密解密的速度快。

对称加密就是通过同一个加密算法，同一个密钥，即可加密明文和解密密文。最典型的对称加密算法就是“异或”。

假设：现有明文A，密钥K，加密算法为异或^，设明文A加密后的密文为B

加密：
$$A\oplus K=B$$
解密：
$$B\oplus K=A\oplus K\oplus K=A\oplus 0=A$$

3.2 非对称加密

1. 概念：非对称加密采用双密钥的方式加密。非对称加密要有一对密钥：私钥和公钥，一般来说，私钥是加密者私有的，公钥是公开的。二者都可以进行加密解密工作，但必须遵守如下规则
   • 私钥加密的数据，必须用公钥解密
   • 公钥加密的数据，必须用私钥解密
2. 常见的非对称加密算法：RSA，DSA，ECDSA
3. 特点： 算法强度复杂、安全性依赖于算法与密钥。但由于其算法复杂，使得加密解密速度比对称加密解密的速度慢得多。

理解非对称加密，可以举一个生活中的例子：

张三要给李四一个机密文件，但李四暂时无法收到。张三有一个盒子和一把锁，并提前给了一把钥匙在李四那边。此时张三就可以用锁把文件锁在盒子里，再送到李四家里。李四只要用提前拿到的钥匙就能打开。这里的“锁”就是公钥，“钥匙”就是私钥。“锁”不怕被别人拿到，因为它们没有钥匙打不开，只有李四手中的钥匙能解锁。

3.3 数据摘要

1. 概念：数据摘要，又称数据指纹，是通过某种单向哈希函数处理某段信息，生成的一串固定长度数据。
2. 摘要常见算法：有MD5、SHA1、SHA256、SHA512等，算法把⽆限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率⾮常低）
3. 特征：数据摘要并不属于加密方式，而是一种标识特定信息的方式。因为数据摘要具有强唯一性（所以又被称为数据指纹），能够用于区分信息是否被篡改。

使用MD5在线加密工具对本条目文本进行数据摘要。

3.4 数字签名

✒数字签名就是经过加密的数据摘要（数据指纹），通常与数字证书一起使用，后面详谈。

---

4. HTTPS加密方案探究

HTTPS协议引入数据加密解密的根本目的就是防止各种黑客和不法分子在传输过程中对数据的窃取，保证网络传输数据安全。那么HTTPS的加密方案究竟是如何设计的？是对称加密还是非对称加密？还是二者组合？我们可以一一分析方案的合理性。数据传输过程的三个角色：客户端、服务器和中间人，我们必须站在中间人的角度，判断在每种方案中，中间人是否能窃取到数据。

• “中间人”（Man-in-the-Middle，缩写为MITM）是指一个插入自己在通信双方之间的通信链路中，具有窃取、篡改或监视通信等行为的攻击者。

方案1： 只使用对称加密

图中以???代表密文。

看起来挺靠谱，客户端与服务器建立连接后，客户端生成对称密钥X后，发送X给服务器，往后二者的通信就使用对称密钥X加密解密即可。但这样做的缺点也很明显，在客户端向服务器发送对称密钥X的过程中，会遭到中间人攻击，如果密钥X被中间人窃取了，那么客户端和服务器往后通信的内容中间人都能看到。那么可不可以给对称密钥X也加密呢？不。这里就引发了“蛋生鸡，鸡生蛋”的问题，因为密钥的密钥也需要密钥。

如果服务端不在连接时获取与客户端交互的密钥，而是提前创建呢？也不行，服务器同时与多个客户端进行交互，那么服务器就得维护多个不同的对称密钥与客户端的映射关系，十分麻烦。

方案2：只使用非对称加密

客户端和服务器通信之前，先在各自本地生成一对非对称密钥，然后双方进行公钥的交换。完成后，客户端持有服务器的公钥S，服务器持有客户端的公钥C，那么往后的通信过程，因为私钥S’是服务器私有的，所以客户端用公钥S加密后的密文只有服务器能解密，反之同理。

这样做依然有两个缺点：

1. 效率低，因为整个传输过程都是非对称加密。
2. 安全问题仍存在，中间人可以攻击密钥协商过程。

方案3： 非对称加密 + 对称加密

这种方案是以非对称加密完成密钥协商，以对称加密进行通信。服务器需要先持有一组非对称密钥（公钥S和私钥S’），收到客户端的连接后，发送公钥S给客户端。客户端收到公钥S，并生成对称密钥X，X本地保留一份，用公钥S加密后发送给服务器一份。由于私钥S’只有服务器持有，因此只有服务器能解密并获得来自客户端的对称密钥X，此后便可以用X通信。这样做将大部分非对称加密的过程变为对称加密，只在密钥协商（双方获得共享对称密钥的过程）时用到了非对称加密，大大提高效率。 但安全问题仍存在，中间人能够窃取并篡改服务器发送给客户端的公钥，见下图详解：

⭕这种方案最大的问题就是：客户端无法分辨接收到的公钥是否来自请求的服务器。 为了解决这一问题，便诞生了一种第三方机构——CA机构（Certificate Authority），是一种认证网络通信组织或个体的合法性、可靠性的机构。

方案4：非对称加密 + 对称加密 + CA证书

这种方案是HTTPS采用的最终方案，我们先要认识什么是CA证书。

什么是CA证书

CA证书是由CA机构颁布的一种证书，又被称为数字证书。证书主要包含证书拥有者的身份信息，CA 机构的签名，公钥。CA 证书是一串能够表明网络用户身份信息的数字，提供了一种在计算机网络上验证网络用户身份的方式，因此数字证书又称为数字标识。

CA证书由两部分构成——数字签名（sig）和明文信息（info），明文信息包含证书拥有者的身份信息，如：域名、申请时间等，最重要的是包含了证书拥有者的公钥。数字签名是对明文信息进行摘要后加密得到的数据。

CA证书的申请流程

任何服务器想要得到客户端的信任，必须向CA机构申请CA证书。就好比餐厅需要向有关部门申请经营许可证，以向顾客确保自身的合法性。下面是服务器向CA机构申请证书的具体流程。

引入证书的HTTPS加密方案

方案4中主要问题就是密钥协商过程中，客户端无法确认接收公钥的合法性，引入证书能够解决这个问题。现在，在密钥协商过程中，不再让服务器直接发送公钥明文，而是发送服务器的CA证书（证书中含公钥）。客户端接收到证书后，需要做以下三件事：

1. 检查证书是否过期
2. 检查证书是否来自可信赖的签发机构（OS/浏览器中已内置的受信任的证书发布机构 ）
3. 检查证书内容是否被篡改，即验证证书的合法性

前两步直接通过检查证书的明文信息即可，第三步是这种方案的核心，判别证书合法后，便可获取证书中的公钥，再生成对称密钥完成密钥协商，如下：

• 方案原理

前置知识：

1. CA机构公开的信息：hash算法（用于处理明文信息）、公钥(用于解密数字签名)。一般是内置在OS或浏览器之中的。

2. CA加密数据摘要的私钥只有CA能够持有。

3. 本地OS/浏览器包含了一些可信任的CA认证机构（维护CA的公钥和一些相关信息）。客户端接收到服务端发送的证书后，根据证书中的一些有效信息（如：签发机构、域名等），索引本地内置对应的CA公钥和hash算法，并以此做进一步信息对比。

4. 对于某个CA机构，只有该机构的哈希算法能正确处理该机构发出的证书，相反，也只有该机构的证书能被该机构的哈希算法正确处理。一旦证书中的明文内容被修改，再用对应的哈希算法处理也无效了。

了解了以上的前置知识，再来看中间人攻击的各种情况，看看在本方案下中间人是否能够“得逞”。

⭕中间人攻击的情况：

1. 只修改明文数据的内容。 不管用，修改了明文，明文对应的hash值就改变了，与证书中的数字签名不再匹配。客户端进行签名与明文hash值对比时，就能辨别出证书被篡改过。
2. 只修改数字签名。 中间人没有CA的私钥，无法对解密后的数字签名再加密，因此只能对数字签名密文直接修改，而由于客户端始终用CA的公钥对数字签名解密，只有经过CA私钥加密的数字签名才能被成功解密，修改之后的数字签名是解密无效的。
3. 整体替换整个证书。 如果中间人也有CA证书，用自己的证书替换服务器发给客户端的证书，那么就要看中间人的证书是否“正规”了。
   • 如果中间人的证书是“伪造”的，也就是用自己的私钥形成的数字签名，但客户端用CA的公钥对数字签名解密，“伪造”的数字签名是无效的。
   • 如果中间人的证书是真正从CA机构申请的，那么其证书也是有中间人信息的，客户端会甄别证书是否合法（即判断证书信息是否与所申请服务器信息一致）。

常见问题

1. 为什么证书要引用摘要加密后的数字签名，而不是直接引用摘要？

   要知道，CA机构的权力更多的是来自用户的信任，因为用户都会使用内置的CA公钥来解密数字签名。私钥是CA机构私有的，公钥是客户端共享的。如果证书不用数字签名，而是直接用数据摘要，就意味着CA放弃了使用私钥的权力，那么客户端也就无需使用内置的CA公钥对摘要进行解密，这就意味着客户端失去了判别数据摘要合法性的能力，因此中间人可以任意修改证书中的内容而不被发觉。

2. 为什么签名不直接加密明文，⽽是要先将明文hash形成摘要后再加密?

   缩⼩签名密⽂的⻓度（摘要是定长的），加快数字签名的验证签名的运算速度

---

ENDING…