秒懂HTTPS接口(原理篇)

前言

讲HTTPS之前,我们先来回顾一下HTTP协议。HTTP是一种超文本传输协议,它是无状态的、简单快速的、基于 TCP 的可靠传输协议。

既然 HTTP 协议这么好,那为什么又冒出来了一个 HTTPS 呢?HTTP本身不具备加密的功能,所以也就无法做到对通信整体内容进行加密, 也就是说HTTP是明文传输的,这就造成了很大的安全隐患。在网络传输过程中,只要数据包被人劫持,那你就相当于赤身全裸的暴露在他人面前,毫无半点隐私可言。想象一下,如果你连了一个不可信的WIFI,正好有使用了某个支付软件进行了支付操作,那么你的密码可能就到别人手里去了,后果可想而知。

网络环境的就是这样,给你带来便利的同时,也到处充满了挑战与风险。对于小白用户,你不能期望他有多高的网络安全意识,产品应该通过技术手段,让自己变得更安全,从源头来控制风险。这就诞生了HTTPS协议。

HTTPS简介

因为HTTP是明文传输,所以造成了安全隐患。如何让数据传输以加密的方式进行,就消除了该隐患。而SSL/TSL提供认证和加密处理及摘要功能。 为了统一解决上述的问题,需要在HTTP上加密处理和认证等机制。我们把添加了加密和认证机制的HTTP称为HTTPS。

HTTPS并非是应用层的一种新协议,只是通信接口部分用SSL/TLS协议代替而已。 所谓的HTTPS,简单理解就是身披SSL/TLS协议壳的HTTP。

从网络的七层模型来看,原先的四层 TCP 到七层 HTTP 之间是明文传输,在这之间加一个负责数据加解密的传输层(SSL/TLS),保证在网络传输的过程中数据是加密的,而HTTP接收到的依然是明文数据,不会有任何影响。

SSL是Netscape开发的专门用户保护Web通讯的,目前版本为3.0。最新版本的TLS 1.0是IETF(工程任务组)制定的一种新的协议,它建立在SSL 3.0协议规范之上,是SSL 3.0的后续版本。两者差别极小,可以理解为SSL 3.1,它是写入了RFC的。

HTTPS实现原理

大致原理

通过上面的介绍,对HTTPS有了大致的了解。可本质问题还没说,HTTPS是如何实现数据的加密传输?

首先,先来了解下加密算法的方式,常用的有两种:对称加密与非对称加密。

  • 对称加密:即通信双方通过相同的密钥进行信息的加解密。加解密速度快,但是安全性较差,如果其中一方泄露了密钥,那加密过程就会被人破解。
  • 非对称加密:相比对称加密,它一般有公钥和私钥。公钥负责信息加密,私钥负责信息解密。两把密钥分别由发送双发各自保管,加解密过程需两把密钥共同完成。安全性更高,但同时计算量也比对称加密要大很多。

技术细节

对于网络通信过程,在安全的前提下,还是需要保证响应速度。如何每次都进行非对称计算,通信过程势必会受影响。所以,人们希望的安全传输,最终肯定是以对称加密的方式进行。

首先 Session Key是如何得到的,并且在 Session Key之前的传输都是明文的。Session Key通过网络传输肯定不安全,所以它一定各自加密生成的。因此在这之前,双方还要互通,确认加密的算法,并且各自添加随机数,提高安全性。

这样双方确认了使用的 SSL/TLS 版本,以及生成 Session Key的加密算法。并且双方拥有了2个随机数(客户端、服务端各自生成一个)。可是如果按照目前的随机参数,加上加密算法生成Session Key呢,还是存在风险,加密算法是有限固定的,而且随机数都是明文传输的,有被截获的可能。

让加密算法变得不可预测,可能性不大。那么能否再传输一个加密的随机数,这个随机数就算被截获,也无法破译。这就用到了非对称加密算法,我们在步骤二中,把公钥传输给客户端。这样客户端的第三个随机数用公钥加密,只有拥有私钥的服务端才能破译第三个参数,这样生成的 Session 就是安全的了。

