目录

• 302图片特点

• 原理

• 对比302图片过程

• 正常情况下

• 在代理的情况下

• 与https不同的地方

• 提取关键数据

• 相比TLS握手优点

• demo

在通过https握手rtt识别TCP代理（socks5/http）之后，渐渐的发现这个事情没想象中的靠谱，主要原因分析大概如下：

1. iphone在部分情况会有谜之延迟，如果通过设置清楚浏览器缓存和记录，可以稳定得到一个近500ms 的延迟。个人认为客户端在没有https证书缓存的情况下验证会出现这个情况。对应的就是用户第一次访问你的服务器。
   

2. https 几乎都是配合H2或者https/1.1使用，由于链接复用，都很难再次触发重新握手（写这文章时还这么认为），则无法进行多次检测加以验证。

302图片特点

为了规避以上问题，我想到一个简单的方法，就是一个302图片跳转。事实上只要是个302跳转就行，用图片的原因有：

1. 图片可以通过img标签引入，页面无需跳转

2. img 默认支持302，并且可以视为完整且不易被干扰的过程

3. img 默认支持跨域，方便其他人使用

原理

通过https握手rtt发现代理的本质原因是：

1. 这是个连续过程

2. 有必然来自客户端的数据（密钥交换）

3. ack应答包被代理先应答

对比302图片过程

正常情况下

	cliet	================== 	server
1		== img request ==>
2		<= 	ack	==
3		<=   302 header ==
4		== 	ack	=>
5		==302img request=>
6		<= 	ack	==	
7 		<=   img body   ==
8		== 	ack	=>

在代理的情况下

	cliet	==================	proxy	==================	server
1		== img request ==>		
2		<= 	ack	==		==  img request =>
3						<= 	ack	==
4						<=   302 header ==		
5		<=   302 header ==		== 	ack	=>
6		== 	ack	=>
7		==302img request=>
8		<= 	ack	==		==302img request=>
9						<= 	ack	==
10						<=   img body   ==
11 		<=   img body   ==		== 	ack	=>
12		== 	ack	=>

这是我们也会发现，302图片符合上面提到的原理：

1. 这也是一个近乎连续的过程

2. 有来自客户端数据（302img request）

3. ack包被proxy代理先应答

与https不同的地方

由于302图片过程存在在整个数据中间，并且包并不用于TLS是明文并且可以被简单识别。那么我们需要通过某种方法吧这个过程的包提取出来。

提取关键数据

我是用的方法是通过记录2次img请求到达时间，提取中间的抓到的数据包进行分析。对应上述的过程，则是：

1. 不使用代理的步骤 2、3、4、5

2. 使用代理的步骤 3、4、5、6、7、8

这时就会发现，关键的点就是 302 header对应的ack应答包已经后续的 302img request。其到达时间间隔则可以视为客户端到代理的延迟。

相比TLS握手优点

1. 由于302图片依然可以在https协议下运行，因此，一个302图片可以至少得到2次检测机会

2. 302图片可以发起多次请求，在一次检测结束后，在重复加载图片可以在得到一次数据

3. 由于http2和http/1.1会话复用，页面多次刷新触发的302图片会让结果更接近真实情况

demo

proxy guess demo