https协议那些事

一、什么是HTTPS
在说HTTPS之前先说说什么是HTTP,HTTP就是我们平时浏览网页时候使用的一种协议。HTTP协议传输的数据都是未加密的,也就是明文的,因此使用HTTP协议传输隐私信息非常不安全。为了保证这些隐私数据能加密传输,于是网景公司设计了SSL(Secure Sockets Layer)协议用于对HTTP协议传输的数据进行加密,从而就诞生了HTTPS。SSL目前的版本是3.0,被IETF(Internet Engineering Task Force)定义在RFC 6101中,之后IETF对SSL 3.0进行了升级,于是出现了TLS(Transport Layer Security) 1.0,定义在RFC 2246。实际上我们现在的HTTPS都是用的TLS协议,但是由于SSL出现的时间比较早,并且依旧被现在浏览器所支持,因此SSL依然是HTTPS的代名词,但无论是TLS还是SSL都是上个世纪的事情,SSL最后一个版本是3.0,今后TLS将会继承SSL优良血统继续为我们进行加密服务。目前TLS的版本是1.2,定义在RFC 5246中,暂时还没有被广泛的使用。


二、HTTPS到底安全吗?
这个答案是肯定的,很安全。谷歌公司已经行动起来要大力推广HTTPS的使用,在未来几周,谷歌将对全球所有本地域名都启用HTTPS,用户只要在搜索前用Google帐号登录,之后所有的搜索操作都将使用TLS协议加密


三、HTTP 和 TCP 之间的关系

简单地说,TCP 协议是 HTTP 协议的基石——HTTP 协议需要依靠 TCP 协议来传输数据。在网络分层模型中,TCP 被称为“传输层协议”,而 HTTP 被称为“应用层协议”。有很多常见的应用层协议是以 TCP 为基础的,比如“FTP、SMTP、POP、IMAP”等。
TCP 被称为“面向连接”的传输层协议。关于它的具体细节,俺就不展开了(否则篇幅又失控了)。你只需知道:传输层主要有两个协议,分别是 TCP 和 UDP。TCP 比 UDP 更可靠。你可以把 TCP 协议想象成某个水管,发送端这头进水,接收端那头就出水。并且 TCP 协议能够确保,先发送的数据先到达(与之相反,UDP 不保证这点)。

HTTP 对 TCP 连接的使用,分为两种方式:俗称“短连接”和“长连接”(“长连接”又称“持久连接”,洋文叫做“Keep-Alive”或“Persistent Connection”)
假设有一个网页,里面包含好多图片,还包含好多【外部的】CSS 文件和 JS 文件。在“短连接”的模式下,浏览器会先发起一个 TCP 连接,拿到该网页的 HTML 源代码(拿到 HTML 之后,这个 TCP 连接就关闭了)。然后,浏览器开始分析这个网页的源码,知道这个页面包含很多外部资源(图片、CSS、JS)。然后针对【每一个】外部资源,再分别发起一个个 TCP 连接,把这些文件获取到本地(同样的,每抓取一个外部资源后,相应的 TCP 就断开)
相反,如果是“长连接”的方式,浏览器也会先发起一个 TCP 连接去抓取页面。但是抓取页面之后,该 TCP 连接并不会立即关闭,而是暂时先保持着(所谓的“Keep-Alive”)。然后浏览器分析 HTML 源码之后,发现有很多外部资源,就用刚才那个 TCP 连接去抓取此页面的外部资源。

在 HTTP 1.0 版本,【默认】使用的是“短连接”(那时候是 Web 诞生初期,网页相对简单,“短连接”的问题不大);
到了1995年底开始制定 HTTP 1.1 草案的时候,网页已经开始变得复杂(网页内的图片、脚本越来越多了)。这时候再用短连接的方式,效率太低下了(因为建立 TCP 连接是有“时间成本”和“CPU 成本”滴)。所以,在 HTTP 1.1 中,【默认】采用的是“Keep-Alive”的方式。


