目录
前言
在上一篇中，我们讲解了什么是HTTP，但是在实际应用中，浏览器和服务器之间很少使用HTTP协议来进行通信。
为什么有了HTTP协议不用，还要去使用HTTPS呢？
这是因为如果使用HTTP协议，那么浏览器和服务器在通信的时候，就是明文传输，只要黑客抓取到HTTP数据包，那么就可以获取到其中的数据，所以我们就需要对这个数据进行加密，因此就出现了HTTPS。
在这之前，我们来了解一些概念：
- 明文：没有经过加密的信息，即要传输的原始数据
- 密文：经过加密之后的信息。
- 密钥 ：进行加密和解密过程的重要道具。
- 加密：把明文通过密钥，生成密文。
- 解密：把密文通过密钥，还原成明文。
- 对称加密：加密和解密使用同一个密钥。
- 非对称密钥：一对密钥，一个叫公钥，一个叫密钥，使用一个加密，另一个解密。
为什么要使用HTTPS？
HTTPS协议的出现主要是为了解决HTTP协议在安全上的不足。
HTTPS主要由以下不足：
- 通信使用明文（不加密）,内容可能会被窃听；
- 不验证通信方的身份，因此有可能遭遇伪装；
- 无法证明报文的完整性，可能已经遭到篡改。
示例：
就像我和我的朋友通过写信来进行联系，那么我们每次写完信，就需要通过传信员来进行传递信息。如果我们不对信息进行加密的话，那么传信员就相当于中间人，可以打开查看信息，甚至修改信息。为了防止这种情况，我们就需要对信息进行加密，约定好加密的方式，从而来防止中间人看到甚至修改我们的信息。
以臭名昭著的运营商劫持事件为例
我们不管是公司、学校还是在家里，网络都是由运营商提供服务的，我们发送和接收信息，中间都需要经过运营商的。
假如我们现在要下载一款软件，那么我们在浏览器中找到对应的下载按钮后，点击按钮后就会弹出一个链接，那么我们就可以进行下载，但在中间我们的数据包可能会被运营商劫持并更换成别的软件的下载链接。
由于我们通过网络传输的任何数据报文都会经过运营商的网络设备（如交换机、路由器等），那么运营商的网络设备就可以解析出我们要传输的数据内容，并进行修改。
我们在点击“下载按钮”的时候，其实就是会给服务器发送一个HTTP请求来获取下载的连接，而获取到的HTTP响应就包含了该软件的下载链接，但如果被运营商劫持后，他就可能篡改HTTP响应中的下载链接，换成别的软件的下载连接。
当然，不止是因为这一个情况，还是为了保护用户的隐私，防止数据外漏或被修改，保证网站的安全性。
而HTTPS的出现正能够解决上述这些问题：
- 传输过程进行加密保护，防止内容被窃听；
- 利用证书来确定对方的身份，防止通信方伪装；
- 保证了报文的完整性，确保不会被篡改。
HTTPS是如果进行加密的
1.对称加密
对称加密就是在加密和解密的时候使用相同的密钥的加密方法，通信双方必须使用同一个密钥，这个密钥既可以用来解密 ，也能用来加密数据。
我们来举个例子，大家应该都或多或少看过一些古代/近代战争,在打战的时候，前线和指挥所之间都是通过通信兵来进行通信的，而通信兵在通信的过程中一般是骑马或者走路，这样是非常不安全，通信兵可能在传信的路途中遭遇意外，导致前线的战况不能及时送到指挥部，并且如果是把信息直接写在信纸上，可能也会被敌方进行篡改，从而传递错误的信息，严重可能导致打战失败。
针对这种传递速度慢且不安全的方法，人们发明出了电报，同时还有密码本，通过密码本，我们就能解密加密。当收到前线发来的电报，我们就能够根据密码本，来解密要传递的信息。当然，如果中间被敌军截取到电报信息，如果他们没有密码本，截取到也没有，不能够解密出其中的信息。
通信双方需要使用相同的密码本来进行加密解密。
在HTTPS中，“密码本”被称为“密钥”。通过密钥，发送方就可以将要发送的信息进行加密，当接收方在接收到信息后，就根据密钥来进行解密。
但这里存在一个问题，我们知道一个服务器一般都是为多个客户端服务的，那么多个客户端和服务器进行通信的时候，全部是使用相同的密钥吗？
显然不是，如果全部都使用相同的密钥，那加密也没用，只要黑客也搞个客户端访问，就能够知道密钥是啥了。
所以当客户端和服务器在建立连接的时候，就会事先协商好使用哪个密钥，而在建立连接的过程中，也是有可能被黑客截取到的，如果黑客截取到建立连接时的报文，那么就能够获取到密钥，这样客户端和服务器之间的通信就全部暴露在黑客眼中。
那可能就有人会说：再用一个对称密钥对密钥进行加密。这种方法其实是没用的，因为我们还是需要将这个对称密钥进行明文传递，这样黑客也能够截取到。
为了解决上面这种问题，就出现了非对称加密。
2.非对称加密
非对称加密使用一对密钥：一个公钥和一个私钥。公钥可以公开分享，但是密钥必须保密，用于解密数据。发送方使用接收方的公钥进行加密，而接收方使用自己的私钥来进行解密数据。例如RSA算法。
非对称加密的出现不是为了取代对称加密，而是为了：辅助。非对称加密的运算开销比较大，比较消耗性能。
在客户端和服务端进行通信前，服务端会先生成一对公钥-私钥，当客户端想要和服务器进行通信时，客户端会发起请求询问服务器：密钥是什么？ 服务器在接收到请求后，就会将公钥明文发送给客户端，当然在这个过程中，公钥被黑客截取到也没事，公钥是公开的。只有通过服务器的私钥对通过公钥加密的数据进行解密，才能获取到明文数据。而私钥只有服务器持有，不会外传，所以黑客就算公钥加密的数据，也不能进行解密。
那么有没有一种情况：就是当客户端生成的对称密钥，服务器已经在和另一个客户端在使用了，那么这个时候该怎么办呢？
能不能由服务器来生成一个对称密钥，然后再通过密钥进行加密发送给客户端？
这样是不行的,如果服务器使用私钥来对称密钥加密，那么当把数据包发送给客户端时，黑客就可以通过公钥来对这个数据包进行解密，从而拿到对称密钥，这样，后面客户端和服务器早通信的时候，就全部暴露在黑客眼中了。
所以对于上面这种情况，服务器就会返回一个数据包，来提示客户端：
"你生成的对称密钥我已经在和别的客户端在使用了，你重新生成个”。
客户端会在本地生成一个对称密钥，然后通过先前和服务器建立连接时获得的公钥来进行加密。就算在这个过程中被黑客截取到，他也解密不了，因为没有私钥。当服务器接收到客户端发送的加密报文后，就会通过私钥来解密获取客户端发送的对称密钥。当得到对称密钥之后，服务器会将协商好的对称密钥通过配对的密钥进行加密，返回给客户端，当客户端得到这个数据后就可以用公钥进行解密，得到协商好的对称密钥。当后面通信的时候，就使用这个对称密钥来进行加密通信。
上面这种 非对称加密+对称加密 的方式，就能够解决网络上所有黑客的攻击吗？肯定是不可以的，存在着 中间人攻击 问题。
中间人攻击
HTTPS是通过使用SSL/TLS对HTTP进行加密，来保护网络通信中的数据传输安全。然而，HTTPS协议其实也是会受到 中间人攻击 的。
中间人攻击（Man-in-the-Middle Attack,简称MITM），是一种会话劫持攻击。攻击者作为中间人，劫持通信双方会话并操纵通信过程，而通信双方并不知情，从而达到窃取信息或者冒充访问的目的。中间人攻击只是一个统称，具体的攻击方式有很多种，如Wi-Fi仿冒（钓鱼）、DNS欺骗、SSL劫持等。中间人攻击常用于窃取用户登录凭据、电子邮件和银行账户等个人信息，是对网银、网游等在线系统极具破坏性的一种攻击方式。
假如客户端向服务器发送请求，询问服务器：你的公钥public key1是什么啊？
如果在这个过程中，黑客截取到了客户端要发送给服务器信息，那么黑客其实也可以生成自己的一对公钥 public key2和私钥 private key2。黑客会根据客户端请求中的服务器地址，向该服务器发送请求：你的公钥public key1是什么啊？
当服务器接收到请求后，就会将生成的公钥public key1返回给客户端，当然，返回的时候会被黑客截取到，那么黑客就可以获取到服务器的公钥public key 1。然后将自己生成的public key2 返回给客户端；
当完成以上的步骤后，那么接下来，客户端就会使用公钥pub2来对 对称密钥66666 进行加密，再发给服务器，但这个过程中会被黑客截获到，黑客会使用私钥pri2来对请求密文进行解密，获取到其中的对称密钥66666 ，再根据服务器发来的公钥pub1 来对对称密钥进行加密，发送给服务器。
当服务器接收到来自客户端的请求密文（被黑客修改过的），就会给客户端返回响应密文。当然，黑客会先获取到响应密文进行解密，再根据pri2来对获进行加密发送给客户端。客户端在接收到响应密文后，会使用pub2来对响应密文进行解密，从而确定了双方通信时使用的对称密钥是什么。
完成上述步骤，黑客就能够知道客户端和服务器之间通信使用的对称密文。在后面客户端和服务器进行加密通信的时候，由于黑客已经知道了密钥，客户端和服务器之间的通信内容就全部暴露在黑客眼中，当然，客户端和服务器并不知情。
那么，为了解决上述这种中间人攻击问题，靠自证是不可能的，所以我们需要用到第三方作为“公证机构”来证明这对密钥是否是黑客黑客伪造的。
那么这个证明密钥是否是由黑客伪造的公证机构就称为证书。
3.证书
HTTPS中的证书是由受信任的第三方认证机构(CA)颁发的数字证书，用于验证服务器身份和安全性。服务端在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里包含有证书申请者信息、公钥信息、厂商、有效期、数字签名等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行，证书就相当于身份证，证明服务端公钥的权威性。
证书内容：
一个标准的X.509格式的数字证书通常包括以下信息：
- 实体的身份信息（如名称、电子邮件地址等）；
- 公钥；
- 签发证书的CA的信息；
- 有效期；
- 序列号；
- 使用的签名算法；
- 数字签名
当客户端向服务器建立连接的时候，客户端不会向服务器请求公钥，而是会向服务端索要证书，证书必须是“公正机构”，其是使用非对称加密的，“公正机构”会有私钥，通过私钥对证书进行加密，当客户端通过配对的公钥获取到这个证书之后，会对证书进行校验和运算（防止证书是伪造的）。
- 判定证书的有效期是否过期
- 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
- 验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到一个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对比 hash1 和 hash2 是否相等.如果相等, 则说明证书是没有被篡改过的.
客户端验证数字签名
1.客户端把证书中的各个字段,再算一次校验和,得到 checksum1
2.客户端使用公正机构的公钥,对数字签名进行解密,得到 checksum2
3.对比 checksum1 == checksum2 如果相等,视为当前证书的各个字段,就是和服务器这边发出来的证书是一模一样的,此时就可以认为这是合法证书.
如果不相等,意味着证书上的内容,被中间的黑客篡改过了~~ 此时浏览器往往就会弹出警告页面,提示用户,该网站不安全。
中间人有没有可能篡改证书？
- 由于中间人没有CA机构的私钥，所以无法hash之后使用私钥加密形成签名，那么也就没有办法对篡改之后的证书形成匹配的签名
- 如果强行篡改，客户端在收到该证书之后，会发现明文和签名解密后的值不一样，则说明证书已经被篡改过了，证书不可信，从而终止与服务器之间的通信，防止信息泄露给中间人。
中间人有没有可能整个调包证书？
- 因为中间⼈没有CA私钥，所以⽆法制作假的证书(为什么？)
- 所以中间⼈只能向CA申请真证书，然后⽤⾃⼰申请的证书进⾏掉包
- 这个确实能做到证书的整体掉包，但是别忘记，证书明⽂中包含了域名等服务端认证信息，如果整体掉包，客⼾端依旧能够识别出来。
- 永远记住：中间⼈没有CA私钥，所以对任何证书都⽆法进⾏合法修改，包括自己的。
以上就是本篇所有内容咯~
若有不足，欢迎指正~