HTTPS是什么

• HTTPS 也是一个应用层协议. 是在 HTTP 协议的基础上引入了一个加密层. HTTP 协议内容都是按照文本的方式明文传输的. 这就导致在传输过程中出现一些被篡改的情况.
• HTTPS是一种应用层协议，‌旨在通过传输加密和身份认证来保证传输过程的安全性。‌它是HTTP的安全版本，‌通过引入SSL/TLS来加密数据包，‌确保数据传输的安全性和验证网站的真实性。‌
• HTTPS相对于HTTP来讲其实就是在HTTP和TCP之间多加了一层加密层SSL/TLS
  

理解加密

什么是加密

• 加密就是把 明文 (要传输的信息)进行一系列变换, 生成 密文 .
• 解密就是把 密文 再进行一系列变换, 还原成 明文 .
• 在这个加密和解密的过程中, 往往需要一个或者多个中间的数据, 辅助进行这个过程, 这样的数据称为 密钥

为什么要加密

1. 防止中间人攻击

http协议用起来很简单，但是它存在着一个致命的问题，就是不安全，它的报文都是以明文方式进行传递的。也就是说http传输的一切数据都是暴露出去的，一旦请求被截取那么面临的就是数据泄漏。而这个过程就可能将用户的私密数据给泄漏。

所以：因为 http 的内容是明文传输的，明文数据会经过路由器、wifi 热点、通信服务运营商、代理服务器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉，这就是 中间人攻击 ，所以我们才需要对信息进行加密。

所以为了不让中间人获取数据，那么就必然的要对数据进行加密，让中间人无法识别数据内容。

常见的加密方式

对称加密

采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，种加密方法称为对称加密，也称为单密钥加密，特征：加密和解密所用的密钥是相同的

• 常见对称加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2 等
• 特点：算法公开、计算量⼩、加密速度快、加密效率⾼

对称加密其实就是通过同一个 “密钥” , 把明文加密成密文, 并且也能把密文解密成明文.

一个简单的对称加密, 按位异或假设 明文 a = 10, 密钥 key = 6666则加密 a ^ key 得到的密文 b . 然后针对密文 b再次进行运算 b ^ key, 得到的就是原来的明文 10. (对于字符串的对称加密也是同理, 每一个字符都可以表⽰成一个数字)当然, 按位异或只是最简单的对称加密. HTTPS 中并不是使用按位异或.

非对称加密

• 需要两个密钥来进行加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。
• 常见非对称加密算法(了解)：RSA，DSA，ECDSA
• 特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快。

非对称加密要用到两个密钥, 一个叫做 “公钥”, 一个叫做 “私钥”. 公钥和私钥是配对的. 最大的缺点就是运算速度非常慢，比对称加密要慢很多.

• 通过公钥对明文加密, 变成密文
• 通过私钥对密文解密, 变成明文

也可以反着用

• 通过私钥对明文加密, 变成密文
• 通过公钥对密文解密, 变成明文

数据摘要/数据指纹

• 数字指纹(数据摘要),其基本原理是利用单向散列函数(Hash 函数)对信息进行运算, 生成一串固定⻓度的数字摘要。比如说一篇文章，单向散列函数就会根据文章内容进行Hash函数生成一串固定长度的数字摘要，如果这个文章没有被修改过，那么就算来在多次hash函数算法计算出来的数字都是一样的，但是如果稍微有一点改动的话，生成出来的数字都会有很大的区别。所以说数字指纹并不是一种加密机制,但可以用来判断数据有没有被篡改，数据是不是同一份。
• 摘要常见算法：有 MD5、SHA1、SHA256、SHA512 等，算法把无限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率非常低）
• 摘要特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推原信息，通常用来进行数据对比

引用场景

云盘通过这样检索用户传递的数据摘要进行判断，如果发现已经有了相同的摘要，那么就说明有相同的一份数据，这样云盘就可以不用存放同一份数据了，直接给这个用户关联一份相同的数就行。这样不仅可以提高上传速度，还可节省云盘的空间资源。

HTTPS的工作过程探究

方案一，只使用对称加密

• 如果通信双方都各自持有同一个密钥 X，且没有别人知道，这两方的通信安全当然是可以被保证的。
• 但是问题来了如果是客户端生成的这个密钥X的话，客户端怎么才能让服务端知道这个密钥X呢？理想的是客户端和服务器建⽴连接的时候, 双方协商确定这次的密钥是啥。但是如果直接把密钥明文传输, 那么中间人也就能获得密钥了此时后续的加密操作就形同虚设了。但是要想对密钥进行对称加密, 就仍然需要先协商确定一个 “密钥的密钥”. 这就成了 “先有鸡还是先有蛋” 的问题了. 此时密钥的传输再用对称加密就行不通了.

