[Suggestion] Replay-attack-detect enabled by default

[sstpe]

Looking at Cargo.toml, it seems like replay attack detection is not enabled by default. Is that correct?

Also, when I run sslocal and ssserver built with cargo build --features "replay-attack-detect", I see in the trace security: SecurityConfig { replay_attack: SecurityReplayAttackConfig { policy: Ignore } }. That's no different to what I see in the trace when I build without replay-attack-detect.

It's possible I'm misunderstanding, but it seems to me that by default there is no replay attack detection, and when --features "replay-attack-detect" is specified, the policy is unchanged (still ignoring replays). Am I correct?

If so, my suggestion is to enable replay attack detection, and enable it by default.

Thanks!

[database64128]

The current Shadowsocks protocol lacks a timestamp in its header. And you can't tell whether a message is client-to-server or server-to-client, since both types of message are encrypted with a session key derived from the same master key. Therefore, it's not possible to properly implement replay protection without changing the protocol. See #556 (comment).

[sstpe]

Thanks so much for pointing me to that discussion. It's a surprising conclusion given the recommendations I thought I remembered from the academic community. Maybe I'll have more questions, so I'll leave this issue open for now, but I'll be away for a couple days. Thanks again!

…

On Thu, Dec 23, 2021, 12:49 PM database64128 ***@***.***> wrote: The current Shadowsocks protocol lacks a timestamp in its header. And you can't tell whether a message is client-to-server or server-to-client, since both types of message is encrypted with a session key derived from the same master key. Therefore, it's not possible to properly implement replay protection without changing the protocol. See #556 (comment) <#556 (comment)> . — Reply to this email directly, view it on GitHub <#729 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWTZSAWK6SGSU3G3G2X72PLUSNOIXANCNFSM5KVGKV7A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[sstpe]

Okay, after reading that discussion and some related ones, I noticed that there wasn't really a lot of consensus from the community at large about how to handle this, despite the issue having gone quiet for a while. I'm sure I may have missed a thread or two, but I read through net4people/bbs#58 (which still recommends nonce and timing-based replay attack prevention), shadowsocks/shadowsocks-org#183, the thread you sent, plus some discussions here and there.

Is Outline still using a replay filter? Is there consensus and/or recent work to refine the protocol I've missed?

Is it fair to say that we're still not sure the best ways to mitigate the theoretical replay attacks, but right now we're doing well enough, so for now it's a non-issue?

Thank you for your insight.

By the way, mostly out of curiosity, does that mean that shadowsocks/shadowsocks-windows#3118 is not an issue any more?

[zonyitoo]

Is Outline still using a replay filter? Is there consensus and/or recent work to refine the protocol I've missed?

Outline only have replay filter for TCP relays.

To make a conclusion, the community have found that the bloom filter based replay filter doesn't help to prevent probing from attackers. On the other hand, shadowsocks is a "fast tunnel proxy", so replay detection should be handled by upper level protocols, for example, TLS.

[sstpe]

To make a conclusion, the community have found that the bloom filter based replay filter doesn't help to prevent probing from attackers. On the other hand, shadowsocks is a "fast tunnel proxy", so replay detection should be handled by upper level protocols, for example, TLS.

So, the suggested replay attack mitigation is using shadowsocks-over-TLS? Or are you saying that because most shadowsocks traffic is going to be TLS-over-shadowsocks, replay detection is already handled sufficiently?

Does this mean that the only mitigations we have now compared to when How China Detects and Blocks Shadowsocks was released are:

• Consistent server reaction to probes (see page 9), since shadowsocks-libev v3.3.1 and outline v1.0.7
• Always using AEAD ciphers

Is that correct?

Thanks!

[zonyitoo]

You don't need to add any obfuscation on shadowsocks, because nearly all your application requests are using TLS. If the attacker replays your data stream, then the TLS request must be rejected by the target servers.

[sstpe]

Makes sense. Is my understanding correct that AEAD ciphers and consistent server reactions to probes have been good enough? Were there other developments I'm not thinking of? Just want to make sure I understand :)

[zonyitoo]

The community has some ideas about how to improve the protocol, but currently there is nothing making progress.

Closing because it seems that the issue have been resolved.

[sstpe]

OK, thanks for answering my questions, @zonyitoo! Agree to close.