目录
[HTTPS 是什么](#HTTPS 是什么)
[不得不的策略 - 应对"运营商劫持"](#不得不的策略 - 应对“运营商劫持”)
["加密" 是什么](#“加密” 是什么)
[HTTPS 工作原理](#HTTPS 工作原理)
[2） 引入非对称加密](#2） 引入非对称加密)
HTTPS 是什么
HTTPS 也是一个应用层协议，是在 HTTP 协议的基础上引入了一个加密层。
HTTP 协议内容都是按照文本的方式明文传输的，这就导致数据在传输的过程中出现一些被篡改的情况。
不得不的策略 - 应对"运营商劫持"
当我们下载一个"快玩游戏盒"，如果是像这样的情况，一般就是存在运营商劫持的情况~~~
当我们点击下载按钮，就会弹出 360 软件宝库的下载链接~~
如果未被劫持，点击下载按钮，就会直接弹出快玩游戏盒的下载链接~~
由于我们通过网络传输的任何数据包都会经过运营商的网络设备（路由器，交换机），那么运营商的相关网络设备就可以解析出我们传输的内容，并进行篡改~~
当点击"下载按钮"，其实就是给服务器发送了一个 HTTP 请求，获取到的 HTTP 响应其实就包含了 APP 的下载连接，但是，如果被运营商劫持了之后，就会发现这个请求是要下载快玩游戏盒，那么就自动的把交给用户的响应的快玩游戏盒的下载连接给篡改成"360 软件宝库"的下载地址了~~
运营商为什么要进行劫持呢？？？
不止运营商可以劫持，其他的黑客也可以用类似的手段来进行劫持，窃取用户的隐私信息，或者篡改内容~~
试想一下，如果 hacker 在用户登录支付宝的时候，获取到了用户的账户余额，甚至获取到了用户的支付密码...
在互联网上，明文传输的比较危险的事情！！！
HTTPS 就是在 HTTP 的基础上进行了加密，进一步的来保证用户的信息安全，进一步的来保证用户的信息安全~~
"加密" 是什么
加密就是把 明文 （要传输的信息）进行一系列变换，生成 密文。
解密就是要把 密文 再进行一系列变换，还原成 明文。
在这个加密和解密的过程中，往往需要一个或者多个中间的数据（密码本什么的），辅助进行这个过程，这样的数据称为 密钥。
分类
加密的方式有很多，但是整体上可以分成两大类：对称加密 和 非对称加密
对称加密
对称加密其实就是通过同一个"密钥"，把明文加密成密文，并且也能把密文解密成明文~~
一个简单的对称加密：按位异或
假设明文 a = 1234，密钥 key = 8888
则加密 a ^ key 得到的密文为 9834
然后针对密文 9834 再次进行运算 b ^ key ，得到的就是原来的明文 1234
（对于字符串的对称加密也是同理，每一个字符都可以表示成一个数字~~）
非对称加密
非对称加密要用到两个密钥，一个叫做"公钥"，一个叫做"私钥"。
公钥和私钥是配对的，最大的缺点就是运算速度非常慢，比对称加密要慢的多。
在非对称加密中，使用的这两个密钥 k1，k2 是成对的。
可以使用 k1 来进行加密，此时就是 k2 解密。
也可以使用 k2 来进行加密，此时就是 k1 解密。
注意：这个特性是有一系列数学原理的，当手里只有一把的时候，是无法知道另一把是什么样的~
HTTPS 工作原理
只要针对 HTTPS 的数据进行解密，就能得到 HTTP 格式的数据。
我们前面提到的运营商劫持，无论是修改 referer 还是修改返回的连接（body），本质上都是明文传输惹的祸。
我们需要对数据引入加密，对传输的数据进行保护。其中，主要就是针对 header 和 body 进行加密
1）引入对称加密
通过对称加密的方式，针对传输的数据进行加密操作。这样，即使数据被截获，由于黑客不知道密钥是什么，因此就无法进行解密，也就不知道请求的真实内容是什么了~~
但这里还是存在问题的：
-
对称加密的时候，客户端和服务器需要使用同一个密钥。
-
不同的客户端，是需要不同的密钥的。（如果所有的客户端的密钥都相同，加密就形同虚设了，黑客还是很容易就拿到，从而还是会造成数据泄漏）
==》
这就意味着，每个客户端连接到服务器的时候，都需要自己生成一个随机的密钥，并且把这个密钥告知给服务器。（如果每个客户端的密钥都是一样的，那黑客只要也伪装成任意一个客户端向服务器发送一个请求，便可以得到密钥了）（也不一定是非得客户端生成，服务器生成也可以，但也是需要告诉客户端的~）
==》
这就是问题的关键所在！！！密钥需要从一方传输给另一方，但如果在传输过程中，一旦黑客拿到了这个密钥，就意味着我们的加密操作就没有任何意义了...
如上图所示，当客户端在告诉服务器："咱俩的密钥是 888888"的时候，黑客就知道了客户端和服务器之间的密钥，那么当服务器给客户端返回 body 的时候，即使是密文，也会被黑客劫持数据。
==》
虽然我们也可以针对"咱俩密钥使用 888888" 进行密文传输，如果使用对称加密，引入 key2 针对 key1 进行加密，但这也意味着，我们也需要把 key2 传输给服务器，同样这个过程还是可能被黑客拿到，这样就形成了套娃了~~
2） 引入非对称加密
使用非对称加密，主要的目的就算为了对对称密钥进行加密，确保密钥的安全性！！！
服务器生成一对非对称密钥，私钥则由服务器自己持有，公钥可以告诉任何客户端。
客户端在连接上服务器之后，需要先从服务器这边拿到公钥，客户端生成对称密钥，将对称密钥通过非对称密钥的公钥进行加密，发送给服务器，服务器通过非对称密钥的私钥进行解密，获得对称密钥。此后客户端和服务器就可以通过对称密钥来进行通信了。（这里的各种密钥，本质上都只是一串数字/数字）
补充：不能使用非对称加密，来针对后续传输的各种 header body 等进行加密，而是只能使用非对称加密，去加密对称密钥。 ＝＝》 **非对称加密的加密解密成本是非常高的（消耗的 CPU 资源），远远高于对称加密的成本。**一点点的使用，是完全没问题的，但是如果大规模使用，就难以承担了~~
中间人攻击
我们上述引入非对称加密后，整个过程似乎就非常安全了，看似防止了黑客的攻击，但是嘛，黑客也不是吃素的，为了获取利益，黑客们也是绞尽脑汁了~~
服务器可以创建出一对公钥和私钥，那黑客，也可以按照同样的方式，创建出一对公钥和私钥，来冒充自己是服务器~~
针对上述问题，要如何解决呢？？？
其实，仔细观察，最关键的问题是，客户端拿到公钥之后，如果有办法来进行验证，这个公钥到底是服务器发来的，还是黑客伪造的？？
引入证书
证书是一个结构化的数据，里面包含很多属性，最终以字符串的形式提供。
证书中会包含一系列信息，比如：服务器的域名，服务器的相关信息，公钥，证书有效期等等......
证书，是搭建服务器的公司，从第三方的公证几个后进行申请的。
这样客户端就可以获得公钥了~~~
这里还有一个关键问题是：黑客在中间人攻击中，就伪造了一对公钥和私钥，那这次在返回证书的时候，能否对证书的内容进行修改，将其中的公钥再换成自己伪造的呢？？？
==》
不可以！！！客户端在拿到证书之后，会对证书进行验伪操作。（都叫证书了，肯定不好伪造~）
证书的验证过程
证书一般包含的内容有：服务器的域名，证书的有效时间，服务器的公钥，公证机构信息........其中最关键的一点是，证书中还会包含一项 -- 签名！！！
颁布证书的第三方公证机构，会在发布证书的时候，根据证书的其他的字段通过一系列算法，计算出一个校验和，然后公证机构，还会使用自己的私钥（注意：这里是公证机构的私钥，和服务器无关~）针对该校验和进行加密，此时就得到了证书的签名。
（市面上的公证机构一共也没有多少，这些公证机构都拥有自己的私钥，对应的公钥，一般都包含在常见的系统中了，例如 windows 里面就内置了大量的公钥。如果系统中没有内置，也可以进行额外的安装）
客户端在拿到证书之后，主要需要做两件事来验伪：
1）按照同样的校验和算法，把证书中的其他字段都重新计算一次，得到一个校验和 1
2）使用客户端这边内置的公证机构的公钥，对证书中的签名进行解密，得到一个校验和 2
此时，就可以将校验和 1 和 校验和 2 来进行对比了。如果一致，那么就说明，证书在由服务器送往客户端的过程中，没有被其他人修改过，就是原版证书，如果不一致，就说明证书被别人篡改了。
补充：我们这里的操作，是为了防止黑客对证书进行修改，而不是防止黑客知道，黑客中的系统也内置了公证机关的公钥，黑客也是可以解密的。
但是黑客是无法对里面的内容进行修改的。
1）如果黑客直接修改公钥，不修改签名，那么此时客户端所得到的两个校验和一定是不一样的~~
2）如果黑客修改了公钥，也尝试对签名进行重新生成的话，更是行不通的。他没有第三方公证机构的私钥呀！！！无法对签名进行重新修改。如果黑客使用自己的私钥来进行加密的话，客户端那边内置的公钥又无法解密~~~
3）黑客也向公证机构申请一份证书，然后将自己的证书替换成服务器的证书~~~也是不可以滴~~~有没有一种可能，证书中不仅仅只有签名的信息嘞，还会有服务器域名等等信息~~~当客户端拿到证书之后，都不需要进行校验和的对比，打眼一看就发现了~~~
当然，我们上述讨论的过程，所谓的安全，也并非是绝对安全，其本质上都是基于非对称加密体系的。非对称加密体系，也不是无懈可击的，只是要破解非对称加密体系，所需要耗费的成本，以目前的计算机算力来说，是非常非常大的，远远超出了截获信息所能获取到的利益，因此我们的数据就是安全的了。
但是随着算力的提升，如果黑客轻松就能破解出非对称加密体系...........密码学就要迎来一波大换血了~~