这是一个创建于 3515 天前的主题，其中的信息可能已经有所发展或是发生改变。
鉴于当前 HTTP 会话劫持几乎都是针对 HTTP 请求的首个 TCP 数据承载包的（是否存在能够维护独立的 TCP 上下文的方案不确定，个人觉得当前在用的系统没有实现的），是否人为干预HTTP请求在两个或多个独立的TCP承载包中就可以使得劫持程序不命中呢？
 |
1
lehui99 2014-09-10 20:55:29 +08:00 via Android
想了2个星期这种方法了，做个proxy进行拆包，可惜一直很忙没时间做。
|
 |
2
dant 2014-09-10 23:27:35 +08:00 via iPhone
把第一个包拆开，比如
HTTP/1 --------- .1 GET / Accept-**** |
|
3
dant 2014-09-10 23:29:55 +08:00 via iPhone
手滑按快了。。
当时写出这样一个程序之后发现电信的劫持暂停了（或许跟我在微博上问候了它们的亲人有关），所以没法测试。等到后来再遇到劫持的时候就找不到了。。 |
 |
4
julyclyde 2014-09-11 07:51:59 +08:00 via iPad
tcp不是包，而是流
首先要坚定这个信念，然后再谈别的 |
 |
5
heiher OP @julyclyde 从应用层看是流，但劫持程序的角度实际在传输层，应该是由于维护网络上所有的 TCP 会话上下文开销很大，而且这样做可能也不会带来太多的好处。我想多数的劫持程序还是假设一个完整（或至少包含了 QueryString, Host）的 HTTP 请求在第一个包含数据的 TCP 包中的，如果打破这个假设劫持程序的匹配应该就不会命中了。我只是在想从哪个层面实现最简单、方便、通用。来这里和大家讨论一下。
|
 |
7
mengzhuo 2014-09-11 09:34:50 +08:00
@heiher
应用层才是最方便的 MITM攻击层出不穷，工具也不少 只是这样劫持需要伪造的证书得是可信CA发的 一般CA会向域名注册信息里的邮箱发封邮件确认 苹果、Linux、Windows都经常更新证书的可靠性 所以无解 |
 |
8
typcn 2014-09-11 09:41:51 +08:00
普及 HTTPS 才是关键
|
|
10
heiher OP @lehui99 我试试这个方式看看行不行，我正好有一个 socks5 server，https://github.com/heiher/hev-socks5-proxy
|
|
11
heiher OP @lehui99 实现了一个代理版本（https://github.com/heiher/hev-socks5-proxy/tree/anti-hijack），方式是前向链路在完成 Socks5 协议处理后，将前向链路的 Buffer 长度限制在了 16 字节。抓包看的确被拆分了：
p0: GET / HTTP/1.1\r\n p1: Host: xxxx .... |
|
12
lehui99 2014-09-11 17:15:45 +08:00 via Android
@heiher 嗯，算是完成了我一直想做的东西了。本来设想还包括使用libpcap检测服务器回包的ttl，如果不一致则说明被劫持。如果是get则重发请求，其他的断开链接。然后把libpcap做成可选项，可以选择是否启用。
|
|
14
julyclyde 2014-09-11 19:22:32 +08:00 via iPad
按包替换，后面根本拼不出来
|
Select Language