CERBERUS/outline-server
1
0
Fork 0
mirror of https://github.com/OutlineFoundation/outline-server.git synced 2026-05-13 13:58:57 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 3

Add info on blocking resistance

Browse source
This commit is contained in:
Vinicius Fortuna 2021-03-10 21:34:45 -05:00 • committed by GitHub
parent b193850304
commit 4ca4e0ee12
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 22 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

22
README.md
View file

@ -87,3 +87,25 @@ To clean up:
```
yarn run clean
```
## Shadowsocks Block Resistance
Shadowsocks used to be blocked in some countries, and because Outline uses Shadowsocks, there has been skepticism about Outline working in those countries. In fact, people have tried Outline in the past and had their servers blocked.
However, since the second half of 2020 things have changed. The Outline team and Shadowsocks community made a number of improvements that strengthened Shadowsocks beyond the censor's current capabilities.
As shown in the research [How China Detects and Blocks Shadowsocks](https://gfw.report/talks/imc20/en/), the censor uses active probing to detect Shadowsocks servers. The probing may be triggered by packet sniffing, but that's not how the servers are detected.
Even though Shadowsocks is a standard, it leaves a lot of room for choices on how it's implemented and deployed.
First of all, you **must use AEAD ciphers**. If you are using stream ciphers, you are doing it wrong. It's very easy to break your encryption and detect your server. Outline has banned all stream ciphers, since people copy old examples to set up their servers. In fact, Outline picks the cipher for you, since people don't know how to pick it. We also generate a long random secret for you, so you are not vulnerable to dictionary-based attacks.
Second, you need **probing resistance**. Both shadowsocks-libev and Outline have added that. The research Detecting Probe-resistant showed that, in the past, an invalid byte would trigger different behaviors whether it was inserted in positions 49, 50 or 51 of the stream, which is very telling. That behavior is now gone, and the censor can no longer rely on that.
Third, you need **protection against replayed data**. Both shadowsocks-libev and Outline have added such protection, which you may need to enable explicitly on ss-libev, but it's the default on Outline.
Fourth, Outline and clients using shadowsocks-libev now **merge the SOCKS address and the initial data** in the same initial encrypted frame, making the size of the first packet variable. Before the first packet only had the SOCKS address, with a fixed size, and that was a giveaway.
The censors used to block Shadowsocks, but Shadowsocks has evolved, and for now it's ahead again in the cat and mouse game.
Shadowsocks remains our protocol of choice because it's simple, well understood and very performant. Furthermore, it has an enthusiastic community of very smart people behind it.