Refine doc for OTA

[Mygod]

No description provided.

[Mygod]

Now why in the first place did we design our own authentication (which could have easily or already have gone wrong) instead of using authenticated encryption that has been tested, for example Salsa20-Poly1305 in NaCl, Chacha20-Poly1305 in Sodium or AES-256-GCM in both? (TODO: I'm just guessing that these have been tested or even academically proven. Are they really?)

I know there is a very old thread that has discussed this (shadowsocks/shadowsocks-chromeapp#1 (comment)) but the current OTA protocol also encapsulate every packet as well.

Another reason I've seen is performance (https://github.com/shadowsocks/shadowsocks/issues/330), which takes us back to the trade-off between security and performance. This is a valid argument but has anybody tested how much it will influence the performance? We should have some kind of benchmark to validate that. I contrived a script which works roughly as follow:

1. Listens on any port A, which copies from /dev/null endlessly to client sockets;
2. Get a packet from A, calculate connection delay t_1;
3. Keep getting b_1 bytes from A for T seconds;
4. Repeat 2-3 for N times;
5. Start a Shadowsocks client and a server that connects to localhost;
6. Connect to port A via Shadowsocks and get the first packet, calculate connection delay t'_1;
7. Keep getting b'_1 bytes for T seconds;
8. Repeat 6-7 for N times;
9. Calculate results.

Additional delay: average(t') - average(t)
Maximum throughput: average(b) / T
Shadowsocks throughput: average(b') / T

[v2ray]

My 2 cents for AES-GCM. Golang benchmark shows GCM (2.5gB/s) is 10 times faster than CFB(200MB/s). Despite other performance penalty in the pipeline, GCM should provide at least 1 gB/a throughout.

[madeye]

Unfortunately, the motivation of OTA is patching the existed shadowsocks' stream ciphers, in order to defend attacks to the shadowsocks server. It is only applied on the request packets and designed to be HMAC before encrypting, which cannot ensure IND-CCA2 actually.

So, maybe we should remove the IND-CCA2 part in the description. @Mygod

As mentioned by @wongsyrone, it's much better to follow existed AEAD instead of building the wheel ourselves. But shadowsocks is initially designed to be a simple and fast obfuscating SOCKS5 proxy with stream ciphers, And that's why we can implement it very easily and efficiently on the every known platform with different programming languages.

I'm OK with adding AES-GCM and chacha20poly1305 as new ciphers (AEADs), if it's really necessary.

[Mygod]

Reply to @wongsyrone: #29 (comment)

In that case should we add AES-GCM? (btw all your replies doesn't show up in my inbox, I wonder why)

@madeye Let's add them and do some benchmark. We'll see. If they are not much slower than stream ciphers, I don't see a reason not to use them.

[madeye]

@Mygod It requires quite a lot of changes. Maybe we'd do that in Python version first.

[Mygod]

So it seems that OTA was added just to counteract the attack proposed here. I still think it's possible to perform a similar attack (to detect a Shadowsocks connection) for a man-in-the-middle by sending repeated XOR-ed packets to client on a connection for the current OTA protocol since OTA isn't enabled for server-to-client connections. Closing this PR for now.

[madeye]

BTW, for benchmark, we can directly use https://github.com/lparam/xSocks. It's exactly a shadowsocks-like protocol based on salsa208-poly1035 with IND-CCA2.

[Mygod]

@madeye Benchmark for xSocks can give us an approximate idea of the final results but I still think benchmark for Shadowsocks is necessary.

@wongsyrone It seems IND-CCA3 is just to used to say that it's equivalent to AE. Correct me if I'm wrong, I think IND-CCA2 implies IND-CCA3 so NM-CCA2 (which is equivalent to IND-CCA2) implies AE.

P.S. Our invention of OTA (which isn't a bright idea) may have caused downstream ShadowsocksR to invent more authentication protocols by themselves (proof).

[madeye]

@Mygod The interesting thing is when I implement chacha20-poly1035 in shadowsocks-libev, it becomes xSocks... The two protocols are just identical.

[Mygod]

@madeye Are you implying we should have used xSocks all along? 😅

[madeye]

@Mygod You got it... That's just my plan. If one day stream ciphers are not enough for bypassing the firewalls, I would switch to the "right" implementations (well known AEADs).

However, I don't think any known attacks to shadowsocks protocol is realistic. And please don't forget that most of the traffic over shadowsocks is TLS...

[madeye]

@wongsyrone The attacks from breakwa11 mostly target to our implementations instead of protocol. She studied every implementation's handshake characteristic and perform replay attack to identify the server. However, the characteristic she is using is based on statistics and depends on specific implementations, leading to a very large false positive.

[Mygod]

I imagine a possible attack could be performed on keep-alive HTTP connections. And migrating to well-tested AEADs also reduces the risk of future/unknown attacks.

EDIT: Also Shadowsocks has a larger community and better community support than xSocks.

[madeye]

What about opening an issue with tags pull request welcome and long term? 😅

[madeye]

@Mygod And first create a SIP?

[Mygod]

Done. Go to #30 for further discussion.