关于随机长度填充的讨论 about shadowsocks-org HOT 17 CLOSED

Why do we need this?

from shadowsocks-org.

I followed a layered approach in go-shadowsocks2. Currently it involves the following layers:

1. Protocol Layer deals with addressing using the SOCKS5 address format. Currently this layer is very thin, and it's actually implemented in client/server application logic. Further development should put features like multiuser here.
2. Security Layer deals with encryption using either the original stream ciphers or the new AEAD ciphers.
3. Obfuscation Layer (via SIP003 plugin; work-in-progress) deals with countermeasures against traffic analysis.

Each layer wraps the layer above it. Ideally each layer should not assume anything above or below it.

The layered design has the benefit that each layer can be changed independently without touching other layers.

The layered design has the drawback that some overhead must occur. For example, random padding implemented at the Obfuscation Layer must split the stream from Security Layer into chunks, even if the Security Layer uses AEAD ciphers with its own framing method.

I think the drawback is worth it for the design to stay clean and simple.

from shadowsocks-org.

@breakwa11 你可能需要解释一下为什么你觉得不应该在 obfs 里面做，才能让人理解这样做的合理性／必要性，才有展开讨论的可能。只有结论并不能有效传达你的设计理念。

from shadowsocks-org.

我个人觉得有必要而已，我自己实现了这个都快要两年了。我想知道的是你怎么看的，你觉得没有必要还是什么原因？

from shadowsocks-org.

我不知道哈，先问下填充的目的是？

from shadowsocks-org.

私下和riobard讨论了一下，他想法是把这块做在obfs而不想动协议，所以 @madeye 你的想法呢？

from shadowsocks-org.

Same here.

from shadowsocks-org.

Any feature requires a purpose. "Why don't we have this" is not a valid question unless there is obvious, consensual reason for it. In this case, the purpose of random padding is anything but obvious, let alone consensual.

Ideally, data security and connection security should be separated, which is also why SIP002 designed the plugin protocol that way. If the proposed random padding - whose purpose has yet to be explained - only serves connection security and offers no additional data security (protection against interception or even manipulation of data), then it should naturally go where connection security is supposed to go - in a plugin.

from shadowsocks-org.

I think it's not necessary if we don't use handshakes.

from shadowsocks-org.

It's still possible to extract limited information such as "likely to be HTTP over ???", "likely to be HTTPS over ???" or "likely to be OpenVPN over ???" even if there are no handshakes, though it is quite expensive to implement those attacks.

However, most users' threat model doesn't contain such attacks (and people do have a good reason). It is only necessary for very few people and would be better done in plugins.

from shadowsocks-org.

unless there is obvious

因为我确实觉得这应该是显而易见需要这么做的，所以我很早就做了这个
另外这个不是 connection security 吧？

另外你们都觉得做在obfs plugin里？难道只有我一个人认为不应该吗？我咋觉得obfs不是做这个的地方，明文的地方放一大堆这种数据难道不会被发现？

from shadowsocks-org.

但是我已经说了的呀

明文的地方放一大堆这种数据难道不会被发现？

我表示我水平所限不知道如何在obfs里实现

from shadowsocks-org.

A naive implementation of random padding at the Obfuscation Layer:

1. Split the data stream into chunks.
2. Prefix each chunk with two fields: length of data in the chunk (2-byte LenData), and length of padding bytes (2-byte LenPadding).
3. Send [*LenData*][*LenPadding*][Data][Padding], where *LenData* and *LenPadding* is encrypted by a stream cipher to obfuscate their purpose.

from shadowsocks-org.

噫，又是这么污的方法，又一层额外的加密（如果把data和padding都加密了，那就等同于在obfs把SS重新实现一个，那SS的core就毫无存在感了，咱就可以高呼万能的obfs**之类的），总感觉至少还得校验一下，不然又是留下可探测的可能。算了，等真的打算具体实现这种obfs要讨论实现的时候再说吧

from shadowsocks-org.

Data is already encrypted in the Security Layer. Padding is randomly generated, and there's no need to encrypt it.

Of course you can insist that the Security Layer and Obfuscation Layer should be merged into one to avoid the extra framing overhead. It'll be a very good reason IMO. It's just a different design philosophy with tighter coupling.

The idea behind SIP003 is that we need different obfuscation strategies in different scenarios, and it would be unwise to mix security needs (which is more common in those scenarios) with obfuscation needs.

from shadowsocks-org.

Also, the Tor project has already created several obfs plugins. We'd like to reuse those without re-implenting everything from scratch. That's also part of the reasons behind SIP003 AFAIK.

from shadowsocks-org.

Locked due to trolling posts.

from shadowsocks-org.