欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

别具匠心的HTTP应用层行为设计

作者:易隐者 发布于:2012-12-26 16:09 Wednesday 分类:网络分析

       今年的年初,有位兄弟在QQ跟我讨论一个较为少见的报文交互情况,我当时在看了具体的报文交互之后,对他说是某种HTTP探测机制,他则对我说有人认为是某种SACK的重传机制,记得我曾说过我会找时间好好研究一下这个交互的行为,后来的确也写了一些分析、画了一些图示,但是在未完成的情况下被耽搁了,直至最近才把这个翻出来,闲话少说,我们还是直奔主题,一起来看一下这个有意思的应用交互行为吧。

       这个报文交互过程如下:

点击查看原图

       其交互的数据流图如下: 

点击查看原图

       我们再来看一下其中几个重要报文的详细解码,首先看服务器的HTTP 200 OK响应报文的解码,如下图所示: 

点击查看原图

服务器响应报文解码(No128报文解码)

       这个服务器的响应报文,其应用字段长度为585字节,序列号为101871,最后两字节应用字段为Hex 0d0a,我们再来看一下客户端对这个服务器响应报文的确认报文的解码,如下图所示: 

点击查看原图

       从上图解码来看,这是一个最为常见的确认报文,确认号为102456(101871+585)。我们再看看服务器的重传报文解码,如下: 

点击查看原图

服务器后续重传报文解码(No132报文解码)

       我们能够清楚的看到,这个来自服务器的重传报文其应用字段为1字节,序列号为102454,应用字段为Hex 0d,通过序列号我们可以看出这个重传报文并不是No130应用响应报文的重传,而仅仅是重传了No130报文中倒数第二个字节的应用字段!我们再看看客户端对服务器这个重传报文(No132报文)进行确认的报文解码: 

点击查看原图

客户端对服务器这个重传报文(No132报文)进行确认的报文解码

       客户端确认号为102456,但是其SACK却显示为102454-102455!确认号大于块左边界、块右边界值,这是不符合SACK的相关规范的!

       我把这个交互过程制作一个更为清晰明了的图示如下: 

点击查看原图

       现在大家应该清楚这个交互的具体情况了,那么疑问来了:

1, 服务器端为何重传倒数第二个字节的应用字段?
2, 客户端在确认服务器的重传报文时,为何使用不规范的SACK?

       带着这两个疑问,我用自己的机器访问163网站,重现了这个交互过程如下: 

点击查看原图

       这个过程跟上面的交互过程几乎是一致的,我们就不再做详细的分析了,但是我们来仔细的查看一下客户端对服务器一字节应用字段重传的确认报文的解码: 

点击查看原图

客户端对服务器重传报文进行确认的报文解码

       在这个解码中,我们看到,我的机器在对服务器的一字节重传报文进行确认时,并未使用SACK,而是正常的重传了对服务器应用响应报文的确认,这是一般情况下的正常处理。这也说明了服务器的这个“重传一字节应用字段”的行为并不会导致客户端的确认出现异常。只有系统处理差异才能够解释这种情况的发生:我使用的客户端是XP操作系统,而那位与我讨论的兄弟使用的是其他操作系统。不同的操作系统在遇到这种重传部分应用字段的报文时处理机制不一样导致了疑问2的出现,这种不合SACK规范的确认报文虽然不会对服务器造成交互的影响,但足以让我们产生困惑,因此,严格来说,那位与我讨论的兄弟所使用的端系统如此处理是异常的。

       如此我们解决了第二个疑问。

       而针对第一个疑问,问遍了google和baidu无果后,让我们一起来分析一下这种行为可能带来的好处和坏处。

       服务器在作出应用响应之后,在200ms左右未收到来自客户端的确认报文,则将倒数第二个字节的应用字段封装重传给客户端。

这样做的好处是在如下几种情况下会提高服务器与客户端的交互效率

