Open riobard opened 7 years ago
Here some personal thoughts:
Who are the users?
Servers: Geeks. Clients: Any user that wants to circumvent censorship or improve privacy.
Why andhow do they use our software?
Set up shadowsocks themselves on public cloud services. Use his/her service privately or share it with a small group of people.
Who are the adversaries?
Mostly DPI based adversaries.
Why andhow do they attack the users?
Identify and block IPs.
How do we differ from other similar projects (e.g. OpenVPN and Tor)?
Nothing special actually, IMO, the ease of use, low-end-device-friendly and rules (URL/hostname) based policy routing are the best parts of shadowsocks.
I'd like to expand on @madeye's response regarding the adversaries.
In general, we do not expect the adversaries to do precise targeting of any particular client or server IP, in which case the affected user is unlikely to survive active attacks.
Additionally we expect the adversaries to be well-funded but still cost-conscious. The corollary is that the adversaries' budget per capita is limited due to the massive amount of traffic in need of DPI analysis, i.e. the adversaries will not spend too much resource over-analyzing each packet.
@riobard I disagree. We absolutely should expect the adversary to engage in precise targeting against individual users, and we should be willing and able to make sure that SS withstands such attacks - the way TOR aims to do. Why would SS strive for anything less?
Yes, in practical terms, a user under a state-level all-out attack will be breached one way or another with certainty - but we should aim to make sure that SS not be the weakest point where the attack comes through.
Shadowsocks will not be the weakest link in such cases as there are so many other things could go wrong :P The simplistic nature of Shadowsocks does not allow protection of users from active attacks sponsored by state-level players. They should use other tools like TOR instead or in addition to Shadowsocks.
Some amends for @madeye reply
how do they attack the users?
Identify and block IPs.
Beside this attack, they can block the special port of that ip for a while (an hour for example), which cause few false positive. I've a 443 port obfs as tls and redirect to 8443 (real nginx ssl), and one day that 443 is blocked from my isp, but 8443 and ssh port is still accessible. and from other vps inside GFW, port 443 is not blocked.
Assume long-time massive concurrent connections from one domestic IP to a single oversea IP will trigger the GFW. Can we create a protocol turns network quota (and quality) into some kind of currency ?
For example, shadowsocks service provider ServiceA create his own currency CoinA, i.e. network quota, it gives a amount of CoinA to it's end-user User1@ServiceA. User1@ServiceA can also spend CoinA with ServiceB as long as ServiceA and ServiceB have some kind of trust agreement.
At first, this trust agreement can be negotiated manually, but it's possible to create a automatically negotiation system.
A newly created provider ServiceC may have a lower trade exchange rate, as long as it gains enough trust by other services, it's exchange rate may raise to normal rate, that is 1:1.
This result is, if you host a shadowsocks ServiceZ and join this protocol, you can have plenty of IPs that you can connect with, and other people can also use your IP.
As long as massive concurrent connections from one domestic IP to a single oversea IP turns into various domestic IPs connect various oversea IPs, It will be very hard for GFW to identify and block.
@unit2b Interesting idea. Measurement of trust level remains a challenge. Unlike Tor, SS requires users' absolute trust in service providers because service providers can decrypt and monitor traffic flow.
Once trust issue is addressed, we can probably create a decentralized peer network where anyone can contribute public servers under her control to route traffic and earn income in the form of consumed coins.
@unit2b There may be two problems in this model:
@JollyTRjano I think this can only work with a single provider, or a small group of providers who trust each other. Or the protocol must only allow the trusted provider to become the exit. (And still this will leak the relationship between the user and the provider.)
a protocol turns network quota (and quality) into some kind of currency
你这种体系不适合翻墙
但是协商和握手是在初始设计的时候就没有考虑的东西。另外p2p网络,例如Tor,一旦有了蜜罐节点,网络的崩溃也就是早晚的事情。
一个系统越复杂,找到攻击点越容易。
“一种是尽量简单,这样显然不会有什么问题;另外一种是,尽量复杂,这样没什么显然的问题。”
Who are the users?
Everyone who wants to evade internet censorship.
Why and how do they use our software?
It is more reliable and fast. Run shadowsocks on both a server and a local machine.
Who are the adversaries?
Great firewall of china.
Why and how do they attack the users?
GFW can attack the users mainly for identify whether a shadowsocks is running on the server.
To my opinion, ip blocking is not a attack, it's a consequence of attacks such as traffic identification(passive) or active probing(active).
These attacks are more obscured so there are no direct evidence.
How do we differ from other similar projects (e.g. OpenVPN and Tor)?
shadowsocks should be much more fast and hidden than VPN and Tor, thus more reliable.
I propose we document the Threat Model of the Shadowsocks project. The Threat Model should explain the scenarios to design for, and the assumptions about users, operators, and adversaries. It should help us better understand the goal of the project, and resolve conflicts and disputes in discussions.
At minimal, the Thread Model must answer the following questions (order does not matter):
This is a very rough proposal. Please comment for feedback.