Will the use of predictable passwords lead to predictable packets?

[cbeuw]

Hi, author of Cloak here.

I have always advised my users that they do not need to enable traffic encryption in Cloak if the underlying proxy does a sufficiently good job in making their traffic appear random (disregarding side-channel behaviours such as packet timings). Shadowsocks was used as the primary example for this use case: cbeuw/Cloak#144. Information which Cloak uses to establish and maintain its connections are always encrypted, regardless of traffic encryption settings.

However, recently a user had issues with Shadowsocks+Cloak being detected. Two things were done which fixed it: 1. Changing Cloak's handshake signature from Chrome to Firefox, and 2. Enabling Cloak's own encryption of Shadowsocks' traffic. Shadowsocks was using chacha20-poly1305 but the password was set to "testing".

I know this isn't a very good sample, as two variables were changed at once. It's well possible that the browser signature exposed Cloak, as this has happened with my Iranian users early this year: the signature for Chrome 68, which Cloak uses, appears to have been completely blocked (even with a real Chrome 68), though Firefox's signature remain unaffected. But I think it's unlikely to be the case here, as I have since updated the signature to align with a fairly recent version of Chrome.

The other possibility would be due to the weak password in Shadowsocks' configuration. Of course, if Shadowsocks were exposed to the internet, the weak password would make it trivially detectable via active probing, but that wasn't the case here as it was listening on loopback. So I'm worried that the censor might have been able to identify Shadowsocks' traffic as one configured with a common password. I'm completely unfamiliar with Shadowsocks' protocol so I'm seeking advice here. Does Shadowsocks commence a key exchange prior to validating the password which could be sent encrypted, or is the password used to seed a potentially predictable or deterministic shared secret? If it were the latter case, then I'll need to change some of Cloak's behaviours.

Thanks in advance

[madeye]

With salts and IVs, I don't think there's any predictable payload from shadowsocks.

Recently, we see more and more studies on traffic analysis [1]. But that's just the problem that Cloak aims to solve.

[cbeuw]

Thanks for the reply. I agree that, with the entropy injected by random salts and IVs, the payload should appear statistically random for most modern crypto schemes (https://moderncrypto.org/mail-archive/noise/2018/001458.html). However, if the cryptographic key was ultimately derived from the shared static password, then someone could simply decrypt the data stream by guessing that password (which was what I thought happened).

The way around this is by doing a key exchange in the beginning, completely independent from the static password, then encrypt the password using that shared secret to authenticate the user. This won't avoid active probing as the attacker could simply do their own key exchange and then guess the password, but that can't be done if Shadowsocks is hidden behind Cloak or other plugins.

With key exchange there's also the issue with the public keys potentially being distinguishable from random, something I literally just learnt that applies to elliptic curves (https://eprint.iacr.org/2013/325.pdf), plus maybe most Diffie-Hellman groups (https://en.wikipedia.org/wiki/Decisional_Diffie%E2%80%93Hellman_assumption#Groups_for_which_DDH_is_assumed_to_hold the multiplicative groups with prime order part). But I don't think this is something being leveraged by the censors now.

[riobard]

Key exchange will lead to more identifiable traffic patterns which is why we stick with shared secret. It's much easier to just use stronger passwords (e.g. random 30 chars).

[rurirei]

do you ask for forward-secrecy?

#157 (comment) and #177 #178