|
S: ServerHello, Certificate, ServerHelloDone (67+858+9 bytes)
C: ClientKeyExchange, ChangeCipherSpec, encrypted Finished (267+6+53 bytes)
S: NewSessionTicket, ChangeCipherSpec, encrypted Finished (207+6+53 bytes)
C: encrypted ApplicationData #1 (37+197 bytes)
S: encrypted ApplicationData #2 (37+693 bytes)
(旁注：ApplicationData 记录分成了两部分，第一部分 37 字节，这是为应对 BEAST 而做的 1/n - 1 记录分割）
这里有一个 TCP 握手，一个 TLS 握手，一个从客户端发送的，大约 200 字节的加密 ApplicationData 记录（HTTP 请求），以及一个从服务端发送的，大约 700 字节的加密 ApplicationData 记录 （HTTP 回应）。这个 TLS 交换和流量模式类似于一个未经代理的 HTTPS 连接，因此 GFW 无法检测到它是一种翻墙技术。
不幸的是，一旦我开始通过我的代理浏览 HTTPS 站点，GFW 就能检测到了并应之以大量的丢包... 它是怎么检测到的呢？
想法 4
通过一个安全代理浏览 HTTPS 站点会有两层 TLS：外层 TLS 连接到代理，内层连接到站点。我推断 GFW 能够猜测出加密的 ApplicationData 里隐藏了一个代理 CONNECT 请求和另一个 TLS 握手。如下为通过代理运行 "curl --head https://www.google.com" 是的抓包结果：
- C: TCP SYN to proxy
- S: TCP SYN+ACK reply from proxy
- C: TCP ACK
- C: ClientHello (86 bytes)
- S: ServerHello, Certificate, ServerHelloDone (67+858+9 bytes)
- C: ClientKeyExchange, ChangeCipherSpec, encrypted Finished (267+6+53 bytes)
- S: NewSessionTicket, ChangeCipherSpec, encrypted Finished (207+6+53 bytes)
-
4/9 首页 上一页 2 3 4 5 6 7 下一页 尾页
|
