3 ms·

how does something like this work against DPI? i guess not great? >Don't use this in situations where your personal safety or freedom could be at risk https:/

how does something like this work against DPI? i guess not great? >Don't use this in situations where your personal safety or freedom could be at risk https://theintercept.com/2020/12/06/kashmir-social-media-police/ https://theintercept.com/2020/12/06/kashmir-social-media-pol... https://thewire.in/media/kashmir-journalist-auqib-javeed-police-assault https://thewire.in/media/kashmir-journalist-auqib-javeed-pol... reason why i have a general disregard for technologies that are based on some sort of "link" AFK, phone number or the stupid facebook real name policy. this is as of today being used to crack down on dissent. what you are saying is true but https://thenextweb.com/in/2020/01/08/kashmirs-police-want-people-to-register-their-whatsapp-groups/ https://thenextweb.com/in/2020/01/08/kashmirs-police-want-pe... when you have your govt do this, how can you keep your signal account private? your phone is already listed. isnt it? cant the police see if you are on signal and if online means you are bypassing them somehow regardless of what you might be saying?

rfoo 6y ago
> 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

rfoo 6y ago

> 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