彻底搞懂https原理

我终于彻底理解了https原理！！！激动之下，写一篇博客，搞一波分享！！！

本篇博客比较精彩的地方：

思维方式：也是借鉴一位大佬的，写得很棒。https://blog.csdn.net/guolin_blog/article/details/104546558

图文并茂，简单明了，化繁为简。

关于https原理，有非常非常多的博客，然而其中很多博主都不一定完全理解，只是单纯地为了写博客而写博客。

基础知识铺垫

虽然我们不一定是专门搞密码学的，但多多少少还是要知道一点的。不然的话，接下来的知识可能无法理解。

1、对称加密算法：加密和解密使用相同的密钥。

2、非对称加密算法：加密和解密使用不同的密钥，一个成为公钥，另一个则是私钥，两者是成对的。公钥用来加密，私钥用来解密。

备注：https原理中，这两种算法都用到了。至于其他加密算法，咱就不多说了。

http传输原理

（其实呢，浏览器和服务器之间信息传输并不是直接的，中间还会有个中间路由。）

解释一下http到底不安全在哪里



正如图中所看到的，如果有人通过中间路由恶意篡改传输的信息，那会怎样？浏览器接收到的信息都被篡改了，后果不堪设想。

https因此诞生。在http基础上加上了SSL/TLS协议。就是为了防止以上的这种情况。

思维风暴：

试想，如果是我们，我们会怎么处理这种情况呢？跟着这个思维走下去，你便会提现到这种思维的魅力

首先，我们很自然地会想到，信息在传输期间进行加密，浏览器和服务器那边再进行解密。这样的话，即使监听者得到了这些信息，他也无法进行解密。这样便安全了。

那又有问题了，以上这种加密便是采用的对称加密，那密钥怎么得到呢？

我们知道，浏览器一开始是向服务器发送请求的，那密钥必定是浏览器发给服务器的。这样的话，监听者还是可以通过中间路由得到这个密钥，然后通过密钥进行解密，治标不治本。或者直接随便恶意篡改这个密钥，后果可想而知。那怎么办呢？

我们可能也很自然地想到，如果把浏览器发给服务器的密钥进行加密，不就可以了吗？这样的话，的确解决了问题。

把浏览器发给服务器的密钥进行加密，我们很自然地会想到，使用非对称加密算法便可以实现。那怎么做到这一点呢？

这也是个计算机届的难题，卡在这儿，走不下去了。

某一天，某个天才突然想到了，浏览器给服务器发送一个请求。打破常规，如果请求两次呢？第一次只请求公钥，得到公钥后，浏览器生成一个密钥（这里称作浏览器密钥），使用公钥进行加密，第二次请求附带上使用公钥进行加密的浏览器密钥，服务器接收后，使用私钥进行解密不就得到了浏览器密钥吗？接下来，传输信息，只需通过浏览器密钥进行加密解密不就成了。这样的话，问题不就解决了吗？的确如此。

最后一个问题，服务器端的公钥和私钥怎么来的呢？

这便诞生出了CA机构。

CA机构专门给网站服务器端添加公钥和私钥（就是所谓的数字签名证书），当然还有一些其他的信息，比如网站域名、证书有效期等。

还有一点要说明一下，浏览器是如何验证公钥的？

浏览器得到服务器发送的公钥后，会和系统内置的证书进行比对便可验证真假了。

总结：

https原理：

1、浏览器给服务器发送一个http请求，得到公钥。

2、将公钥和系统内置证书进行对比，并验证有效期，然后生成一个随机浏览器密钥并使用公钥加密，接着再发送一个http请求。

3、服务器接收到用公钥加密的浏览器密钥后，使用私钥进行解密。

4、接下来传输便通过浏览器密钥进行加密解密。即使监听者通过中间路由接收到了信息，也无法解密，恶意篡改的话，浏览器和服务器端会识别到，中断连接。这样的话，便安全了。

怎么升级到https？

将http升级到https，比较简单，购买SSL证书，然后将证书安装到网站服务器端即可。一般而言，购买SSL证书的话，第一年是免费的，然后每年差不多要4k左右。（还挺贵的。。。）当然了，http升级到https，网站访问速度要稍微降低一些的，毕竟有个加密解密的过程嘛！

知识在于分享传播，在分享传播的过程中，会逐步进行凝练和升华！