1, 服务器发往客户端的应用响应报文在网络传输过程中被丢弃
       服务器的响应报文被丢弃,未到达客户端,在这种情况下,服务器的这个“200ms内未收到客户端ACK报文则重传一字节应用字段”的行为,避免了服务器端被动等待客户端确认报文到达直至重传定时器清零,服务器才可以重传报文,服务器通过这种行为主动探测客户端对服务器报文接收的情况,提高了交互的效率。 

点击查看原图

服务器应用响应报文被丢弃时的交互过程图示

2,客户端对服务器应用响应报文的确认在网络传输过程中被丢弃
       如果客户端对服务器应用响应报文的确认报文在到达服务器之前被丢弃了,那么,会出现服务器端等待客户端确认报文到达的情况,这是一个超时重传的等待时间,一般至少在数秒之间,而服务器的这个“200ms内未收到客户端ACK报文则重传一字节应用字段”的行为,可以在200ms左右主动发送“封装最后倒数第二个字节应用字段的重传报文”,这个报文到达客户端之后,客户端将重新发送确认报文,这减少了超时重传的等待时间,从而提高了交互的效率;

点击查看原图

客户端对服务器响应报文的确认被丢弃时交互过程的图示

坏处就是:与一般正常交互过程相比,可能会给网络多带来两个64字节的小包

       如果客户端正常收到了服务器的应用响应报文,只是客户端的ACK报文较慢(网络传输延时或者客户端的delay ack机制等)到达服务器,则服务器会发送这种带有一个应用字段的重传报文,而客户端在收到这个报文后,会对这个报文进行确认。

       而这个坏处相对于其带来的好处而言,实在不值一提,因此不得不说,这个HTTP应用行为的设计是别具匠心的!

       那么为什么是倒数第二个字节而不是倒数第一个字节、倒数第三个字节或者其他字节?理论上来说重传任何一个字节达到的效果都是一样的,只重传部分应用字段(一个字节)是为了节约网络带宽资源,或许程序设计者如此设计有一些特别的用处,但是这只能去问程序设计者本人了。

      另:我已将相关报文文件作为附件上传至此,有兴趣的兄弟姐妹可下载学习探讨,下载后解压即可使用wireshark直接打开查看。

阅读全文>>

附件下载:
别具匠心的HTTP应用行为设计-兄弟提供的原报文.zip 203.32KB
别具匠心的HTTP应用行为设计-我重现的报文1.zip 2.1KB
别具匠心的HTTP应用行为设计-我重现的报文2.zip 4.21KB

标签: sack 解码 重传 get delay ack HTTP 应用行为

评论(1) 引用(0) 浏览(78416)

可能的URL超长导致丢包案例

作者:易隐者 发布于:2012-12-10 14:03 Monday 分类:案例讨论

       上周五,有网友兄弟给我发了一个报文,让我帮忙查看是否存在什么异常问题。我查看其TCP会话交互过程,如下图所示: 

点击查看原图

       单从这个报文交互来看,客户端与服务器的TCP连接建立正常,客户端已经向服务器发送过get请求,并得到了服务器的确认,问题出在客户端向服务器发送的第二个get请求:“
http://192.168.0.12/Default_Login.aspxusercode=x6x9&password=81xx9xxx52x04xx20036xxx8313xx055&

MyCurrentCompany=&rdnum=0.5966797953405811”。

       客户端发出这个get请求之后,在37秒的时间内重传了5次,服务器端无应用数据需要主动的发给客户端,因此在这个时间段内我们未见来自于服务器的报文,而如果客户端的发送的这个get请求到达了服务器端,则服务器会根据其请求内容作出应用响应,最起码服务器端会对客户端的TCP报文发送ACK确认。但是这些都没有出现,这能够说明客户端的get请求报文根本未到达服务器端,即客户端的这个get请求报文被中间设备丢弃了,我们查看客户端的发送的第二个get请求报文的解码

点击查看原图

       我们发现这个报文除了其请求的URL长度较长(420字节)外,其他似乎也没什么特别的,因此,个人推测其被中间设备丢弃的原因可能是其URL超出了防火墙/负载均衡/WAF/IPS等设备的限制,或者是URL中包含“uesr”、“password”等敏感字段而被中间设备丢弃了。

