3 ms·
The strategy used to detect "Fully Encrypted Traffic" is indeed complex, but the protocols investigated by the paper (at least Shadowsocks, VMess. Not really su
by nirui 3y ago
The strategy used to detect "Fully Encrypted Traffic" is indeed complex, but the protocols investigated by the paper (at least Shadowsocks, VMess. Not really sure about Obfs4) works by transforming the traffic to make it "look like nothing".
So I still believe "High Entropy" is a better description than "Fully Encrypted Traffic".
I mean, you can pack the entire data stream in Base64 after sending them through a SHA256 pipeline, and it will still be "Fully Encrypted", but the entropy (in terms of traffic classification by content scanning) is not the same compare to doing it without the Base64 step.
- luke-stanley 3y agoYes, "High Entropy" or even "HighE" is a more accurate than "Fully Encrypted Traffic". It's interesting that the filter was observed to operate at specific ranges of entropy in the paper, and the repo has it mostly reproduced here: https://github.com/apernet/OpenGFW/blob/1dce82745d0bc8b3813aea147954ba3a2294ef30/analyzer/tcp/fet.go#L46 https://github.com/apernet/OpenGFW/blob/1dce82745d0bc8b3813a... But presumably to keep people on their toes, the real filter, only operates some of the time. It be a cursed, "hex ensemble".
- nirui 3y agoCorrection: instead of `SHA256`, I've should typed `AES256`. The last time when I wrote any encryption, it was still back in 2019... that's why I lost it... Sorry :)