HTTP 会话劫持防御想法

[heiher]

鉴于当前 HTTP 会话劫持几乎都是针对 HTTP 请求的首个 TCP 数据承载包的（是否存在能够维护独立的 TCP 上下文的方案不确定，个人觉得当前在用的系统没有实现的），是否人为干预HTTP请求在两个或多个独立的TCP承载包中就可以使得劫持程序不命中呢？

[lehui99]

想了2个星期这种方法了，做个proxy进行拆包，可惜一直很忙没时间做。

[dant]

把第一个包拆开，比如

HTTP/1
---------
.1 GET /
Accept-****

[dant]

手滑按快了。。

当时写出这样一个程序之后发现电信的劫持暂停了（或许跟我在微博上问候了它们的亲人有关），所以没法测试。等到后来再遇到劫持的时候就找不到了。。

[julyclyde]

tcp不是包，而是流
首先要坚定这个信念，然后再谈别的

[heiher]

@julyclyde 从应用层看是流，但劫持程序的角度实际在传输层，应该是由于维护网络上所有的 TCP 会话上下文开销很大，而且这样做可能也不会带来太多的好处。我想多数的劫持程序还是假设一个完整（或至少包含了 QueryString, Host）的 HTTP 请求在第一个包含数据的 TCP 包中的，如果打破这个假设劫持程序的匹配应该就不会命中了。我只是在想从哪个层面实现最简单、方便、通用。来这里和大家讨论一下。

[heiher]

@lehui99 工作在应用层的 proxy 如何保证一定会拆包呢？是通过延迟控制吗？

[mengzhuo]

@heiher

应用层才是最方便的
MITM攻击层出不穷，工具也不少

只是这样劫持需要伪造的证书得是可信CA发的
一般CA会向域名注册信息里的邮箱发封邮件确认
苹果、Linux、Windows都经常更新证书的可靠性
所以无解

[typcn]

普及 HTTPS 才是关键

[lehui99]

@heiher setsockopt中有多种方式可以控制发送缓冲区

[heiher]

@lehui99 我试试这个方式看看行不行，我正好有一个 socks5 server，https://github.com/heiher/hev-socks5-proxy

[heiher]

@lehui99 实现了一个代理版本（https://github.com/heiher/hev-socks5-proxy/tree/anti-hijack），方式是前向链路在完成 Socks5 协议处理后，将前向链路的 Buffer 长度限制在了 16 字节。抓包看的确被拆分了：
p0: GET / HTTP/1.1\r\n
p1: Host: xxxx ....

[lehui99]

@heiher 嗯，算是完成了我一直想做的东西了。本来设想还包括使用libpcap检测服务器回包的ttl，如果不一致则说明被劫持。如果是get则重发请求，其他的断开链接。然后把libpcap做成可选项，可以选择是否启用。

[heiher]

@lehui99 TTL 正常情况下就有可能变化。

[julyclyde]

按包替换，后面根本拼不出来

[heiher]

@julyclyde 按包替换是什么意思？

[heiher]

@julyclyde 这个按包替换是什么意思？

[jedihy]

@lehui99 听说你这样做会触发GFW的IP封锁

[heiher]

@jedihy 这是为什么？

[lehui99]

@heiher 这种及其偶然的情况基本上可以忽略了。


@jedihy 封锁哪个IP？