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

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

作者：林沛满

2012年7月27日，伦敦奥运会开幕式上，一位老者坐在电脑边。他在众人的注视下发了一条推特"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, PUT和HEAD等等。这些方法都有特定功能，比如我们登录网站时就可能用到POST方法。下图是在打开http://www.rfc-editor.org/info/rfc2616时抓的包。我们来看看具体发生了什么：

1）从SYN标志可知，1、2、3号包是TCP三次握手，建立了一个连接。

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

3）5号包是对4号包的确认，表示服务器已经收到该请求。

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

5）8号包是客户机对6、7号包的确认，表示客户机已经收到响应。

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

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

8）12号包是客户机对10、11号包的确认，表示客户机已经收到响应。

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

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

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

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

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

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

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

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

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

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

2．  用Wireshark打开rsasnakeoil2.cap。

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

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

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

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

作者介绍：

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

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

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