文章目录
HTTPS协议
在HTTP中，我们还遗留了一个问题：
我们在网页中使用form表单进行提交参数的时候，不管是使用GET方法还是POST方法，其实都是存在一个很大的问题的：就是数据可以被其他人看见！
GET和POST的区别也就是在提交参数的方式上，一个是在URL上，一个是通过正文提交。然后序列化后发送到网络中。这些数据并没有做任何的处理，直接发送到网络。
这就导致，这样的方式提交，就很容易被其他人使用抓包工具获取到这些信息！！！
所以，在此之上，就需要有一种方式来解决这种数据在裸奔的问题！
这就是我们今天要讲的：HTTPS协议！
什么是HTTPS
如上图所示，这是网络中，通信双方的、最简化的模型！
对于HTTP也是一样的，这个时候，我们会发现，对于应用层HTTP相关的数据，我们并没有做任何的加密处理就进行发送了！
对于HTTPS的解释：
总结：
HTTPS 也是一个应用层协议，是在 HTTP 协议的基础上引入了一个加密层。
概念前置准备
接下来，为了后序能够更加清晰的理解一些，我们需要先来了解一些重要的概念！
加密(密文)和解密(明文)
先来了解第一个概念：加密和解密。
其实这个我们很好理解，就是在一些情况下，有一些内容是不能直接发送出去的，因为很可能导致机密泄露等一系列严重的问题！所以，在一些特殊情况下，一些要发送的数据必须要进行加密！比如我们听过很多次的：摩斯密码！
加密：就是把要发送的数据按照一定的方式进行处理，形成加密后的数据，被叫做密文！
解密：把收到的密文再按照一定的方式进行解密处理，得到的就是明文。
密钥
而在上述的过程中，加密和解密是需要通过一定的方式进行辅助的。这个方式，被称为密钥！
我们只需要把密钥理解为一个中间过程即可！用于辅助密文和明文之间的转换。
为什么要加密——运营商劫持解释
这里我们就讲一个最简单的例子
有时候我们可能会发现：我们想从网络上下载一些软件的时候，需要先点击下载，然后弹出下载连接，正常的情况是下面这样子的：
但是，我们需要知道一个最基本的常识：
我们今天在网络中的通信的数据，都是需要经过运营商的！
我们的流量、网线，都是从运营商那里缴费使用的。这个十分好理解。
如果我们仅仅使用HTTP协议进行通信，数据都是以明文进行传送，数据会被别人直接看到！
所以，会出现以下这种情况：
这就是运营商劫持的问题。从这里也可以看出：
如果只使用HTTP进行明文传送数据，是会引发很大的数据安全问题的！
常见加密方式
我们需要了解的是，常见的加密方式有哪一些？
1.对称加密
采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密，特征：加密和解密所用的密钥是相同的。
举个很简单的例子：
其实就是，通信双方都使用同一个密钥，来进行加密和解密！
常见算法和特点：
常见对称加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2 等
特点：算法公开、计算量小、加密速度快、加密效率高
2.非对称加密
非对称加密，意思就是，通信的双方使用的密钥是不一样的！
这里需要使用两个密钥来进行加密和解密：即 公钥和私钥！
公钥：就是公开的密钥。
私钥：只有极少数能使用的密钥。
其实就是一方发送数据的时候，使用公钥进行加密，然后接收方用密钥解密。
也可以反过来使用，总之，通信的双方在密钥的使用上是不对称的！
举个例子就能更好的理解：
今天A要给B一份重要文件，但是B可能不在
所以A和B约定：
B: 桌子上有个盒子, 还有一把锁, A把文件放盒子里用锁锁上, 然后B回来后拿着钥匙来开锁取文件。
在这个过程中，锁就是公钥，给谁都可以！但是，私钥是钥匙，只有B有！只有B能解开！
常见算法和特点：
常见非对称加密算法(了解)：RSA，DSA，ECDSA
特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加
密解密速度没有对称加密解密的速度快
数据摘要 & 数据指纹
其实数据摘要和数据指纹是一个东西来的，后序我都选择叫做摘要！
数字指纹(数据摘要),其基本原理是利用单向散列函数(Hash 函数)对信息进行运算, 生成一串固定长度的数字摘要。数字指纹并不是一种加密机制,但可以用来判断数据有没有被篡改。
Tips：摘要不是加密机制！因为没办法解密！
摘要常见算法：有MD5、SHA1、SHA256、SHA512等，算法把无限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率非常低）。
这个固定长度的数字摘要，我们可以理解为是一个数字字符串即可，其特点是：
1.无论原始数据量多大，最后生成的数字摘要都是一样长的！
2.原始数据极其微小的修改，都会导致生成的摘要和原来的有极大不同！
数字签名
如果对生成的摘要进行加密，就会得到一个数字签名！这里我们直接说是不明白的，需要结合后续的特殊场景来进行讲解。这里只需知道有这么一个概念即可！
提出四种解决方案
现在，有了上述的一些概念，和对HTTPS的初步认识，我们先提出几种方案，查看是否可行。
需要说明的是：
我们下面提出的四种方案，都是有问题的！HTTPS协议并不是下面这么做的。但是，下面的四种方案是层层递进的，而且是越来越接近HTTPS的做法！
只使用对称加密
就是双方直接使用对称加密进行加密和解密！
我们需要知道的是：
每个客户端和服务器之间的对称密钥一定是不同的！要不然我不就可以解密其他人的密文？
这个密钥是需要在建立连接的过程中，客户端先向服务器申请一个密钥的！
上述的过程，虽然说是对数据进行加密，但是有一个最大的问题：
密钥使用明文传送了！如果有一个中间人，在建立连接的时候就能抓包，抓到了这个密钥，那么，发送的密文他一样能解密！
但是，怎么解决这个密钥的安全呢？密钥本身也就是一个数据，难道再给它加密？
这肯定不行，这就好比我们在学习多线程的锁的时候，为了保证锁的原子性，不可能再给它上一层锁。这么做只会造成死循环。
所以，从上述的分析来看：只使用对称加密是不安全的！
只使用非对称加密
既然只使用对称加密不行，我们使用非对称加密！因为非对称加密的公钥是不怕泄露的！
这种情况，只有服务器持有私钥，也就只有服务器能够解密！
这个方案，其实还隐藏着一些问题：
1.使用非对称加密效率较低
2.上面只是展示了从客户端向服务器的安全，但是，服务器向客户端呢？
如上图所示：从服务器向浏览器的数据安全没法保证！
双方使用非对称加密
我们先来解决服务器到浏览器的数据安全问题！
其实我们可以很快的想出来一个解决方案，就是服务器和客户端都持有对应的公钥和私钥！
双方都是用非对称加密，其实就是客户端和服务器都有对应的公钥和私钥！
加密的时候，使用对方给的公钥进行加密，这就意味着，只有对方能够解密！
但是，其实这里还是要说：
1.双边都使用非对称，并没有解决效率问题！反而效率更低了，因为非对称加密本来就慢！
2.其实上面还是会存在安全问题的！
非对称 + 对称
我们需要先解决效率的问题！如果双方都使用非对称加密，效率会非常的低，那么，有没有什么办法能够解决效率问题呢？
答案是使用：非对称 + 对称来进行操作：
通过使用非对称 + 对称加密的方式，我们仅仅只需要再获取公钥和传输对称密钥的时候使用非对称加密的方式。一旦完成上述操作，后序都是使用对称加密！这大大提高效率！
效率问题是解决的不错了，但是，上面还是会存在着安全问题！
这里我们先不说安全问题，我们将放在后续的中间人攻击来进行详细讲解！
中间人攻击
上面我们提出了几个解决方法，即如何能够保障通信的双方的数据安全！
但是，第三第四种方法，存在着同一个安全问题！为了方便，我们以第四种方法来讲解。只要能明白第四种方法出现的安全问题，第三种自然能够理解！
而这里要理解的概念就是：
中间人攻击！其实就是通信的时候，我们的数据可能被别人用抓包工具抓到了！上述提及的四种方案，在面对中间人攻击的时候，还是会存在问题的！
问题如下：
我们需要假设，在通信双方还未就绪的时候，中间人就已经存在了：
这个条件是比较苛刻的，但是也确实有可能存在这种问题！
对于中间人来说，它必须想办法在客户端和服务器双方交换密钥的时候就拿到对应的密钥！要不然中间人做不到攻击！
所以，第三种方案——双方使用非对称加密，其实也存在这个问题！这里就不解释了！
所以，上述的那么多方案都不行，最后我们需要知道，到底问题出在哪里？
其实，问题就出在：客户端没办法保证自己拿到的公钥是合法的，就是服务器的！
所以，后续的解决方案就指向一个方面，即保障客户端的公钥是合法的！
终极方案——CA证书与签名
理解签名与验证
首先，我们需要理解签名和验证的概念，流程如上所示。
签名的人，我们暂且称为签名者。签名者拿着对数据摘要，并且进行加密！这个就叫做签名。然后，把数字签名和原始数据叠加在一起(就是物理意义上的拼接叠加)，这就形成了带有数字签名的数据。
验证的人，先暂且称为验证者。验证者可以接收到对应的带有数字签名的数据，把数字签名和有效数据分割开来。然后解密得到散列值，同时对有效数据做一次摘要！
我们知道：对于摘要的算法，只要数据有一点点改动，都会导致摘要的值大不相同！
所以，如果说，有效数据被篡改了，那么它做摘要得到的散列，必然和解密后的是不一样的！
验证就是验证有效数据的散列和解密后的散列是否一样！
CA机构
理解了数字签名，问题来了，谁是签名者呢？
答案是，全球范围内，存在着一个机构，即CA机构，他们来负责签名！
所有的服务器，不是说想上线到市场给用户用就能做到的！
只要服务器想使用HTTPS协议服务，就需要向 CA 机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性！
这个是一种规定！一般是当地或者附近一些部门会存在有CA机构信任的子机构，当一款产品需要上线的时候，第一件事情就是需要先获取CA证书！
当地的CA机构会对公司的业务、法人等相关信息进行审核！如果审核成功，该公司就需要提供服务器对应的公钥、域名等有效信息。
然后CA机构会生成一对公钥和私钥(假设为A和A’)，先对明文信息做摘要(服务器公钥、域名、有效时间等)，然后再对摘要加密，形成数字签名，形成一份证书，签发给服务方！
证书其实就是一个.csr文件，其中公钥会随着 CSR 文件，一起发给 CA 进行权威认证，私钥服务端自己保留，用来后续进行通信（其实主要就是用来交换对称秘钥）。
这里提供一个csr在线生成工具：https://myssl.com/csr_create.html
方案五——非对称加密 + 对称加密 + 证书认证
一旦服务器对应申请好了对应的CA证书，开发人员就会把对应的证书内置到服务器中！
所以，我们需要知道的是：
其实所谓的请求公钥，到现在来看，应该是客户端向服务器申请一份证书！这个证书包含了一系列与服务器相关的信息：
证书发布机构
证书有效期
公钥
证书所有者
签名
散列哈希算法
…
所以，客户端就拿到了对应的证书！证书中是带有CA机构的数字签名的！
那么，问题来了，客户端怎么使用对应的公钥来解密数字签名呢？
这里直接给结论：一般来说，操作系统中已内置的受信任的证书发布机构。所以，我们的浏览器(客户端)也是内置了对应的证书发布机构的公钥！这就可以进行解密了！
所以，客户端一旦拿到了对应的证书，就先对数字签名解密，得到一个散列值。
然后使用算法，对收到的数据进行哈希散列的获取，得到一个散列值。
然后，只需要对上述的两个散列值判等，就可以判断当前的数据是否遭篡改！一旦检测出数据被篡改了，直接丢弃，这样子就不会存在后续的通信了！
方案五的安全性
现在来思考一下这个方案的安全性，因为这个方案就是基于安全性来考量的。
1.中间人有没有可能篡改该证书？
可能，因为证书是明文(除了签名)！但是，一旦篡改证书，客户端做哈希散列的时候，就会发现和数据签名解密的值不一样！就认为收到的证书不合法了！
2.中间人有没有可能整个掉包证书？
中间人没有CA私钥，也就没办法修改对应的数字签名。就算修改了，客户端拿着CA的公钥解密的时候，会发现得到的结果根本就不认识！
所以，中间人只能去申请合法的证书，然后用自己申请的证书进行掉包。这个确实能做到证书的整体掉包，但是别忘记，证书明文中包含了域名等服务端认证信息，如果整体掉包，客户端依旧能够识别出来。总之就是，最后中间人的努力，还是没有任何用处！
所以，这个方案是在很大程度上是安全的！
当然，世界上没有绝对的安全，魔高一尺道高一丈，当新技术产生的时候，也可能不安全了！
对数据摘要签名的原因
缩小签名密文的长度,加快数字签名的验证签名的运算速度。
当然，直接对数据签名在技术上是一定能够实现的。只不过说，没有必要！因为需要效率！
如何成为中间人
ARP 欺骗：在局域网中，hacker经过收到 ARP Request广播包，能够偷听到其它节点的 (IP, MAC)地址。例， 黑客收到两个主机 A, B 的地址，告诉 B (受害者) ，自己是 A，使得 B 在发送给 A 的数据包都被黑客截取
ICMP 攻击：由于 ICMP 协议中有重定向的报文类型，那么我们就可以伪造一个ICMP 信息然后发送给局域网中的客户端，并伪装自己是一个更好的路由通路。从而导致目标所有的上网流量都会发送到我们指定的接口上，达到和 ARP 欺骗同样的效果
假 wifi && 假网站等
HTTPS的整体流程
HTTPS的整体流程如下图所示：
HTTPS 工作过程中涉及到的密钥有三组：
第一组(非对称加密): 用于校验证书是否被篡改.。服务器持有私钥(私钥在形成 CSR 文件与申请证书时获得), 客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器在客户端请求时，返回携带签名的证书. 客户端通过这个公钥进行证书验证, 保证证书的合法性，进一步保证证书中携带的服务端公钥权威性。
第⼆组(非对称加密): 用于协商生成对称加密的密钥. 客户端用收到的 CA 证书中的公钥(是可被信任的)给随机生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥。
第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密。