烦恼数个月,终于彻底搞懂https原理

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

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

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

基础知识铺垫

虽然我们不一定是专门搞密码学的,但多多少少还是要知道一点的。不然的话,接下来的知识可能无法理解。
1、对称加密算法:加密和解密使用相同的密钥。
2、非对称加密算法:加密和解密使用不同的密钥,一个成为公钥,另一个则是私钥,两者是成对的。公钥用来加密,私钥用来解密。
备注:https原理中,这两种算法都用到了。至于其他加密算法,咱就不多说了。

http传输原理

(其实呢,浏览器和服务器之间信息传输并不是直接的,中间还会有个中间路由。)
烦恼数个月,终于彻底搞懂https原理_第1张图片

解释一下http到底不安全在哪里
烦恼数个月,终于彻底搞懂https原理_第2张图片
正如图中所看到的,如果有人通过中间路由恶意篡改传输的信息,那会怎样?浏览器接收到的信息都被篡改了,后果不堪设想。
https因此诞生。在http基础上加上了SSL/TLS协议。就是为了防止以上的这种情况。

思维风暴:

试想,如果是我们,我们会怎么处理这种情况呢?跟着这个思维走下去,你便会提现到这种思维的魅力
首先,我们很自然地会想到,信息在传输期间进行加密,浏览器和服务器那边再进行解密。这样的话,即使监听者得到了这些信息,他也无法进行解密。这样便安全了。

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

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

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

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

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

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

最后一个问题,服务器端的公钥和私钥怎么来的呢?
这便诞生出了CA机构。
CA机构专门给网站服务器端添加公钥和私钥(就是所谓的数字签名证书),当然还有一些其他的信息,比如网站域名、证书有效期等。
还有一点要说明一下,浏览器是如何验证公钥的?
浏览器得到服务器发送的公钥后,会和系统内置的证书进行比对便可验证真假了。
烦恼数个月,终于彻底搞懂https原理_第3张图片

总结:

https原理:

烦恼数个月,终于彻底搞懂https原理_第4张图片

1、浏览器给服务器发送一个http请求,得到公钥。
2、将公钥和系统内置证书进行对比,并验证有效期,然后生成一个随机浏览器密钥并使用公钥加密,接着再发送一个http请求。
3、服务器接收到用公钥加密的浏览器密钥后,使用私钥进行解密。
4、接下来传输便通过浏览器密钥进行加密解密。即使监听者通过中间路由接收到了信息,也无法解密,恶意篡改的话,浏览器和服务器端会识别到,中断连接。这样的话,便安全了。

怎么升级到https?

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

知识在于分享传播,在分享传播的过程中,会逐步进行凝练和升华!
原文: https://www.cnblogs.com/ywjbokeyuan/p/13533208.html

你可能感兴趣的:(https)