HTTPS(超文本传输安全协议)是如何运作的

很早以前就想写一篇这样的博客了,借着最近复习网络知识的契机,来做一些总结。

早期的HTTP协议,是不要求加密的,因此就会出现各种强加广告的现象,随便浏览一些网页都会被莫名其妙硬塞一大堆浮窗广告信息。我记得我刚开始写博客的第一年,每次打开网站都指不定有什么广告弹窗出现在右下角,用户体验十分差。随着技术的进步,HTTP2开始要求大家要使用SSL/TLS才能接入,浏览器也逐渐将没有HTTPS的网站标记成不安全的网站。那么HTTPS是如何解决这些问题的呢?又是如何加密的呢?

要知道,HTTP协议由于是明文传输数据的,所以会导致出现中间人攻击的现象,当你浏览网页的时候,数据包从服务器传回浏览器的过程中经过的各个节点的主机,都能获知你访问的数据,甚至直接篡改数据,加入一段弹窗广告代码再继续传输。为了将数据进行加密,HTTP协议在下层加入了一层安全套接层(SSL),随着SSL的更新,SSL3.0之后就更名为了TLS,因此我们所说的SSL和TLS其实是一个东西。

加密最优秀的方法就是采用非对称加密,但是HTTPS之所以没有采用非对称加密的方案,是因为非对称加密是非常耗时间的事情,加密解密的时间将会严重影响性能和体验。

HTTPS采用每次产生新连接时就生成一个随机值以用于对称加密。但这个随机值总归是应该在服务器和浏览器之间进行一次传输,才能使得双方拥有同一个密钥(即随机值)来解密,因此如何确保随机值在传输过程当中不被泄露就变成了新的问题。

解决方法也不难,可以采用非对称加密传输一次该随机值。过程就是在浏览器想要发起请求时,先向服务器发起一次索要公钥的请求,服务器将公钥以明文传输给浏览器,浏览器接收到之后,将随机值用公钥进行加密,之后把数据发送给服务器, 这样就能同步双方的密钥(即随机值)。

这个做法有问题吗?思考一下上述的中间人攻击在这里是不是也能适用,假设服务器为A,中间人为B,浏览器为C,当C向A发起请求时,B劫持了A的公钥,并把自己的公钥发给了A,如此一来,A的随机值就共享给了B,而B会新建一个新的随机值共享给C,这样B就完完全全成为了一个中间人,而双方都没法发现这个事情。

那么这个问题的实质是什么?实际上就是浏览器没法验证所接收到的公钥是否来自于自己请求的服务器。为了解决这个问题,需要引入第三方公信机构,也就是我们所熟知的CA机构。CA机构为服务器颁发证书,该证书包含了域名持有者的信息和公钥等信息。当服务器把证书传输给浏览器时,浏览器可以根据证书所颁布的CA机构是否可信,来确定要不要信任该证书,一旦选择信任该证书,就可以从里面获取公钥完成接下来的数据传输。

到此,问题就转化为如何确保证书不被中间人所篡改。流程大致如下:

首先CA将证书内的信息P进行一次hash,得到串H,再用自己的私钥把S进行加密得到S,将P和S连接起来形成服务器的证书。当有浏览器向服务器发起请求时,服务器先把证书传给浏览器,浏览器只需要把信息P重新进行一次hash得到H1,再使用浏览器内置的该CA机构的公钥,对S进行解密得到H2,最后再将H1和H2比较一下,如果相同就信任该证书进行下一步数据传输,如果不同则终止进一步传输数据。

回顾一下,为什么现在中间人攻击不适用了?本质上在于,中间人没法使用CA机构的密钥对自己篡改后的数据进行加密,且没法伪造一个受浏览器信任的公钥与私钥。一旦中间人篡改了数据,那么H就会随改变,信息S理论上也应该随之改变才能篡改成功,但信息S因为中间人无法破解,所以也就无法伪造一张假证书,由此也就产生了一条安全的通信链路。

-- 热度:69 ℃
-- 于 共写了1465个字
-- 文内使用到的标签:

评论已关闭。