方案二，只使用非对称加密

• 鉴于非对称加密的机制，如果服务器先把公钥以明文方式传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，从客户端到服务器信道似乎是安全的(有安全问题)，因为只有服务器有相应的私钥能解开公钥加密的数据。但是服务器到浏览器的这条路怎么保障安全？如果服务器用它的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输给浏览器的，若这个公钥被中间人劫持到了，那他也能用该公钥解密服务器传来的信息了。
  

方案三，双方都是用非对称加密

从方案三我们会发现如果只是使用一对非对称加密的话只能保证一方是是安全的。所以我们不难会想到用两对非对称加密，这样就可保证是双方通信安全的（难道真的安全吗？）

1. 服务端拥有公钥 S 与对应的私钥 S’，客户端拥有公钥 C 与对应的私钥 C’
2. 客户和服务端交换公钥
3. 客户端给服务端发信息：先用 S 对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥 S’
4. 服务端给客户端发信息：先用 C 对数据加密，在发送，只能由客户端解密，因为只有客户端有私钥 C’

那是不是这样真的安全呢？我们继续谈。

方案四，非对称加密+对称加密

方案二和方案三中都有一个明显的缺点，不说方案二是不安全的，方案三看似是安全的，但是非对称加密的效率是很低的，更别说是方案三使用了两对非对称加密，效率低也就说明了通信会很慢。而方案一虽然效率特别快但是也是不安全的，所以就产生了方案四，将两个融合起来。

1. 服务端具有非对称公钥 S 和私钥 S’
2. 客户端发起 https 请求，获取服务端公钥 S
3. 客户端在本地生成对称密钥 C, 通过公钥 S 加密, 发送给服务器.
4. 由于中间的网络设备没有私钥, 即使截获了数据, 也无法还原出内部的原文, 也就无法获取到对称密钥(真的吗？)
5. 服务器通过私钥 S’解密, 还原出客户端发送的对称密钥 C. 并且使用这个对称密钥加密给客户端返回的响应数据.
6. 后续客户端和服务器的通信都只用对称加密即可. 由于该密钥只有客户端和服务器两个主机知道, 其他主机/设备不知道密钥即使截获数据也没有意义.

由于对称加密的效率比非对称加密⾼很多, 因此只是在开始阶段协商密钥的时候使用非对称加密, 后 续的传输仍然使用对称加密.

• 虽然上面已经比较接近答案了，但是依旧有安全问题方案 2，方案 3，方案 4 都存在一个问题，如果最开始，中间人就已经开始攻击了呢？

中间人攻击 - 针对上面的场景

• Man-in-the-MiddleAttack，简称“MITM 攻击”
确实，在方案 2/3/4 中，客户端获取到公钥 S 之后，对客户端形成的对称秘钥 X 用服务端给客户端的公钥 S 进行加密，中间人即使窃取到了数据，此时中间人确实无法解出客户端形成的密钥 X，因为只有服务器有私钥 S’ 但是中间人的攻击，如果在最开始握手协商的时候就进行了，那就不一定了，假设hacker 已经成功成为中间人

1. 服务器具有非对称加密算法的公钥 S，私钥 S’
2. 中间人具有非对称加密算法的公钥 M，私钥 M’
3. 客户端向服务器发起请求，服务器明文传送公钥 S 给客户端
4. 中间人劫持数据报文，提取公钥 S 并保存好，然后将被劫持报文中的公钥 S 替换成为自己的公钥 M，并将伪造报文发给客户端
5. 客户端收到报文，提取公钥 M(自己当然不知道公钥被更换过了)，自己形成对称秘钥 X，用公钥 M 加密 X，形成报文发送给服务器
6. 中间人劫持后，直接用自己的私钥 M’进行解密，得到通信秘钥 X，再用曾经保存的服务端公钥 S 加密后，将报文推送给服务器
7. 服务器拿到报文，用自己的私钥 S’解密，得到通信秘钥 X
8. 双方开始采用 X 进行对称加密，进行通信。但是一切都在中间人的掌握中，劫持数据，进行窃听甚至修改，都是可以的

上面的攻击方案，同样适用于方案 2，方案 3问题本质出在哪里了呢？客户端无法确定收到的含有公钥的数据报文，就是⽬标服务器发送过来的！

方案五，终极版，非对称加密 + 对称加密 + 证书认证

引入证书

引入CA认证

• 从上面的中间人攻击事件分析，之所以会出现这样的漏洞，归根结底是因为客户端无法确定收到的公钥是否是目标服务器所提供的。所以我们只需要从这一点出发，只要让客户端确定收到的公钥一定是由目标服务器所提供的，那么问题不久迎刃而解了吗！所以这里首先引出CA机构。

• 一根服务器在线上时想使用HTTPS协议的话，就必须要向当地的CA机构申请一份数字证书，数字证书中含有申请者的信息，公钥等。

• 申请过程：首先服务器端自行提供S（公钥）和S`（私钥），并且提供好服务器的基本信息，并将基本信息和公钥发送给CA机构，并向当地的CA机构发起申请数字证书，该数据会形成CSR文件发送给CA机构，当地的CA结构在收到申请后，会对所提供的信息进行核对（甚至可能时微服私访），核对身份后CA结构就会给服务器返会一个证书，这个证书是由两部分组成的，一部分是之前服务器自行所提供的基本信息（这里重点提到S公钥这个基本信息）还有就是签名（下面会将签名和验证）服务器拿到这个证书后，一旦由客户端进行请求，服务器就会返回这个证书，而这个证书中包含了服务器提供的公钥，以及CA机构提供的签字，这样就能保证数据不被掉包。

签字和验证

• 在CA机构给服务器发送一个证书的时候，我们说过了这个证书是由两部分组成的，一部分是服务端向CA结构提供的基本信息，另一部分是CA机构提供的签名。
• 这里的签名操作其实就是对数据摘要的加密操作，而数据摘要就是服务端向CA结构提供的基本信息通过hash散列函数生成的散列值，然后对散列值进行加密。这个加密操作时由CA机构提供的。在服务器发送请求的时候，CA机构也会提供A（公钥）和A`（私钥），CA机构会对散列值使用私钥进行加密，从而形成了签名。然后将签名和数据整合才形成了证书。
• 而之所以客户端非常的确定拿到的公钥就是目标服务器所提供的公钥，是因为验证这一步。在客户端收到了服务器发送来的证书后，首先客户端会把拿到的基本信息也作一次相同的hash散列函数生成的散列值，同时使用CA机构提供的公钥对签名进行解密，将生成的散列值和解码后的散列值进行对比后如果发现时相同的那么就说明收到的公钥一定时由目标服务器所提供的，反之数据时被修改过的。

• 那么就有小伙伴问了，CA那么客户端是如何知道CA机构的公钥的呢？其实所有的浏览器都（客户端）一般都要内置可信的CA机构或者授权的子结构的公钥。

• 那么上面这种情况会不会受到中间人的篡改呢?答案是非常的难做到，因为就算中间人截取到了请求，但是因为中间人没有CA机构所认证的私钥，也就无法对签名进行篡改，一旦中间人对数据进行篡改了，那么在客户端中，验证阶段中一定不能通过，也就避免了被数据泄漏问题。

• 那么中间人可不可以将整个证书替换呢？答案是做不到，因为中间人式没有CA机构提供的私钥的，也就无法生成签名，也无法生成证书发送给客户端。那么如果中间人申请了真的证书，然后用自己申请的证书进行掉包呢？这个确实是可以做到，但是别忘了，申请CA证书是需要提供基本信息的，其中就包括域名，而域名式全网唯一的，并且就算掉包了，别忘了客户端在发起申请的时候是发送了要申请的域名的，如果返回的是中间人的证书，这个证书包含的中间人的域名，也就匹配不上了。

完整流程

总结

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

• 第一组非对称加：是用于检验证书是否被篡改了。服务器在CA机构申请证书后，一旦客户端发起请求后，服务端就会把这个证书发送给客户端，因为一般客户端操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的CA机构的公钥，于是就可拿到这个公钥就进行解密验证。

• 第二组非对称加密：是用于协商对称密钥的。客户端在检验证书的合法性后，救护提取出服务器发送过来的公钥，并在底层自动生成一个对称密钥，并用拿到的公钥进行加密，然后把这个加密好的对称密钥发送给服务端，这样客户端和服务端都有了这个对称密钥，并且只有他两个知道，也就可以进行加密和解密。

• 第三组对称加密：客户端和服务端后序的数据都是通过这个对称密钥进行加密和解密的。

• 第⼆组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器. 第一组非对称加密的密钥是为了让客户端拿到第⼆组非对称加密的公钥.