程序员

梳理一下HTTPS

2018-05-29  本文已影响9人  单调先生

最近经历了一波波的面试,也遭遇了一波波的虐心,没错我就是这么菜……,但收获也是很大的,起码扫荡了近半年来心里的迷茫,成长蛮多的。嗯……废话好像讲多了,从这篇开始讲解面试中遇到了一些有意思的事情,现在进入主题,理解HTTPS

什么是HTTPS?

可以这么来说

HTTPS协议 = HTTP协议 + SSL/TLS协议

也就是说HTTPS本质上用来传输的还是HTTP协议,不同的点(也是特别的)在于在经过应用层的HTTP协议之后,还在另一层做了SSL/TLS套接,将传输的报文进行加密/解密,用以确保安全性,下图助于理解 HTTPS

为什么要用HTTPS?

这个比较好理解,最终目的就一个——安全。谁都不想自己的信息轻易被人拦截,也不想自己请求的网页被人篡改甚至加一些不知名的小广告。而传统的HTTP协议是以明文进行传输的,明文的意思就是不加密,在传输过程中很容易就被中间服务器或路由拦截、篡改数据包,这就导致了我上面举例的两种情况的发生。总结来讲使用HTTP协议有以下缺点:

怎么确保安全性?

上面哔哔了那么多,无非就为了说明HTTPS的安全性很牛,那么问题来了,怎么确保安全性呢?如果像我一样笼统的讲什么SSL/TLS套接层啦、加密解密啦就显得太肤浅了,继续问下去就会被发现装的X无所遁形,原形毕露(是的,我一片空白的尴尬),接下来就好好讲讲是怎么一步步确保安全性的。

对称加密算法

对称加密算法很简单,加密/解密双方只要拥有同一秘钥即可完成加密/解密的过程。这个算法比较符合我们常见的思维,日常生活中房东和我都有同一把锁的钥匙,我们都可以对我的房子进行上锁和解锁(当然,房东不可以私自进入我的领地)。经过对称加密算法后,只有拥有同一秘钥的才能对信息加解密,确保了一定的安全性,但这里也引发了另一个问题,秘钥如何传输?秘钥需要传输才能使双方进行通信,但秘钥的传输如果用明文则很容易被人截取,用加密吗?似乎陷入了一个死循环,但大牛们想出了以下算法

非对称加密算法

一般讲非对称加密算法指的都是RSA,RSA算法基于一个简单的数理理论:

将两个大素数相乘十分容易,但是想要对其乘积进行因式分解却极其困难,因此可以将乘积公开作为加密密钥

通过RSA算法可以得出下面的规则,通讯的双方各有一套公钥和私钥,同一套公钥和私钥中公钥的加密需要私钥才能解密,私钥的加密需要公钥才能解密。举个例子,A把自己的公钥公开,B拿到了A的公钥,然后用A的公钥加密数据包发送回给A,A再用自己的私钥解密就得到了明文。在这个过程中任何第三方拦截了信息都没法破解,有了这个算法之后安全性就有了保障。

非对称加密算法

嗯……这里有个需要注意的地方,非对称加密算法的加密/解密时间会比较长(相对来讲),所以不能用于数据量较大的信息传递,所以直接传要发送的数据信息是不行的,只能用于对称算法秘钥的传递

不完美——中间人攻击

嗯,一山还有一山高,非对称加密算法够绝了,但有人想出更绝的方法——中间人攻击。通过上面的描述,我们知道非对称加密中双方的公钥都是公开的,并没有任何证据可以证明公钥属于A还是B,这个时候中间人M出现了,M采取了某些手段在A和B通信过程中成为中间人。在A向B通信的时候,A要拿到B的公钥加密信息,这个时候中间人M谎称自己的公钥是B的公钥,于是A拿M的公钥加密了信息传递出去,这时候M拿到了信息并用自己的私钥解密信息,随后再用B的公钥加密发送给了B。在这个过程中A和B以为通信绝对安全,但实际上早就被M拿到了信息明文,整个过程堪称完美。至于M是如何中间人的,实际上是另外一个安全问题了。这里的关键是只要M让A相信公钥是B的,就可以做中间人攻击。

中间人攻击

CA——第三方认证机构

为了让中间人M不再得逞,就需要解决一个问题——证明公钥属于谁,于是出现了第三方认证机构。第三方认证机构要做的事情简单来讲就一个,确保A拿到的公钥真正属于B,而非其它浑水摸鱼的中间人M。至于CA要怎么做,就涉及到另一个概念——数字证书
讲数字证书前我们先来讲讲日常生活中的普通证书,普通证书的作用就是证明,比如身份证证明公民身份、CET-4证书证明英语能力(好吧我没有)。而产生这些证书的条件就是通过登记个人信息或通过某项测试,第三方权威部门将信息证明无误后盖个章、录入系统之类的,这就算认证过了,然后个人就可以用这个证书从事各类证明活动。
数字证书同理,不过与现实世界不同的是,在互联网上完成一个完整的验证过程,要考虑的事情会更多一些。举例以下几个方面:

一次完整的HTTPS通信

HTTPS通信
上一篇下一篇

猜你喜欢

热点阅读