【Linux】：HTTPS协议
朋友们、伙计们，我们又见面了，本期来给大家带来HTTPS协议相关的知识点，如果看完之后对你有一定的启发，那么请留下你的三连，祝大家心想事成！
C 语 言 专 栏：C语言：从入门到精通
数据结构专栏：数据结构
个 人 主 页 ：stackY、
C + + 专 栏 ：C++
Linux 专 栏 ：Linux
目录
1. 概念准备
1.1 加密
1.2 为什么需要加密
1.3 常见的加密方式
1.3.1 对称加密
1.3.2 非对称加密
1.4 数据指纹（数据摘要）
1.5 数字签名
2. HTTPS协议的加密过程
2.1 只使用对称加密
2.2 只使用非对称加密
2.3 双方都使用非对称加密
2.4 对称加密和非对称加密结合
3. 引入证书
3.1 理解CA证书签发过程
3.1.1 理解数据签名
3.1.2 黑客对证书进行修改
3.2 证书 + 对称加密 + 非对称加密结合
HTTPS协议也是一个应用层协议，是在HTTP协议的基础上引入了一个加密层；
HTTP协议的内容都是按照文本的方式明文传输的，这就导致在传输过程中可能会出现一些数据被篡改的情况。
在正式了解HTTPS协议之前我们先来了解一下HTTPS的这个加密过程；
1. 概念准备
1.1 加密
加密就是把 明文 (要传输的信息)进行一系列变换，生成 密文。
解密就是把 密文 再进行一系列变换，还原成 明文。
1.2 为什么需要加密
之前比较容易发生运营商劫持事件；
就比如我们要下载一个软件，然后我们在浏览器上面搜索软件，当我们点击下载的时候，其实并不是我们想要下载的软件，先给我们下载一个中间软件，然后通过这个中间软件再去下载，就比如我遇到的下载软件下载到了360安全卫士；
我在网上找了一些运营商劫持的图片：
基本原理就是：
点击 "下载按钮"，其实就是在给服务器发送了一个 HTTP 请求，获取到的 HTTP 响应其
实就包含了该 APP 的下载链接。运营商劫持之后，就发现这个请求是要下载天天动听，
那么就自动的把交给用户的响应给篡改成 "QQ 浏览器" 的下载地址了。
其实不止运营商可以劫持，比如一些网络上的黑客，可以通过此类手段来盗取用户信息，从而获得一些收益等等；
所以在网络上明文传输是比较危险的一件事情；
HTTPS就是在HTTP的基础上进行数据加密，进一步来保证用户的数据安全！
1.3 常见的加密方式
1.3.1 对称加密
只有一个密钥（单密钥），既可以用来加密，也可以用来解密；
- 常见的加密算法：DES、 3DES、 AES、 TDEA、 Blowfish、 RC2 等
- 特点：算法公开、 计算量⼩、 加密速度快、 加密效率⾼
一个简单的对称加密，按位异或：
假设明文：x = 7 密钥：key = 5
加密：a ^ key 得到的密文b = 2
解密：b ^ key 得到的明文a = 7
1.3.2 非对称加密
需要两个密钥来进行加密和解密，其中一个密钥公开，叫做公钥，一个密钥私有，叫做私钥；
公钥和私钥是配对的，用公钥加密的数据只能用私钥解密，反之，用私钥加密的数据只能用公钥解密；
- 常见的加密算法：RSA， DSA， ECDSA
- 特点： 算法强度复杂、 安全性依赖于算法与密钥但是由于其算法复杂， 而使得加密解密速度没有对称加密解密的速度快
1.4 数据指纹（数据摘要）
数字指纹(数据摘要)，其基本原理是利用单向散列函数(Hash 函数)对信息进行运算,
生成一串固定⻓度的数字摘要。 数字指纹并不是一种加密机制,但可以用来判断数据有
没有被篡改。
- 摘要常见算法： 有 MD5、 SHA1、 SHA256、 SHA512 等；
- 算法把无限的映射成有限， 因此可能会有碰撞（两个不同的信息， 算出的摘要相同， 但是概率非常低）
- 摘要特征： 和加密算法的区别是， 摘要严格意义不是加密， 因为没有解密， 只不过从摘要很难反推原信息， 通常用来进行数据对比
- 如果更改了原始数据，散列值的变化是很大的，另外hash散列是单向的，只能转化成散列值，不能从散列值转化为原始数据；
数据指纹的两个常见的应用场景：
1. 两个数据进行比对：
我们在注册用户的时候，需要输入用户名和密码，此时就可以把密码进行一下hash散列形成一段散列值保存在服务器中的数据库中，当下次登录的时候，将输入的密码先用同样的hash散列函数转化成散列值，然后去数据库进行比对；
2. 两个文件进行比对：
比如我们的这个百度网盘的这个秒传，如果我们要上传一个特别大的数据文件（视频资源、音频资源等等）时，他先回把我们的这个资源数据hash散列转化成散列值，然后传递到后端服务器去寻找有没有同样的资源，如果有那么直接进行一个指向性文件的创建（类似于Linux下的软链接），此时就完成了秒传，如果没有那就只能慢慢的上传了；
1.5 数字签名
数据摘要经过加密， 就得到数字签名（这个后面细说）
2. HTTPS协议的加密过程
既然要保证数据安全, 就需要进行 "加密"。
网络传输中不再直接传输明文了，而是加密之后的 "密文"。
加密的方式有很多，但是整体可以分成两大类：对称加密 和 非对称加密。
接下来我们一一进行设计，自己走一遍这个过程，进行加密的设计，问题的提出，方案的优化：
2.1 只使用对称加密
通信双方都约定好一个密钥，我给你发数据是使用这个密钥加密，你解密也使用这个密钥进行解密，这样子即使数据被中间黑客拿到了，但是他没有密钥，他也不能知道你的具体数据是什么，除非你这个密钥被黑客破解了；
但是这只是基于通信人数比较少的情况，但是实际上服务器是给很多很多客户端提供服务的，那么这么多的客户端，那应该每个客户端和服务器之间约定的密钥都需要不同，如果相同，那么黑客也很容易可以拿到密钥，那么就需要很多不同的密钥，服务器维护这么多的密钥也是一件不现实的事情，所以只使用对称加密是不能完成的；
2.2 只使用非对称加密
如果只使用非堆成加密的话又会如何呢？接下来我们来演示一下这个过程：
- ① 服务器生成一个公钥S和一个私钥S'，在通信之前先进行密钥的交换；将公钥交给客户端，此时作为中间人的黑客也可以拿到公钥S；
- ② 接下来客户端拿着公钥S对数据进行加密形成密文然后发送给服务器，此时中间人黑客也可以拿到密文，但是要解开这个密文的私钥S'只有服务器有，所以黑客也无能为力，所以服务器拿到密文之后用私钥S'对密文进行解密；所以就可以拿到数据了；
- ③ 但是呢，这只是客户端向服务器发送消息，反过来服务器也要给客户端进行消息的响应呀，那么如果服务器向客户端发送消息的时候，用自己的私钥S'加密形成密文，发送给客户端时，中间人黑客也可以拿到密文，由于这个密文是私钥S'加密的，能解开的只有公钥S，此时黑客已经有公钥S了，所以可以直接进行解密获取到信息，所以只使用非对称加密也是有安全问题的；
2.3 双方都使用非对称加密
上面的两种方法都不可行，那么如果双方都使用非对称加密呢？接下来我们来演示一下：
- ① 双方在通信的时候进行密钥的交换，中间人黑客可以拿到客户端的公钥和服务端的公钥；
- ② 然后客户端用服务器交给他的公钥进行加密然后发送，此时中间人没有服务器的私钥，所以无济于事；
- ③ 服务器向客户端发送响应，用客户端的公钥加密然后发送，中间人黑客也没有客户端的私钥，所以拿到数据也无济于事。
但是这种方法面临两个问题：
- 1. 非对称加密的时间太长了，效率极低；
- 2. 其实还是存在安全隐患的（后面再说）
2.4 对称加密和非对称加密结合
上面的几种方法都不可取，所以为了节省时间，我们搭配着来，使用对称和非对称的方法，接下来就来演示一遍：
- ① 我们在通信之前进行密钥的交换，此时不是单纯的传递密钥，而是使用非对称加密的方式进行对称密钥的交换；
- ② 服务器生成公钥S和私钥S'，然后将公钥S发送给客户端，此时中间人黑客也可以拿到公钥S，然后客户端将公钥C使用公钥S进行加密发送给服务端，中间人拿到了密文但是他没有私钥S'，所以不能解密，然后服务端拿着密文使用S'进行解密之后拿到了公钥C，此时这个公钥C只有客户端和服务端知道，中间人黑客是不知道的；
- ③ 从此往后，客户端和服务端只需要用公钥C进行加密解密就可以完成数据的交换了；
这种方法使用非对称加密进行密钥的交换，然后使用对称加密继续通信，虽然解决了效率问题，但是，这个方法还是存在问题；
这种情况下我们的中间人黑客其实还没有发力，他是只静静的等待着密钥和密文的到来，并没有对密文和密钥做什么事情，那么接下来黑客就要发力了（中间人攻击：MITM攻击）：
- ① 当服务端向客户端发送公钥S的时候，此时中间人黑客也可以收到，并且黑客自己也有一个公钥M，黑客直接把服务端发送的S替换成自己的公钥M发送给客户端；
- ② 客户端并不知道这个公钥是否合法呀，所以拿着这个公钥M对自己的公钥C进行了加密，然后发送给服务端，此时黑客拿到了密文，非常高兴，直接对密文进行解密，拿到了公钥C；
- ③ 为了避免被服务端发现，黑客又很懂事的拿着服务端的公钥S对公钥C进行了加密，发送给服务端，服务端也正常可以使用S'进行解密拿到公钥C，从此以后，服务端和客户端通信使用的公钥C黑客也有了，双方之间发送的任何数据黑客都可以进行解密获取哦！！！
其实前面的三种情况都存在这样的问题，这个问题的主要核心就是：客户端无法判别密钥的合法性；
此时，就需要有一种让客户端来判别你给我发送的密钥时候合法的东西：CA证书
3. 引入证书
服务端在使用 HTTPS 前， 需要向 CA 机构申领一份数字证书， 数字证书里含有证书申请者信息、 公钥信息等。 服务器把证书传输给浏览器， 浏览器从证书里获取公钥就行了， 证书就如身份证， 证明服务端公钥的权威性；
这个 证书 可以理解成是一个结构化的字符串, 里面包含了以下信息:
- 证书发布机构
- 证书有效期
- 公钥
- 证书所有者
- 签名
那么该如何理解这个CA签发证书的过程呢？- 另外，证书里面的明文信息如果被更改了呢？
3.1 理解CA证书签发过程
- ① 在通信之前，server首先生成自己的私钥pri_svr和公钥pub_svr，然后将自己的私钥保存好；
- ② 接下来先需要申请证书，需要上传的信息域名、申请者、公钥等，然后生成一个.csr的文件提交给CA机构进行审核，审核无误之后CA机构就会给server签发一个证书；其中这个证书里面有签名、以及一些明文信息（签发机构、域名、申请者、公钥pub_svr等）；
- ③ 这样子server端就有了证书，然后此时在进行密钥交换时进行证书的传递，客户端拿到证书之后先验证证书是否合理，然后再提取公钥，使用对称和非对称加密进行通信即可。
那么客户端如何验证证书的合法性呢？接下来就需要对证书里面的签名进行理解：
3.1.1 理解数据签名
CA机构不仅可以进行证书的签发，他还有自己的非对称加密的公钥和私钥。
CA机构数据签名的过程：
- ① 把证书里面的明文信息通过hash散列转化成一串散列值，然后使用CA的私钥对散列值进行加密，被加密的数据就叫做签名；
- ② 然后把明文信息和签名附加就形成了一个CA证书；
CA证书的验证过程：
- ① 客户端拿到证书之后，将证书里面的签名和明文数据分离；
- ② 然后对明文数据进行hash散列形成散列值，然后使用CA的公钥解密签名，然后判断形成的散列值与解密后的签名是否相同，如果相同则表示证书无误，可以使用明文数据中的公钥。
在这个过程中，CA的私钥只有CA机构知道，我们的浏览器是需要内置CA公钥或者CA授权机构的公钥。
3.1.2 黑客对证书进行修改
接下来演示如果黑客把证书修改了客户端会看到什么变化呢：
1. 只修改明文数据里面的公钥
如果把公钥修改了之后，然后客户端拿到这个证书之后，使用hash散列对明文数据进行散列化得到了散列值，然后使用CA公钥对签名进行解密得到的散列值与之比较，因为签名对应的明文数据中的公钥是server端对应的散列值，而客户端拿到的明文数据中的公钥是黑客的，所以两个散列值肯定不一样，因此就可以判断出这次发送的公钥是非法的；
2. 只修改签名
因为客户端拿到证书之后对签名使用的是CA公钥解密，黑客将签名修改，黑客并没有CA的私钥，不能形成一个能让CA公钥解密的签名，所以这样做没有意义；
所以证书里面的明文数据是不害怕被修改的，修改后就可以被验证出来；
3.2 证书 + 对称加密 + 非对称加密结合
最终HTTPS加密过程就使用的是证书 + 对称加密 + 非对称加密的方法完成的，解决了客户端无法识别公钥的合法性的问题：
这就是HTTPS的密钥协商的过程！