看似完成了,现在生成的 Session Key 是不可预测的(就算被截获也无所谓),我们可以放心的进行私密通信了。真的是这样吗?我们似乎对服务端给的公钥十分信任,如果你目前通信的本身就不可信,或者被中间人劫持,由它发送伪造的公钥给你,那后果可想而知,这就是传说中的“中间人攻击”。

所以,我们得包装一下公钥,让它变得安全。这就引出了数字证书的概念,数字证书由受信任的证书机构颁发,证书包含证书文件与证书私钥文件。私钥文件由服务端自己保存,证书文件发送给请求的客户端,文件包含了域名信息、公钥以及相应的校验码。客户可以根据得到的证书文件,校验证书是否可信。

通俗的表示整个流程如图:

证书示例:

Extended Validation(EV):该级别的证书具有最高的安全性,也是最值得信任的。它除了给出更详细的公司/组织信息外,还在浏览器的地址栏上直接给出了公司名称。

示例:https://www.github.com

小故事

如果上面的技术细节没怎么看太懂?来,我们来讲个故事。

我们在网络的行为(例如看浏览、上传图片、聊天),简单来说都是向服务器发送消息、接收服务器的消息,这个过程很像信鸽传书。 为了更加形象,我们把通信过程中的主要角色服务器、客户端、黑客的称呼也替换一下,小服、小客、小黑。 如小客想给小服发送信息,那么她就把信绑在信鸽腿上,放出信鸽,小服接到信鸽,拿到信纸读消息,这个过程就完成了,很不错,简单方便。 但是,坏人小黑出现了,他把正在愉快飞翔的信鸽抓了下来,并把信给换了,这就麻烦了,小服得到了假消息。 这就是 HTTP 的沟通方式,方便但极不安全,不能传递重要信息。

但是小服小客很聪明,想到了一个好办法,他们设定了一套编码规则:把字母偏移3个位置,例如,D → A、E → B、F → C,这样,原本的消息“secret message” 就变成了 “pbzobq jbppxdb”。 小黑截获到消息后就会一脸懵逼,看不懂改不了,但是小服知道解码规则,可以轻松转化成原文。 这个方式就是“对称式加密”。

对称式加密很安全,只要保护好key,别让其他人知道即可,但也有个问题,如果小服小客在通信之前不认识,他们就没办法设定加密规则。 为了解决这个问题,通信方式又一次升级了,比如小客向给小服发送信息,他们的通信流程如下:

  1. 小客让信鸽飞到小服那儿,但啥也没带,没有信息。
  2. 小服让信鸽带着一个箱子和一把开着的锁飞回到小客小服自己留着锁的钥匙。小服让信鸽带着一个箱子和一把开着的锁飞回到小客小服自己留着锁的钥匙。
  3. 小客把信放到箱子里,并用锁把箱子锁上,让信鸽把箱子带给小服小客把信放到箱子里,并用锁把箱子锁上,让信鸽把箱子带给小服
  4. 小服收到箱子,用钥匙开锁,拿到信
  5. 这样小黑就没招儿了,小服小客可以愉快的通信了。这样小黑就没招儿了,小服小客可以愉快的通信了。

这个方式就是“非对称加密”,这个箱子就是公钥,开锁的钥匙就是私钥

细想一下,有个问题,小客怎么确认箱子来自小服而不是小黑呢?为此,小服决定给箱子签个名,小客收到后先检查一下签名就可以确认了。 但这样还不够稳妥,小服决定让最权威的小明来签名,小明是干啥的?他非常有名望,是个绝对值得信赖的家伙,他的签名大家都认,小明就是大名鼎鼎的 CA(Certification Authority)。 小服小明建立了合作,小明收到小服的请求就会为她签名,而小黑是得不到小明小客的签名的,这样小服就可以放心了。 这就是HTTPS的通信通俗原理了,是不是很好理解。

我们可以看到 HTTPS 比 HTTP的流程重了很多,有个箱子,还有签名,还增加了往返过程,性能肯定有所影响,这一切都是为了安全,所以我们要根据自己的需求场景来选择什么时候使用 HTTPS,什么时候使用 HTTP。

参考文献:

[1]上野宣,于均良译.图解HTTP.北京:人民邮电出版社,2014

[2]https://github.com/jasonGeng88/blog/blob/master/201705/https.md

本文分享自微信公众号 - 7DGroup(Zee_7DGroup)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-12-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券