四、HTTPS的工作原理
HTTPS在传输数据之前需要客户端(浏览器)与服务端(网站)之间进行一次握手,在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议不仅仅是一套加密传输的协议,更是一件经过艺术家精心设计的艺术品,TLS/SSL中使用了非对称加密,对称加密以及HASH算法。握手过程的简单描述如下:
1.浏览器将自己支持的一套加密规则发送给网站。
2.网站从中选出一组加密算法与HASH算法,并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址,加密公钥,以及证书的颁发机构等信息。
3.获得网站证书之后浏览器要做以下工作:
a) 验证证书的合法性(颁发证书的机构是否合法,证书中包含的网站地址是否与正在访问的地址一致等),如果证书受信任,则浏览器栏里面会显示一个小锁头,否则会给出证书不受信的提示。
b) 如果证书受信任,或者是用户接受了不受信的证书,浏览器会生成一串随机数的密码,并用证书中提供的公钥加密。
c) 使用约定好的HASH计算握手消息,并使用生成的随机数对消息进行加密,最后将之前生成的所有信息发送给网站。
4.网站接收浏览器发来的数据之后要做以下的操作:
a) 使用自己的私钥将信息解密取出密码,使用密码解密浏览器发来的握手消息,并验证HASH是否与浏览器发来的一致。
b) 使用密码加密一段握手消息,发送给浏览器。
5.浏览器解密并计算握手消息的HASH,如果与服务端发来的HASH一致,此时握手过程结束,之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。
这里浏览器与网站互相发送加密的握手消息并验证,目的是为了保证双方都获得了一致的密码,并且可以正常的加密解密数据,为后续真正数据的传输做一次测试。另外,HTTPS一般使用的加密与HASH算法如下:
非对称加密算法:RSA,DSA/DSS
对称加密算法:AES,RC4,3DES
HASH算法:MD5,SHA1,SHA256
其中非对称加密算法用于在握手过程中加密生成的密码,对称加密算法用于对真正传输的数据进行加密,而HASH算法用于验证数据的完整性。由于浏览器生成的密码是整个数据加密的关键,因此在传输的时候使用了非对称加密算法对其加密。非对称加密算法会生成公钥和私钥,公钥只能用于加密数据,因此可以随意传输,而网站的私钥用于对数据进行解密,所以网站都会非常小心的保管自己的私钥,防止泄漏。
TLS握手过程中如果有任何错误,都会使加密连接断开,从而阻止了隐私信息的传输。正是由于HTTPS非常的安全,攻击者无法从中找到下手的地方,于是更多的是采用了假证书的手法来欺骗客户端,从而获取明文的信息,但是这些手段都可以被识别出来

https协议具有以下特点

兼容性

因为是先有 HTTP 再有 HTTPS。所以,HTTPS 的设计者肯定要考虑到对原有 HTTP 的兼容性。
这里所说的兼容性包括很多方面。比如已有的 Web 应用要尽可能无缝地迁移到 HTTPS;比如对浏览器厂商而言,改动要尽可能小;……
基于“兼容性”方面的考虑,很容易得出如下几个结论:
1. HTTPS 还是要基于 TCP 来传输
(如果改为 UDP 作传输层,无论是 Web 服务端还是浏览器客户端,都要大改,动静太大了)
2. 单独使用一个新的协议,把 HTTP 协议包裹起来
(所谓的“HTTP over SSL”,实际上是在原有的 HTTP 数据外面加了一层 SSL 的封装。HTTP 协议原有的 GET、POST 之类的机制,基本上原封不动)

打个比方:如果原来的 HTTP 是塑料水管,容易被戳破;那么如今新设计的 HTTPS 就像是在原有的塑料水管之外,再包一层金属水管。一来,原有的塑料水管照样运行;二来,用金属加固了之后,不容易被戳破。

可扩展性

前面说了,HTTPS 相当于是“HTTP over SSL”。
如果 SSL 这个协议在“可扩展性”方面的设计足够牛逼,那么它除了能跟 HTTP 搭配,还能够跟其它的应用层协议搭配。岂不美哉?
现在看来,当初设计 SSL 的人确实比较牛。如今的 SSL/TLS 可以跟很多常用的应用层协议(比如:FTP、SMTP、POP、Telnet)搭配,来强化这些应用层协议的安全性。

接着刚才打的比方:如果把 SSL/TLS 视作一根用来加固的金属管,它不仅可以用来加固输水的管道,还可以用来加固输煤气的管道。

保密性(防泄密)

HTTPS 需要做到足够好的保密性。
说到保密性,首先要能够对抗嗅探(行话叫 Sniffer)。所谓的“嗅探”,通俗而言就是监视你的网络传输流量。如果你使用明文的 HTTP 上网,那么监视者通过嗅探,就知道你在访问哪些网站的哪些页面。
嗅探是最低级的攻击手法。除了嗅探,HTTPS 还需要能对抗其它一些稍微高级的攻击手法——比如“重放攻击”(后面讲协议原理的时候,会再聊)。

