讲述一个你所不知的HTTP故事

8 Krypton

讲述一个你所不知的HTTP故事

讲述一个你所不知的HTTP故事

转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese

作者:林沛满

2012727日,伦敦奥运会开幕式上,一位老者坐在电脑边。他在众人的注视下发了一条推特"This is for everyone",随即就被显示在体育馆的大屏幕上,传遍世界。

他就是57岁的Tim Berners-Lee爵士,World Wide Web的发起者,也是第一位实现HTTP的工程师。英国人不但借此传播了开放和分享的互联网精神,也展示了其在IT历史上的地位——从奠定现代计算机基础的Alan Turing,到发明分组交换的Donald Davies,再到网页之父Tim Berners-Lee,每一个重大环节都有英国人的位置。假如北京奥运会上也要推出中国的IT英雄,我想德高望重的方滨兴校长当仁不让。他也可以坐在一排防火墙旁边,发一条推特。

Tim所贡献的HTTP便是我们今天浏览网页所用的协议。HTTP的工作方式是“请求-响应”模式,即客户机向服务器发起请求,服务器再把结果返还给客户机。请求里包含的方法有多种,例如GET, POST, PUTHEAD等等。这些方法都有特定功能,比如我们登录网站时就可能用到POST方法。下图是在打开http://www.rfc-editor.org/info/rfc2616时抓的包。我们来看看具体发生了什么:


pl_1.png

1)从SYN标志可知,123号包是TCP三次握手,建立了一个连接。

2)在4号包里客户机向服务器发送了"GET /info/rfc2616 HTTP1.1"的请求,就是想通过1.1版的HTTP协议获得该页面的内容。

35号包是对4号包的确认,表示服务器已经收到该请求。

46,7号包里服务器响应了该请求,把/info/rfc2616的内容发给客户机。

58号包是客户机对67号包的确认,表示客户机已经收到响应。

69号包里客户机向服务器发送了“GET /style/rfc-editor.css”的请求,这个文件定义了该页面的格式。

710,11号包里服务器响应了该请求,把/style/rfc-editor.css的内容发给客户机。

812号包是客户机对1011号包的确认,表示客户机已经收到响应。

就这样,客户机通过两个GET方法打开了网页。如果点开每一个HTTP包还能看到其协议头和详细信息。以4号包为例,它的HTTP协议头在Wireshark中显示如下。其包含的信息大概可以归纳为:我要通过1.1版的HTTP协议从服务器www.rfc-editor.org/info目录里得到rfc2616文件的内容。


pl_2.png

HTTP算不上一个复杂的协议,出问题时浏览器也有提示信息,所以需要用到Wireshark的状况并不多。不过随着技术的进步,HTTP也逐渐被应用到不需要浏览器的场景中,比如现在如火如荼的云存储。由于海量文件不适合传统的目录结构,所以云存储一般使用对象存储技术。也就是说客户机读写文件时并不使用其文件名,而是用该文件所对应的Object ID。身份验证方式也是通过HTTP。处理此类问题就要用上Wireshark了。下图是Wireshark解析后的读过程,我们从中可以看到该文件的Object ID 59J5T5KV78EP0e7AJIV55UO93DVG4140QGQQ000ED7PR8EJH3OGUV”,还有身份验证时用到的用户名“paddy”及其加密后的密码。我们甚至可以看到服务器响应的文件内容“I am Paddy Lin……”。在这个过程中一旦发生问题,比如身份验证出错了,就能通过Wireshark来辅助诊断。


pl_3.png

上面两个例子都用到了GET方法,因为它是最常用的。事实上HTTP协议最早的版本就只支持GETTim开发的第一个网页也是如此。这在今天的开发者看来是小菜一碟,甚至给人一种“时无英雄”的错觉。但如果放眼整个IT历史,现在看起来很了不起的技术都是这样发展而来的。还是以云存储为例,底层用到的HTTP等协议称得上简单,但由此发展起来的云概念就是科技前沿了。