阅读全文>>

标签: TCP 负载均衡 解码 ACK确认 防火墙 IPS get URL超长 get请求

评论(3) 引用(0) 浏览(4610)

【转】中科院《个人隐私泄露风险的技术研究报告V1.0》的部分内容

作者:易隐者 发布于:2012-11-23 9:43 Friday 分类:案例讨论

【说在之前】:

1,早上看到新浪新闻《中科院报告:360产品存在三大隐私安全问题 》,其中引用了中科院保密技术攻防重点实验室研究撰写的《个人隐私泄露风险的技术研究报告》的部分内容,通过分析可见任何应用产品,若非自行开发,均可能在后台执行各种非法的或非授权的操作,而这种隐形的操作行为很可能会给最终用户带来各种威胁;

2,这些后台的隐形行为不易为用户所察觉,但是利用网分析技术可以对这些隐形行为进行数据包级别的深入分析;

3,该报告分析的主要方式是通过网络分析的技术手段实现对360浏览器网络行为的分析,使用的工具看截图应该是wireshark,此报告作为利用网络分析技术对应用进行分析评估的一个案例,值得大家参考学习。

【原文链接】:http://tech.sina.com.cn/i/2012-11-23/08517825584.shtml

【原文】:

  前言

  随着国内外个人隐私泄露事件的频繁发生和对个人隐私保护的重视,人们越来越关注日常工作生活中计算机软件、移动终端以及高技术带来的个人隐私问题。中国科学院信息工程研究所保密技术攻防重点实验室对当前常用软件和终端产品的用户隐私保护情况进行了初步调查,通过实验研究发现了一些有关隐私保护存在的风险。本文主要从常用软件、网络服务、移动终端以及声光电磁等四个方面介绍了实验室的研究结果和发现。文中内容注重实例研究和数据再现,希望引起有关部门对个人隐私相关问题的关注。

  本文得到了北京大学互联网安全技术北京市重点实验室的帮助。

  1 终端常用软件与用户隐私保护

  1.1网络浏览器

  许多网络浏览器为了增强用户体验、提供个性化服务、发展定向广告业务等目的,通常会在后台收集用户的网页浏览记录等个人信息上传到服务器。然而许多收集用户个人信息的行为是在用户不知情的情况下进行的,或者所收集的信息超出了软件《安装许可协议》中进行了明确规定的范围。

  实验室以360安全浏览器当前最新版本5.0为例,对浏览器的用户隐私泄露问题进行了分析和研究,网络浏览器中的隐私泄露威胁存在于以下几个方面:

  1)预留后门,植入代码:一些浏览器在使用过程中会在用户不知情的情况下在后台执行《安装许可协议》规定内容之外的功能,360安全浏览器在运行过程中约每5分钟与服务端进行一次通信,并下载一个文件,如下图所示,下载的文件为se.360.cn/cloud/cset18.ini,但是从数据流可以看出该文件实际上是一个PE文件,文件头中标识的产品名称为DataDll。

图1-1 
图1-1

  将该文件从数据流中提取出来得到一个dll文件,查看该文件的属性,得到其文件说明为“360安全浏览器 安全网银”。

图1-2 
图1-2

  从该文件中提取到一段Base64编码的文本信息:

W3N0XQ0KY291bnQ9Mg0KW3N0MV0NCmlkPTENCnVybD1odHRwOi8vd3d3LmJhaWR1LmNvbS9zZWFyY2gvc

mVzc2FmZS5odG1sKg0KW3N0Ml0NCmlkPTINCnVybD1odHRwOi8vdmVyaWZ5LmJhaWR1LmNvbS92Y29kZT8q

DQpbdHJheW1zZ10NCnN0YXRpY3NpZD0zMQ0KY291bnQgPSAxDQp1cmwxPWh0dHA6Ly93d3cuYmFpZHUuY2

