A possible attack to detect AEAD algorithms about shadowsocks-org HOT 20 CLOSED

from shadowsocks-org.

This is not a weakness of AEAD ciphers, but rather server implementation's behavioral characteristics.

It's trivial for the server to identify such probing attempts. Either add random delay before closing, or keep accepting more bytes till sender disconnects.

from shadowsocks-org.

Name an encrypted protocol that won't behave differently when the content is modified then I'll tell you how to solve this issue.

from shadowsocks-org.

@wongsyrone

我有个问题，你怎么从其他未知加密协议中区分出用了AEAD的SS的？如果区分不出来，随便发现流量就尝试一番吗？

I think unknown encryption protocols and connections only take up a little proportion of all protocols and connections. Most connections will use known and detectable protocols, such as HTTPS, SSH, IPSec, etc. So I think unknown encryption protocols themselves are patterns. Actually in this case, I think HTTPS is safer to be used to bypass the wall. Just do some tricks on the certification.

from shadowsocks-org.

@Mygod

As I've mentioned before, server should null route the connection instead
of closing it when the incoming packets seem malicious.

Oh, I haven't thought of that. It's a great idea.

from shadowsocks-org.

检测到被修改的数据以后保持连接这个做法本身也是特征，一个正常的加密协议不会在明知数据被篡改的情况下依旧保持连接的（因为会占用服务器资源，理应尽早断开，当然如果你想伪装成自己装了个应用层防火墙的话... 那倒是也可以）。如果是避免被检测应该从obfs角度入手，伪装成常见流量。AEAD本身只是防篡改，并不是为了隐藏自己是个加密协议。

from shadowsocks-org.

@Noisyfox @Mygod

检测到被修改的数据以后保持连接这个做法本身也是特征，一个正常的加密协议不会在明知数据被篡改的情况下依旧保持连接的（因为会占用服务器资源，理应尽早断开）。如果是避免被检测应该从obfs角度入手。AEAD本身只是防篡改，并不是为了隐藏自己是个加密协议。

So how to hide from being detected as well as being modified?

from shadowsocks-org.

Either add random delay before closing

That's a possible solution. Or we could follow pattern of the protocol we are pretended to be, like HTTPS.

There may be some more costly ways, such as randomise the packet boundary (eg. the boundary of our chunk is not aligned with the tcp packet boundary) so the gfw won't be able to replay the tcp chunk (but with more delay and use more bandwidth).

from shadowsocks-org.

I propose using AEAD public key cipher. For connection we generage a new key pair, so the wall will never be able to replay TCP Chunk.

from shadowsocks-org.

Then you need to pay extra attention to the packet pattern since you may need some sort of handshake which involves some fixed size packets right after the tcp connection is established.

from shadowsocks-org.

Use non-fixed-length garbage data. And encrypt it to avoid modification.

from shadowsocks-org.

I have written a protocol. I can show you later.

from shadowsocks-org.

Anyway, I am going to release my pipesocks protocol here. It does not solve the problem mentioned in this issue. (about modified replay attack)

Header Structure

+-----+-------------------------+-------+-----+--------------------------------+-------+
| MAC | encrypted header length | nonce | MAC | encrypted garbage + public key | nonce |
+-----+-------------------------+-------+-----+--------------------------------+-------+
| 16  |            2            |  24   | 16  |       header length - 82       |  24   |
+-----+-------------------------+-------+-----+--------------------------------+-------+

Both are encrypted by secret key cryptography (XSalsa20). The secret key is password + 0x98 (filled to 32 bytes).
MAC is Poly1305.

Packet Structure

+-----+-------------------------+-------+-----+--------------------+-------+
| MAC | encrypted packet length | nonce | MAC |   encrypted data   | nonce |
+-----+-------------------------+-------+-----+--------------------+-------+
| 16  |            2            |  24   | 16  | packet length - 82 |  24   |
+-----+-------------------------+-------+-----+--------------------+-------+

Packet length is encrypted by secret key cryptography (XSalsa20). The secret key is password + 0x98 (filled to 32 bytes).
Data is encrypted by public key cryptography (XSalsa20).
MAC is Poly1305.

from shadowsocks-org.

Actually I have discussed this kind of attack in #30 .
For defending replay attacks, we have a thread #44 to discuss on it.

I do not think random padding could be a good idea since it must have certain statistical properties.

from shadowsocks-org.

from shadowsocks-org.

from shadowsocks-org.

We should still use obfs, in my personal sense, give the server a fake HTTPS certification, and open the port on 443.

from shadowsocks-org.

For normal HTTPS connections, return a fake website.

from shadowsocks-org.

@yvbbrjdr If GFW replays it immediately, we will discover the duplicate in the IV/salt cache.

@Mygod
A pattern of protocol A + An evidence that this is not real protocol A -> Shadowsocks
No pattern of any protocols -> Unknown service, maybe a shadowsocks
In the first case it is causality. In the second case it is probability.
However, of course it is better that we have plenty of plugins to make the diversity and the winner survives. It seems that they do not block unknown services out but do some QoS.

from shadowsocks-org.

@shinku721 Theoretically it's always possible to detect if there is any suspicious payload in the underlying traffic. Our goal is to make it computationally more expensive. For example, active detection is more expensive than passive checking the packets going through. Stateful checks are more expensive than stateless checks. Also I still think ideally plugins should decide/design the behavior when a malicious packet is detected.

See also: steganography and steganalysis.

from shadowsocks-org.