> how does something like this work against DPI? i guess not great? No, it's pretty good. Think about it: all DPIs can see is an ordinary https connection. Sin

> how does something like this work against DPI? i guess not great? No, it's pretty good. Think about it: all DPIs can see is an ordinary https connection. Since the traffic itself is encrypted, to discriminate this from normal web browsing the DPI device can only depend on metadata. Classic moves are: 1. Packet length pattern for TLS-in-TLS. 2. TLS fingerprinting. The first could be defeated by adding padding to the first few packets of each of your connections. [1] The second.. someone built a socks5 <-> https CONNECT proxy client [2] out of Chrome's codebase, which means it shares all the fingerprint with Chrome and you really can't tell. [1] https://github.com/klzgrad/forwardproxy/commit/2350f380f8db2451528863fd12aeed3d3d06ec65 https://github.com/klzgrad/forwardproxy/commit/2350f380f8db2... [2] https://github.com/klzgrad/naiveproxy https://github.com/klzgrad/naiveproxy