9tL3NlYXJjaC9yZXNzYWZlLmh0bWwqDQpbbWFpbl0NCmhrcmVzMj0xDQpjYmM9MQ0KW2NiY10NCnVybGNvdW

50PTENCnVybDE9aHR0cDovL3d3dy5iYWlkdS5jb20vc2VhcmNoL3Jlc3NhZmUuaHRtbCoNCmNiY2NvdW50PTINC

mMxPUJBSURVSUQNCmMyPUJEVVNT

  经过解码后的内容为:

  [st]

  count=2

  [st1]

  id=1

  url=http://www.baidu.com/search/ressafe.html*

  [st2]

  id=2

  url=http://verify.baidu.com/vcode?*

  [traymsg]

  staticsid=31

  count = 1

  url1=http://www.baidu.com/search/ressafe.html*

  [main]

  hkres2=1

  cbc=1

  [cbc]

  urlcount=1

  url1=http://www.baidu.com/search/ressafe.html*

  cbccount=2

  c1=BAIDUID

  c2=BDUSS

  由此可推测该DLL文件的功能与网银无任何关系,而是跟搜索引擎百度相关可能是为了躲避Referer字段的检查。这种行为虽然不涉及用户隐私,但是具有欺骗性。

  此外,360安全浏览器还会在用户不知情的情况下定期从服务端下载和执行一个名为“ExtSmartWiz.dll”的动态链接库。如果该动态链接库被植入恶意功能或者不法分子利用域名劫持等方法对浏览器下载的“ExtSmartWiz.dll”文件进行恶意篡改,将会给用户安全带来严重危害。

  2)收集用户浏览记录:很多浏览器会将用户所打开的页面地址上传到服务器,以分析用户的个人爱好或者统计网站的受欢迎度,从而在浏览器首页更好地为用户推荐个性化内容。这种行为也侵犯了用户的隐私数据。下图为当用户使用360安全浏览器5.0访问网页的时候,每打开一个网页之后都会向360的特定服务器发送一个POST请求,内容包含加密过的url信息。

图1-3
 图1-3

  3)收集浏览器地址栏输入信息:当用户在浏览器地址栏中输入网址的时候,很多浏览器为了帮助用户自动补全网址,会把用户所输入的内容上传到服务器来。下图为当用户在360安全浏览器5.0的地址栏中输入“10.105.240.57”时,浏览器会将该地址发送到sug.so.360.cn,并且发送时附带的Cookie中会带有具有用户唯一性标志的guid值,这可能会导致特定用户的地址栏输入以及浏览记录被跟踪和泄漏。

图1-4 
图1-4

  下图所示为当用户在360安全浏览器5.0的地址栏中输入“weibo.com”的过程中,每输入一个字符,浏览器就会向sug.so.360.cn发送当前浏览器地址栏中的内容(即“w”、“we”、“wei”、“weib”、“weibo”、“weibo。”、“weibo.c”、“weibo.co”、“weibo.com”)。

中科院报告:360产品存在三大隐私安全问题

图1-5

阅读全文>>

标签: wireshark 网络分析 解码 安全 业务 网络行为 应用分析 应用评估

评论(0) 引用(0) 浏览(3648)

Wireshark对ping报文的解码显示(BE与LE)

作者:易隐者 发布于:2012-9-25 17:34 Tuesday 分类:网络分析

        我们非常熟悉ping报文的封装结构,但是,在这个报文解码里,我们发现wireshark的解码多了几个参数:Identifier(BE)、Identifier(LE)、Sequence number(BE)、Sequence number(LE),如下图所示: 

点击查看原图

       以前一直未注意wireshark是这样解码ping报文的,感觉非常奇怪,我们先来仔细的看一下wireshark对ping报文中这几个参数的解码情况:

点击查看原图

点击查看原图

点击查看原图

