HTTPS原理大概是怎样的？
https比http多的，主要就是安全。那么，安全在哪儿了？
假如说，现在只有http协议，让你进行安全的数据传输，你怎么办？
当然是加密了，就是服务器和客户端商议好一个密钥，然后彼此之间传输数据的时候通过这个密钥进行加密和解密。当然了，这个密钥可以是固定的，但是这种情况下要么服务器密钥和加解密算法泄漏，要么客户端被破解密钥和加解密算法被泄漏。所以，进阶的办法就是让服务器和客户端之间进行密钥交换，比如这个密钥泄漏了，就换了。但是这样，依然还是有问题，就是既然交换密钥，就以为着密钥是明文在网上传来传去的，还是会被中间人给劫持掉。当然了，其实上面这个过程就是传说中的对称加解密技术。
那么，时候让非对称加解密技术表演真正的技术了！非对称加解密是靠一对公钥／私钥来解决问题，这里值得注意的是公钥和私钥是一对，公钥加密的数据只能靠私钥解密，私钥加密的数据只能靠对应的公钥解密。其中，私钥是必须得自己藏好了；公钥是给客户端使用的。如果说是app客户端，那么我们可以将公钥让客户端的开发人人员内置在客户端里，但是，客户端不也包括浏览器，那么，你总不能指望浏览器能自动集成收集这个世界上所有公司的产品的公钥吧？浏览器可以访问网站的时候，就从网站服务器上获取公钥啊。但是，一个绝大问题摆在我们面前，那就是非对称加解密 和 对称加解密 相比，性能相当差劲，差到什么份上？请查看这篇文章：https://t.ti-node.com/thread/6445811932803891201。
所以，怎么办呢？
所以有鸡贼的人就灵机一动，可以结合非对称和对称加密！大概意思是，客户端先通过获取公钥，然后再通过非对称加解密技术将对称加解密的密钥进行加密后传输，这样不就解决问题了？nice！
看起来这个流程已经很nice了，先通过浪费性能的非对称加解密交换对称加解密的密钥，然后后面的交互都采用性能很不错的对称加解密技术进行交互。但是，仔细一想，一旦有了获取公钥这个流程，因为获取公钥的过程是明文的，所以中间人可以劫持这个过程，直接给客户端发自己生成的公钥，继续实现劫持攻击！
所以，到这一步，问题的关键变成了如何防止公钥被调包。
于是，所谓的第三方机构的诞生了，什么是第三方机构，就是特么的靠替你安全放公钥赚钱的二道贩子而已。他们将你的产品的公钥写入到一种叫做证书的文件中，然后常年靠贩卖证书榨取资本买车买房。当然了，这年月，也有了像letsencrypt的良心资本家。你从二道贩子那里买证书和私钥，私钥你自己藏到裤裆里，证书就配置到你的nginx或者apache中，然后浏览器中就会出现那个绿色的小锁儿。那么，这样就安全了？
是的，基本上是靠谱了。因为这个二道贩子吧，不是随便一个人能干的了的，都是持证上岗的二道贩子，有组织有规模有纪律，我们只能选择信任。
那么，此时，当客户端和服务端进行交互的时候，从服务端获取到了证书，被中间人劫持了，中间人发给客户端自己伪造的证书，此时浏览器获取到伪造的证书后，会进行如下流程：
（下文中浏览器也可以更换为app，app也会从相应的安卓或者ios系统中获取内置好的证书）
1 首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验
2 浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发
3 如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。
4 如果找到，那么浏览器就会从操作系统中取出 颁发者CA 的公钥，然后对服务器发来的证书里面的签名进行解密
5 浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比
6 对比结果一致，则证明服务器发来的证书合法，没有被冒充
7 此时浏览器就可以读取证书中的公钥，用于后续加密了
有时候，一个网站在某个安卓系统上可以显示绿色笑锁子，但是在老版本安卓上就不行，就是因为老版本安卓没有内置这家二道贩子的信息，所以认为他们兜售的是假货，继而提醒你该网站不安全。