完整性(防篡改)

除了“保密性”,还有一个同样重要的目标是“确保完整性”。关于“完整性”这个概念,在之前的博文《扫盲文件完整性校验——关于散列值和数字签名》中大致提过。健忘的同学再去温习一下。
在发明 HTTPS 之前,由于 HTTP 是明文的,不但容易被嗅探,还容易被篡改。
举个例子:
比如咱们天朝的网络运营商(ISP)都比较流氓,经常有网友抱怨说访问某网站(本来是没有广告的),竟然会跳出很多中国电信的广告。为啥会这样捏?因为你的网络流量需要经过 ISP 的线路才能到达公网。如果你使用的是明文的 HTTP,ISP 很容易就可以在你访问的页面中植入广告。
所以,当初设计 HTTPS 的时候,还有一个需求是“确保 HTTP 协议的内容不被篡改”。

真实性(防假冒)

在谈到 HTTPS 的需求时,“真实性”经常被忽略。其实“真实性”的重要程度不亚于前面的“保密性”和“完整性”。
举个例子:
你因为使用网银,需要访问该网银的 Web 站点。那么,你如何确保你访问的网站确实是你想访问的网站?(这话有点绕口令)
有些天真的同学会说:通过看网址里面的域名,来确保。为啥说这样的同学是“天真的”?因为 DNS 系统本身是不可靠的(尤其是在设计 SSL 的那个年代,连 DNSSEC 都还没发明)。由于 DNS 的不可靠(存在“域名欺骗”和“域名劫持”),你看到的网址里面的域名【未必】是真实滴!
(不了解“域名欺骗”和“域名劫持”的同学,可以参见俺之前写的《扫盲 DNS 原理,兼谈“域名劫持”和“域名欺骗/域名污染”》)
所以,HTTPS 协议必须有某种机制来确保“真实性”的需求(至于如何确保,后面会细聊)。

性能

再来说最后一个需求——性能。
引入 HTTPS 之后,【不能】导致性能变得太差。否则的话,谁还愿意用?
为了确保性能,SSL 的设计者至少要考虑如下几点:
1. 如何选择加密算法(“对称”or“非对称”)?
2. 如何兼顾 HTTP 采用的“短连接”TCP 方式?
(SSL 是在1995年之前开始设计的,那时候的 HTTP 版本还是 1.0,默认使用的是“短连接”的 TCP 方式——默认不启用 Keep-Alive)

 


 

最后给大家看个小故事~方便大家理解

从前山上有座庙,庙里有个和尚……,别胡闹了,老和尚来了。

小和尚问老和尚:ssl为什么会让http安全?

老和尚答道:譬如你我都有一个同样的密码,我发信给你时用这个密码加密,你收到我发的信,用这个密码解密,就能知道我信的内容,其他的闲杂人等,就算偷偷拿到了信,由于不知道这个密码,也只能望信兴叹,这个密码就叫做对称密码。ssl使用对称密码对http内容进行加解密,所以让http安全了,常用的加解密算法主要有3DES和AES等。

小和尚摸摸脑袋问老和尚:师傅,如果我们两人选择“和尚”作为密码,再创造一个和尚算法,我们俩之间的通信不就高枕无忧了?

老和尚当头给了小和尚一戒尺:那我要给山下的小花写情书,还得用“和尚”这个密码不成?想了想又给了小和尚一戒尺:虽然我们是和尚,不是码农,也不能自己造轮子,当初一堆牛人码农造出了Wifi的安全算法WEP,后来发现是一绣花枕头,在安全界传为笑谈;况且小花只知道3DES和AES,哪知道和尚算法?

小和尚问到:那师傅何解?

老和尚:我和小花只要知道每封信的密码,就可以读到对方加密的信件,关键是我们互相之间怎么知道这个对称密码。你说,我要是将密码写封信给她,信被别人偷了,那大家不都知道我们的密码了,也就能够读懂我们情书了。不过还是有解的,这里我用到了江湖中秘传的非对称密码。我现在手头有两个密码,一个叫“公钥”,一个叫“私钥”,公钥发布到了江湖上,好多人都知道,私钥嘛,江湖上只有我一个人知道;这两个密钥有数学相关性,就是说用公钥加密的信件,可以用私钥解开,但是用公钥却解不开。公钥小花是知道的,她每次给我写信,都要我的公钥加密她的对称密码,单独写一张密码纸,然后用她的对称密码加密她的信件,这样我用我的私钥可以解出这个对称密码,再用这个对称密码来解密她的信件。