点击查看原图

         Wireshark解码显示,Identifier(BE)与Identifier(LE)都对应“hex 0200”,Sequence number(BE)与Sequence number(LE)都对应“hex 027b”,仔细看的话,我们能够发现BE值(0x0200)与LE值(0x0002)之间的差别就是顺序不一样。那到底BE、LE是指什么呢?搜遍百度无果,决定还是去wireshark官网看看,结果发现下面链接的内容:http://www.wireshark.org/lists/wireshark-bugs/200909/msg00439.html,其中有一段是这样描述的:

“After I discovered that the Windows ping sends ICMP echo request packets with the sequence number in little-endian byte order, but the Linux ping sends it in proper big-endian format, a discussion about it took place on the mailing list as to how to handle it (refer to  http://www.wireshark.org/lists/wireshark-dev/200909/msg00216.html).  However,to keep things simple and avoid adding any new ICMP preferences and/or trying to guess at the byte order, I thought why not just display the sequence number in both formats, so that's what this patch does.”

       我来做个总结:wireshark考虑到window系统与Linux系统发出的ping报文(主要指ping应用字段而非包含IP头的ping包)的字节顺序不一样(windowsLElittle-endian byte orderLinuxBEbig-endian),为了体现wireshark的易用性,开发者将其分别显示出来。

       Wireshark的牛B之处,由此细节可见一斑!

阅读全文>>

标签: wireshark 解码 ping BE LE little-endian big-endian

评论(0) 引用(0) 浏览(33014)

iPhone与Multicast DNS

作者:易隐者 发布于:2012-9-21 20:58 Friday 分类:案例讨论

        前两天看到CSNA论坛上有一个求助帖,原帖连接为:http://www.csna.cn/network-analyst-49133-1-1.html,故障现象大致为:网络经常出现断网情况,抓包发现断网时有大量的DNS包,楼主认为是IPHONE或IPAD在连接公司无线网络时出现的数据包。

       我下载了其数据包文件,并选其中的一个数据包文件进行了大致的分析:
1, 在数据包视图中查看其发包频率,如下图: 

点击查看原图

在1秒的时间内 发送了15542个IPv6的多播报文,这种发包频率,足以影响相关无线路由、交换机等设备的处理性能,而接收方对多播报文的处理流程决定了过多的多播报文对网络和主机的影响,大家可参考本人个人博客中《基于UDP组播实施分片攻击的可能性》一文。

2,我们查看其详细解码: 

点击查看原图

IPV6封装UDP 5353端口的DNS请求行为,经网络搜索相关信息,确认为Multicast DNS(组播DNS)报文;

       经查阅相关资料,苹果系列产品在本地局域网内缺少DNS服务器的环境下,使用Multicast DNS,实现名字和IP地址的解析,每个主机都知道自己的名字,并且会自动响应来自多播报文中针对该名字的请求。 使用Multicast DNS的设备大致工作过程如下:

1,在“.local.”子域下,挑选所需的名字;
2,使用Multicast DNS进行名字查询,看是否有主机已经使用了这个名字;
3,如果收到来自与其他主机的名字解析响应,则在“.local.”子域下重新选择一个名字,直至确认本地局域网内无其他设备使用该名字为止。

       大家可参考苹果支持主页中关于“Multicast DNS”的相关页面:http://support.apple.com/kb/TA20999?viewlocale=en_US

       这些都明确说明这个报文是iPhone发出的Multicast DNS报文,但是异常之处在于设备发包的频率太快了,而楼主反馈说,“不是每次连接都出现这个问题,只是偶尔会出现”,这也从侧面说明这个异常行为应该是属于iPhone本身跟“Multicast DNS”有关的进程异常导致的,可能是iPhone的BUG亦未可知。

       我在搜索相关信息的时候,竟然找到了一篇跟MAC OS相关的DNS异常问题的帖子,应该属于相关内容了,感兴趣的可以自行查看下面连接:http://blog.sina.com.cn/s/blog_539a3a320100q5dq.html

阅读全文>>

标签: 交换机 分片 解码 故障 UDP 多播 DNS iPhone Multicast DNS 多播DNS 组播DNS IPv6

评论(0) 引用(0) 浏览(11281)

Powered by 易隐者 基于emlog 皖ICP备12002343号-1