HTTPS与SSL(上篇)

作者: tsyeyuanfeng | 来源:发表于2016-05-11 13:47 被阅读1248次

    HTTP的安全性问题

    一般地,HTTP的报文在网络中是明文传输的。WEB服务器或者浏览器组装好HTTP数据包后,就直接递交给了传输层(一般是基于TCP的)进行传送。而通常情况下,我们的数据包不是直接传送到目标主机的,中间会经过很多的转发节点,比如寝室或家里的路由器,学校的网关路由器,运营商的路由器等。这中间的任何节点都可以截获我们的数据包,查看甚至篡改里面的内容然后再进行转发。

    在这里,举三个例子。

    例1:Cookie窃取
    我们都知道,HTTP协议是一个无状态的协议,在不附带其他额外信息的情况下,服务器是无法分辨前后两次请求是否是来自同一用户的。因此,需要一些辅助手段来记录用户的信息。Cookie就是其中之一(Cookie的作用就不在这里详述了)。Cookie最常见的作用就是用来记录用户登录的Session ID。
    我们首先来回顾一下登录的原理:

    • 用户填写用户名、密码
    • 发送登录请求,此请求会带上用户填写的用户名、密码,密码通常会再浏览器端先进行加密再传送
    • 服务器接收到登录请求数据包,取出用户名、密码进行验证,验证通过则在服务器端创建一个记录用户信息的Session,然后构造响应数据包,并且在HTTP头里面增加一个Set-Cookie字段,把刚才创建的Session的ID放进去
    • 浏览器接收到响应,并且把Set-Cookie头中的Cookie信息保存到本地
    • 以后浏览器再向该网站发起请求的时候,都会带上本地存储的Cookie信息;同样,服务器接收到请求的时候,也首先去检查请求头的Cookie信息,如果Cookie里有Session ID并且该Session ID对应的Session在服务器端还存在且有效,则服务器允许用户进行操作,否则将用户重定向到登录页面。

    如下图所示,这是登录之后浏览器存储的Cookie,里面有一个Session ID。


    Cookie-Session

    也就是说,如果我们的Cookie信息在传输的过程中被窃取了,窃取者就可以登录我们的账号了。我们拿163邮箱的登录举个例子。

    • 首先,登录我们的163邮箱


      163邮箱登录
    • 然后,我们通过Chrome自带的Network工具随便获取一个到main.163.com的请求,并取出其中的Cookie信息


      获取Cookie信息
    • 接下来打开另外一个浏览器,访问 http://mail.163.com。如果你没有在这个浏览器登录过,这个时候是不会直接登录的。打开浏览器开发工具的JS控制台,输入如下代码,并且把刚才的获取的Cookie粘贴到Prompt弹框里面。这个时候我们获取的Cookie信息已经写入了新浏览器。按照设想,此时我们应该可以复原该账号的登录了。
      写入Cookie
    • 重新载入页面,果然,登录进去了。


      复原登录

    所以,从例子1我们能看出来,当我们的Cookie信息被窃取,账号就有可能被坏人登录,然后做一些坏事^。我们的QQ空间,人人账号,BBS等都有可能通过这种方式被别人登录,因为他们都是只基于HTTP的。所以,对于不信任的WIFI热点,最好少连,连了也不要登录这些只基于HTTP的社交账号。当然了,这里只是举了一个例子,能够被窃取的还不仅仅是Cookie信息。由此可见,HTTP安全性问题一:数据有被窃取的危险。

    例2: 运营商HTTP劫持
    明文HTTP数据包除了可以被窃取之外,还有可能被篡改,而且通信的双方都无法知道接收到的HTTP数据包是否被篡改过。
    接下来,让我们来看一个HTTP数据包被篡改的例子。
    我们有时候在浏览手机网页的时候,会发现页面出了正常的内容之外,还多出了一些奇怪的东西,如下图右下角的水泡。

    HTTP劫持示意图1
    点开一看,却是运营商充话费、充流量的一个导购页面。
    HTTP劫持示意图2
    当我通过电脑访问,或者手机从数据切换到WIFI环境再访问时,页面上的水泡就消失了。这说明,页面上的这个水泡是运营商做的手脚。通过对比发现,在使用运营商网络访问网页时,获取到的页面被插入了一段JS。而这段JS的作用就是生成那个水泡和运营商的导购页面。
    HTTP劫持示意图3
    这说明,我们的响应HTTP数据包在返回的时候被运营商截获并且修改了。虽然这一行为很无耻,但是用户和WEB服务提供者对此都无能为力。

    例3:中间人攻击
    中间人攻击举一个典型的公钥私钥加密通信的例子吧。
    一般的场景是:A要与B进行通信,为了使通信内容保密,A会把自己的公钥发给B,B也会把自己的公钥发给A,然后A与B就可以进行加密通信了。但是,如果此时A与B中间有一个人C在窃听A与B的通信,当A把公钥发给B的时候,C把A的公钥截获下来并且把自己的公钥发给B,当B把自己的公钥发给A的时候,C把B的公钥截获下来并且把自己的公钥发给A,这样C就可以冒充A和B进行通信,也可以冒充B和A进行通信。A与B的通信内容对与C来说是毫无保密性可言的。
    这中间的问题在于,当我拿到一个公钥是,我无法知道我拿到的公钥是不是我目标通信对象的。要解决这个问题,必须要有一种办法,让收到公钥的人能够确认公钥的真实性。这就是后面会讲到的证书的作用。

    相关文章

      网友评论

      • f87f499102cd:请问下第一个例子,我敲了代码,输入了cookie后,控制台提示undefined,刷新网页也进不了163邮箱呢..咋破呢
        tsyeyuanfeng:@genericyzh 你是否是在第二个浏览器进行的操作并且第一个浏览器没有退出登录?
        f87f499102cd:@tsyeyuanfeng 应该是的Host:mail.163.com
        tsyeyuanfeng:@genericyzh 你的cookie是发往mail.163.com这个域的吗?
      • 我在睡觉:中间人攻击针对加密协议的,http不加密,所以我觉得中间人攻击应该放到下一篇讲解。
      • jasonkxs:支持~学习了
      • 给我二两面:讲的很详细,谢谢了
      • Bison:通过你这个运营商的例子,我应该可以去掉移动端那恶心的流量提醒了,晚点试试:smile:
      • 陈词非滥调:正要用到这些,一起学习,谢谢博主分享
      • 4588e4274830:学习了!
      • 9188dc518d63:不是很懂这个,只是知道有时上外网时需要把默认http改成https才能进入:joy:

      本文标题:HTTPS与SSL(上篇)

      本文链接:https://www.haomeiwen.com/subject/zreplttx.html