绪论
“如今我努力奔跑，不过是为了追上那个曾经被寄予厚望的自己 —— 约翰丶利文斯顿”，本章承接上章Http，没看过强烈建议看后再看本章，本章主要就是学习Https是干什么的并且去底层的学习Http的原理，将会讲到Https的加密、解密过程。
话不多说安全带系好，发车啦（建议电脑观看）。
Https协议
https也是一个应用层协议，是在http协议的基础上引入了一个加密层
常见的https其实就是加密式的http
http协议内容是按照文本的方式明文传输的，这就导致在传输过程中可能出现一些被篡改的情况，所以就需要将这些明文给进行加密防止数据泄露
加密、解密过程
- 加密：把明文（要传输的信息）进行一系列变换生成密文的方法
- 解密：把密文进行一系列变换还原成明文的方法
秘钥：在解密过程中往往需要辅助进行这个过程的一个或者多个中间值
理解运营商、浏览器（客户端）、服务器的关系
关系如下图：
浏览器和运营商设备关系我们能理解成，当我们用手机给电脑使用热点来入网，手机就是运营商设备，电脑就是浏览器，电脑所要发送的信息都会经过手机（中间人）！
常见加密方式：
- 对称加密：加密和解密所用的秘钥是一样的，也称为单密钥加密。通过同一个密码加密解密。
常⻅对称加密算法(了解)：
1. DES
2. 3DES
3. AES
4. TDEA
5. Blowfish
5. RC2等
特点：算法公开，计算量小，加密速度快，加密效率高
- ⾮对称加密：需要两个秘钥进行加密和解密，这两个秘钥是公开秘钥（公钥）和私有秘钥（私钥）
使用方法：- 公钥加密只能私钥解密
- 私钥加密只能公钥解密
（建议先记忆后面会写具体使用就会更好的理解!）
常见的⾮对称加密：
1. RSA
2. DSA
3. ECDSA
特点：算法强度复杂、公钥私钥是配对的，运算速度非常慢、算法复杂
数据摘要、数据指纹
利用单向散列（Hash函数）对信息进行运算，生成一串固定长度的数字摘要
常见方法：
- MD5
- SHA1
- SHA256
- SHA512等
算法把⽆限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要可能相同，但是概率⾮常低）
数据摘要其实就等于数据指纹（一个概念）
单向散列的应用场景：
-
对用户注册的账号的密码进行加密存进MySQL数据库（因为密码直接明文存在数据库里面其实也并不安全，而散列值只能单向加密（无法通过散列值还原数据），所以散列值即使泄密了无法返回去解密也无法被还原）
-
百度网盘，秒传功能，其实就是对于百度来说他们在存储时不会存储多份相同的数据。百度会把所有上传的数据生成散列值，然后查看散列值是否相同，若相同则直接形成一个链接直接链接上即可，就不需要在服务器内存储多份相同的数据。
数据指纹用于：
- 对比两个文件是否是同一个
- 判断是否被篡改过
数字签名：经过加密的数据摘要
关于https的加密发展
设计一下https，提出方案（若不想看直接跳方案5）
下面将会不断提出方案通过不断提出然后修正，最终得到最好的方案
方案1：
只使用对称加密，是不行的因为无法让服务器和客户端直接通过网络用上同一个秘钥
方案2：
只使用一个非对称秘钥：服务端通过公钥加密发给客户端，客户端使用公钥解密，服务端使用私钥解密。
会导致数据被盗因为：公钥是公开的，当S服务器发送消息（数据）给C客户端时可能会被中间人给截胡解密从而导致数据的泄露
方案3：
双方同时使用非对称秘钥
能实现加密但效率低（有一定的安全问题：穷举）
方案4：
非对称加密 + 对称加密：服务器使用非对称生成公钥和秘钥，并且把S公钥给到客户，客户使用对称生成对称秘钥C。
再通过S的公钥把密钥C进行加密给到服务器，这样就只有有S’秘钥的服务器才能解密得到C，从而服务器也就得到对称秘钥C，就能进行对称加密。
但仍然有一定漏洞：中间人将服务器传来给客户端的公钥S，截胡然后把中间人生成的公钥M给到客户（客户并不知道自己收到的公钥其实并不是服务器的）当客户再把密文传来时，就能通过M’解开得到对称秘钥C，然后再还原真正要传给服务器的密文（C + S），这样中间人就能再中间不断的获取服务器和客户相互之间的数据！
方案4的核心问题在哪里？
client无法判断收到的公钥S的合法性！
方案5：
所以方案5就是在这个基础上优化第四种方案
引入证书
理解类似于我们进网站时见到的：
CA认证（相当于权威机构认证）
服务端在使用https前，需要向CA机构申领一份数字证书，数字证书里含有证书申请者信息，公钥信息等。
服务器先形成自己的公钥和私钥，将域名/申请者/公钥打包生成请求文件（.csr），给到CA机构进行审核信息，审核成功后签发证书（证书内的公钥就是服务器给client的公钥）
证书（数字签名的数据）的使用过程：
证书 = 企业明文数据 + 签名
- 将数据和签名（把数据形成的散列经过加密）合并成数字签名的数据
- 在验证时候把它们分开来再查看散列值是否一样就能确定数据是否被更
其中生成的签名是通过CA（签名者）的私钥加密生成的，中间人拿着个签名没办法，这样我们就解决了服务器的公钥被中间人替换的问题！！！
client进行如下操作：
- client得到了：证书 + 域名 + 公钥 + CA签名（CA私钥）
- 甄别
1. 若数据被修改了它的散列值也将对不上签名解密的散列值
2. 若是改签名，因为浏览器只会用CA的公钥解密，若是中间人写的签名是无法被解密的。
3. 数据和签名全改了，也就表示着得用真正的证书，而真证书只能由CA签发，这样也就暴露了，客户端也能根据假证书的域名和所要进入的域名区别来识别
4. 所以只要没出现上述问题就表示数据正常 - 从证书中提取server公钥
- 最后走方案4即可加密传送数据！
现在https所用的加密：
浏览器/client内置CA权威机构的公钥 + 证书（存的服务器公钥） + 非对称 + 对称 （也就等于方案5）
附：
- 可以使⽤在线⽣成CSR和私钥：https://myssl.com/csr_create.html
- 在我们浏览器中也会提前内置证书：
- 内部就会有存在明文信息（公钥等信息）
本章完。预知后事如何，暂听下回分解。
如果有任何问题欢迎讨论哈！
如果觉得这篇文章对你有所帮助的话点点赞吧！
持续更新大量计算机网络细致内容，早关注不迷路。