Wireshark来解决问题是很痛快,因为整个通信过程一览无遗。但仔细一想却令人脊背发冷——如果连文件内容都可以清楚地看到,那我上网时的聊天记录,甚至密码是否也会被发现?答案肯定的,如果没有使用加密软件,黑客(或者你的领导)可以从网络包中看出你上班时聊了些什么,在哪些帖子上祝福楼主好人一生平安,搜索了什么资料,甚至知道你登录某些论坛的用户名和密码。

下图是我在Google上搜索时抓的包。从4号包可以看到我搜索的关键词 “Max is the best boss in the world”(Max是我老板的名字,希望他现在正在监控我的网络)。如果IT部门把这类包收集出来,就能统计出员工们上班时都在搜索什么。通过IP地址还能查到某一项是谁搜的。


pl_4.png

至于更敏感的用户名和密码,这里也有个血淋淋的例子。我在登录www.mshua.net(这是我经常登录的园艺论坛)时抓了包,结果如下图所示。当客户机用POST方法把用户名和密码传给服务器时,已经在网络上暴露了身份。请看下图底部的用户名“wiresharktest”和密码“P@ssw0rd”,可以想见这个帐号随时可能落入他人手中。事实也是如此,上个月我登录时,就发现几位平时一本正经的网友在发成人图片,显然他们的密码已经被盗了。为了防止好奇的读者用我的帐号浏览不健康信息,我已经把密码改掉了。


pl_5.png

那要如何保护自己的信息呢?HTTPS就是一个不错的选择。比如用Google搜索时在http后加个s,变成 https://www.google.com.hk/,就不用担心老板知道你在搜些什么了。

因为大多数读者并不需要理解HTTPS的加密算法(其实是因为作者不懂),本文将不在此多费笔墨。但是HTTPS会给诊断过程带来不少障碍,所以有必要知道如何对它进行解码。下图是4HTTPS包,我们除了能看到”Application Data Protocol”是http之外,几乎对它们一无所知。因为所有信息都被加密了,在Wireshark里显示为“Encrypted Application Data”。


pl_6.png

要对这些加密包进行解码,需要以下几个步骤。本例所用的网络包和密钥来自http://wiki.wireshark.org/SSL 上的snakeoil2_070531.tgz文件,建议你也下载来玩玩。

1  解压snakeoil2_070531.tgz并记住key文件的位置,比如C:\tmp\rsasnakeoil2.key

2  Wireshark打开rsasnakeoil2.cap

3  点击WiresharkEdit菜单PreferencesProtocolsSSLRSA keys list。然后按照IPAddress,Port,Protocol,PrivateKey 的格式填好。如下图所示:


pl_7.png

4  点击OK,这些包就成功解码了。下图就是这4个包解码后的样子。


pl_8.png

既然HTTPS能被解码,是不是说明它也不安全呢?事实并非如此,因为解码用到的密钥只能在服务器端导出。不同的服务器操作步骤有所不同,比如IIS就可以参考这一篇:http://www.packetech.com/showthread.php?1585-Use-Wireshark-to-Decrypt-HTTPS

你的老板能潜入Google窃取密钥吗?我知道Max是不能的。

作者介绍:

pl_9.png

林沛满Paddy   Lin)是EMC全球技术支持中心(上海)NAS领域最资深的专家之一,拥有多年IT从业经验,擅长解决各种NAS方面的疑难杂症,在园林种植方面也颇有建树。业余时间,他喜欢撰写一些NAS相关的文章发布于个人的博客EMC中文支持论坛,文章用词诙谐幽默,深入浅出。他平时的口号是:爱科普,爱装B!

想了解更多关于作者的信息,可以访问:

林沛满博客地址:http://blog.sina.com.cn/u/1882820021

      微博地址:http://www.weibo.com/linpeiman?source=blog

评论

EMC真是卧虎藏龙呀。

专家Peiman Lin投稿,图文并茂,诙谐幽默,不能沉底!顶起来!

英国人还是非常厉害的。

版本历史
修订号
1 / 1
上次更新时间:
‎09-24-2013 10:24 AM
更新依据: