目录
[1. HTTPS](#1. HTTPS)
[2. 常见的加密方式](#2. 常见的加密方式)
[3. 加密方式实际场景分析](#3. 加密方式实际场景分析)
[3.1 只使用对称加密](#3.1 只使用对称加密)
[3.2 只使用非对称加密](#3.2 只使用非对称加密)
[3.3 双方都使用非对称加密](#3.3 双方都使用非对称加密)
[3.4 非对称加密 + 对称加密](#3.4 非对称加密 + 对称加密)
[3.5 CA证书](#3.5 CA证书)
[3.6 最终解决方案](#3.6 最终解决方案)
[4. HTTPS的配置与使用](#4. HTTPS的配置与使用)
1. HTTPS
HTTPS 也是⼀个应用层协议；是在 HTTP 协议的基础上引入了⼀个加密层； HTTP 协议内容都是按照文本的方式明文传输的；这就导致在传输过程中出现⼀些被篡改的情况；
为什么要加密？直接使用明文，别人使用抓包软件就会直接泄露;所以对于一些重要信息很有必要进行加密；
加密：加密就是把明文(要传输的信息)进行一系列变换，生成密文；解密就是把密文再进行一系列变换，还原成明文；
在这个加密和解密的过程中，往往需要一个或者多个中间的数据,辅助进行这个过程,这样的数据称为密钥；
举个例子，臭名昭著的"运营商劫持"：
在早期时小伙伴们使用浏览器搜索可能会遇到这样的情况:在浏览器中下载某个软件时，下载下来的不是我们想要的软件，而是另一个软件；这就是因为被运营商劫持的原因：
因为http的内容是明文传输的，明文数据会经过路由器、wifi热点、通信服务运营商、代理服务器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉，这就是 中间人攻击，所以我们才需要对信息进行加密；
不止运营商可以劫持，其他的黑客也可以用类似的手段进行劫持，来窃取用户隐私信息，或者篡改内容，试想一下，如果黑客在用户登陆支付软件的时候获取到用户账户余额，甚至获取到用户的支付密码.....；在互联网上，明文传输是比较危险的事情！HTTPS就是在HTTP的基础上进行了加密，进一步的来保证用户的信息安全；
2. 常见的加密方式
对称加密
采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密，特征：加密和解密所用的密钥是相同的；
常见对称加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2等；
特点：算法公开、计算量小、加密速度快、加密效率高；
简单的例子：简单的加密方式------异或；
假设明文a=1234，密钥key=8888 则加密 a ^ key 得到的密文 b 为 9834. 然后针对密文 9834 再次进行运算 b ^ key，得到的就是原来的明文1234；
非对称加密
需要两个密钥来进行加密和解密，这两个密钥是公开密钥（publickey，简称公钥）和私有密钥(privatekey，简称私钥）公开可以随意发送；
常见非对称加密算法(了解)：RSA，DSA，ECDSA(大数运算、大质数的因式分解)；
特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快(速度慢的多)；
常见非对称加密算法(了解):RSA，DSA，ECDSA(大数运算、大质数的因式分解)；
特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快(速度慢的多)；
公钥加密 必须用 私钥才能解密；私钥加密 必须用 公钥才能解密；公钥和私钥可以互相加密互相解密公钥和私钥是配对的；最大的缺点就是运算速度非常慢，比对称加密要慢很多；
举个例子：A要给B一些重要的文件，但是B可能不在；于是A和B提前做出约定：B说，我桌子上有个盒子，然后我给你一把锁，你把文件放盒子里用锁锁上，然后我回头拿着钥匙来开锁取文件，在这个场景中，这把锁就相当于公钥，钥匙就是私钥；公钥给谁都行(不怕泄露)，但是私钥只有B自己持有，持有私钥的人才能解密；
数据指纹/数据摘要
数字指纹(数据摘要)，其基本原理是利用单向散列函数(Hash函数)对信息进行运算，生成一串固定长度的数字摘要。数字指纹并不是一种加密机制，但可以用来判断数据有没有被窜改；
注意他本身并不是一种加密机制，因为他不能被解密；
如果对原始数据做一点点修改，通过同样的hash散列，摘要数据也会非常大；
使用场景：
场景1：
注册一个软件账户，会有账号和密码，实际场景中，密码是不能直接存储在数据库中的，而需要先进行加密，然后再存储密文，经过散列函数加密后生成数据摘要再进行存储；这样可以有效的避免账号被盗的风险；
场景2：
假设一个人要传一部战狼到百度云盘。第二个人也想上传战狼，但是云盘中已经存在一部了，难道还要再上传一份进行存储吗？那又来一个人呢 ...？这样肯定是不可取的，数据被重复存储是是很浪费的；
为了避免空间存储重复的数据，就可以使用"数据指纹"，再次上传时，让战狼(数据)通过哈希散列，得到数据指纹，然后在云盘中进行搜索，如果有就不再上传存储，建立一个链接文件，指向已有的文件即可；
数据指纹：
- 对比两个文件是否存在
- 对比数据是否曾经被篡改
3. 加密方式实际场景分析
3.1 只使用对称加密
如果通信双方都各自持有同一个密钥X，且没有别人知道，这两方的通信安全当然是可以被保证的(除非密钥被破解) ；
中间人攻击的情况：发送请求给对方，对方能拿到，中间人也一定能截取拿到数据；那么此时就存在一个致命漏洞，密钥的协商，在进行密钥协商时存在密钥被截取的风险；并且约定密钥也是问题，是都使用一样的密钥，还是每个客户端一个密钥？其实都不行，都使用一个密钥，一旦泄露全部的都会被破解；每个客户端各一个密钥也不行，那还要管理无数个密钥；
那使用动态密钥可以吗？也不行，服务端动态形成密钥，发送过去是使用密文还是明文？肯定是明文，明文经过路由器很有可能也会被黑客截获；想要约定好密钥，还不想让黑客知道，这个是做不到的；如果再对密钥进行加密，那就变成了"先有鸡还是先有蛋"的问题了；
因此只使用对称加密时是不安全的；
3.2 只使用非对称加密
非对称加密方式会有什么问题？
公钥是对外公开的，在发送公钥时，中间人也是可以拿到的；客户端向服务端发送加密的密文虽然是安全的，但是当服务端向客户端发送密文时，就存在消息泄露的风险，中间人可以使用公钥对服务端的密文进行解密；
因此这种方法也是不安全的；
3.3 双方都使用非对称加密
服务端拥有公钥S与对应的私钥S'，客戸端拥有公钥 C 与对应的 私钥 C';
客户和服务端交换公钥；
客户端给服务端发信息：先用S（服务端公钥）对数据加密，再发送，客户端发送的密文只能由服务端解密，只有服务端有私钥S'；服务端给客户端发信息；先用C对数据加密，再发送，服务端的密文只能由客户端解密，因为只有客户端有私钥C' 这样貌似也行，安全程度较高，但是效率太低；
虽然只有密文，但是依然可以通过计算机的算力，进行穷举，早晚会被破解，但也需要足够的成本当破解密文的成本大于密钥的价值时，我们就可以说，这个密钥是安全的；
这种方式虽然相对安全，但是效率较低；
3.4 非对称加密 + 对称加密
服务端有非对称加密的公钥 S 和 私钥S' ；
客户端发起请求，获取服务端公钥S；
客户端在本地生成对称密钥C，通过公钥S加密，发送给服务器
由于中间的网络设备没有私钥，即使截获了数据，也无法还原出内部的原文，也就无法获取到对称密钥服务器通过私钥 S' 解密，还原出客户端发送的对称密钥C，并且使用这个对称密钥加密给客户端返回的响应数据，后续客户端和服务器的通信都只用对称加密即可.由于该密钥只有客户端和服务器两个主机知道，其他主机/设备不知道密钥，即使截获数据也没有意义；对称加密的效率比非对称加密高很多，因此只是在开始阶段协商密钥的时候使用非对称加密,后续的传输仍然使用对称加密；（这样针真的就安全吗?）
并不安全，依然存在中间人攻击的风险，在最开始协商时中间人就已经进行攻击了呢？
中间人将服务端的公钥替换成自己的公钥，那么发送的所有数据都会被中间人截获；
问题在于客户端无法判定收到的公钥是否合法； 如何甄别公钥是否合法？这时就需要CA证书；
3.5 CA证书
服务端在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书发送给浏览器，浏览器从证书里获取公钥就行了；证书就如身份证，证明服务端公钥的权威性；
如果网站没有CA认证的证书，在访问时就会有类似这样的弹窗：
证书的颁发流程：
有了证书以后，client端再向server端发送请求，server端返回的就不在只是公钥了，而是证书(包含公钥及申请者信息)；
证书里的明文，就不怕被篡改吗？如何理解CA签发证书的过程；
CA机构签发证书有两把密钥：公钥和私钥；
生成数字签名由CA机构的私钥进行加密（只有CA机构能够生成签名），然后将签名加到（server端）提交的明文数据中，这也就形成了证书；client端在验证时，拿CA的公钥进行解密，对比证书数据的散列值和签名解析后的散列值是否相同；
中间人篡改数据情况：篡改证书明文数据 ------ 通过散列值对比可以解决；
篡改签名：签名被篡改，那么client验证时使用CA的公钥解析对比散列值就会不相同，中间人持有CA的公钥也没有用，因为只有CA的官方机构才可以签发数字签名(私钥加密)；中间人无法签发数字签名；CA公钥在编写client端时就已经内置，不可能篡改 ；
两个都篡改：中间人就只能用真签名去篡改；使用真签名，中间人就会暴露；证书中存在域名，不可能有两个相同的域名，替换证书client端也能分辨出来；
3.6 最终解决方案
CA证书 + client端内置CA公钥 + 对称加密 + 非对称加密；就是CA + 3.4的方案；
https密钥协商的整个过程：
4. HTTPS的配置与使用
现代的 Web 服务架构，通常采用前后端分离的设计，前端可能使用 Vue、HTML 等技术，而后端则通过 Nginx 进行配置和管理。在配置 HTTPS 时，首先需要设置 Nginx。根据安全性需求，后端服务可以选择是否也使用 HTTPS，并将经过加密的响应返回给 Nginx。
Nginx 是一个高性能的 Web 服务器和反向代理服务器，广泛应用于当今的网络架构。
在配置 HTTPS 时，无论是 Nginx 还是后端服务，都需要两个关键文件：SSL 证书和密钥（私钥）。SSL 证书用于验证身份并确保数据的安全传输，而私钥则用于解密由客户端发送的加密数据。
SSL证书就是服务端返回给客户端的数字证书，服务端的密钥（私钥）采用的非对称加密，公钥会通过证书发送给客户端；在nginx的配置时需要指定这两个文件；
当然在一些测试场景，可以选择使用工具，自己生成一份SSL证书和密钥进行测试，在实际发布时采用官方认证的证书和私钥；后续也会对nginx的配置进行介绍；
总结
以上便是本文的全部内容，希望对你有所帮助，感谢阅读！