Shadowsocks should send data along with header

[Mygod]

Currently, this implementation does handshake first, which is problematic for obfuscation, e.g.

shadowsocks-rust/src/relay/tcprelay/socks5_local.rs

Line 40 in 1204d58

let svr_s = match ProxyStream::connect(server.clone_context(), svr_cfg, addr).await {

[zonyitoo]

Hmm, IV is already sent with the first packet:

1. Client -> Server: target's Address
2. Server -> Client: the first response packet.

[Mygod]

Two connections should use independent IVs.

[zonyitoo]

Yes, they are.

[Mygod]

The first packet should contain the header/handshake as well as actual payload.

[zonyitoo]

Hmm, then the ProxyStream should store the Address and send it with the first write call.

[Mygod]

CC @madeye to double check on this.

[zonyitoo]

Made a simple but a little bit ugly solution.

[Mygod]

This should also be done at the server side as well -- https://github.com/shadowsocks/shadowsocks-rust/blob/806f44244af1366323d69a2abed3a530838ab264/src/relay/tcprelay/aead.rs

[zonyitoo]

Server side doesn't have a handshake packet.
The first data response is sent with IV.

[Mygod]

Cool just double checked via tcpdump and can confirm that both sides are doing it correctly with 45a3469.

[Mygod]

@madeye Maybe we should include this in official doc as well?

[madeye]

Yeah, we should do that.

[Mygod]

@madeye Updated at https://github.com/shadowsocks/shadowsocks-org/wiki/Protocol

[madeye]

Hmm, this fix caused another problem: shadowsocks/shadowsocks-android#2621.

We'd better have a delay control to send out the header, even if there's no data. Some underlying protocol requires this behavior like FTP.

[zonyitoo]

Well, it would be quite tricky to do that in a Future based server... But it should be able to do.

[madeye]

Yes, I tried to implement this myself at first, but found it's not easy.

[zonyitoo]

I am currently working on #326 . This issue will probably have to be fixed after #326 being done.

[Mygod]

Considering this only covers a few use cases like FTP, maybe it is better to have a timeout of maybe 500ms, and an option to turn off this behavior (default on).

EDIT: Or a configurable timeout defaulting to 500ms, 0 indicating not waiting...

[madeye]

A fixed 500ms timeout looks good enough.

Given most of protocols today let client send the request first, I don't think we would see header only handshakes often.

[zonyitoo]

This 500ms is only applied on the client side: client -> remote. The other side of the tunnel on servers can still wait for the first response from the target remote servers.