老和尚顿了顿:可惜她用的对称密码老是“和尚为什么写情书”这一类,所以我每次解开密码纸时总是怅然若失,其实我钟意的对称密码是诸如“风花”“雪月”什么的,最头痛的是,我还不得不用“和尚为什么写情书”这个密码来加密我给小花回的情书,人世间最痛苦的事莫过于如此。可我哪里知道,其实有人比我更痛苦。山下的张屠夫,暗恋小花很多年,看着我们鸿雁传书,心中很不是滋味,主动毛遂自荐代替香客给我们送信。在他第一次给小花送信时,就给了小花他自己的公钥,谎称是我公钥刚刚更新了,小花信以为真,之后的信件对称密码都用张屠夫的这个公钥加密了,张屠夫拿到回信后,用他自己的私钥解开了小花的对称密码,然后用这个对称密码,不仅能够看到了小花信件的所有内容,还能使用这个密码伪造小花给我写信,同时还能用他的私钥加密给小花的信件。渐渐我发现信件变味了,尽管心生疑惑,但是没有确切的证据,一次我写信问小花第一次使用的对称密码,回信中“和尚为什么写情书”赫然在列,于是我的疑惑稍稍减轻。直到有一次去拜会嵩山少林寺老方丈才顿悟,原来由于我的公钥没有火印,任何人都可以伪造一份公钥宣称是我的,这样这个人即能读到别人写给我的信,也能伪造别人给我写信,同样也能读到我的回信,也能伪造我给别人的回信,这种邪门武功江湖上称之“Man-in-the-middle attack”。唯一的破解就是使用嵩山少林寺的火印,这个火印可有讲究了,需要将我的公钥及个人在江湖地位提交给18罗汉委员会,他们会根据我的这些信息使用委员会私钥进行数字签名,签名的信息凸现在火印上,有火印的公钥真实性在江湖上无人质疑,要知道18罗汉可是无人敢得罪的。

小和尚问:那然后呢?

老和尚:从嵩山少林寺回山上寺庙时,我将有火印的公钥亲自给小花送去,可是之后再也没有收到小花的来信。过了一年才知道,其实小花还是给我写过信的,当时信确实是用有火印的公钥加密,张屠夫拿到信后,由于不知道我的私钥,解不开小花的密码信,所以一怒之下将信件全部烧毁了。也由于张屠夫无法知道小花的对称密码而无法回信,小花发出几封信后石沉大海,也心生疑惑,到处打听我的近况。这下张屠夫急了,他使用我发布的公钥,仿照小花的语气,给我发来一封信。拿到信时我就觉得奇怪,信纸上怎么有一股猪油的味道,结尾竟然还关切的询问我的私钥。情知有诈,我思量无论如何要找到办法让我知道来的信是否真是小花所写。后来竟然让我想到了办法….

老和尚摸着光头说:这头发可不是白掉的,我托香客给小花带话,我一切安好,希望她也拥有属于自己的一段幸福,不对,是一对非对称密钥。小花委托小镇美女协会给小花公钥打上火印后,托香客给我送来,这样小花在每次给我写信时,都会在密码纸上贴上一朵小牡丹,牡丹上写上用她自己的私钥加密过的给我的留言,这样我收到自称是小花的信后,我会先抽出密码纸,取下小牡丹,使用小花的公钥解密这段留言,如果解不出来,我会直接将整封信连同密码纸一起扔掉,因为这封信一定不是小花写的,如果能够解出来,这封信才能确信来之于小花,我才仔细的解码阅读。

小和尚:难怪听说张屠夫是被活活气死的。您这情书整的,我头都大了,我长大后,有想法直接扯着嗓子对山下喊,也省的这么些麻烦。不过我倒是明白了楼上的话,ssl 握手阶段,就是要解决什么看火印,读牡丹,解密码纸,确实够麻烦的,所以性能瓶颈在这里,一旦双方都知道了对称密码,之后就是行云流水的解码读信阶段了,相对轻松很多。

发表评论

电子邮件地址不会被公开。 必填项已用*标注