-
Notifications
You must be signed in to change notification settings - Fork 775
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add bandwidth, duration, and re-use limits to access keys, and choice of protocol #32
Comments
I've noted your request for limits. Could you explain why you would like to impose these limits? Also, could you explain why you prefer that encryption algorithm? Thank you. |
Now, shadowsocks suggest use following AEAD cipher
And following cipher is marked as DO NOT USE
Sometime we need some enterprise level function (e.g. user account, original ss just provide a password for every user). When it born, ss is just a encrypted socks proxy for single user. After we found it's power, we started use it establishing tunnel(for multiple users). Then we have some problem. |
I see the following asks:
@wnxkiwi Could you give more context on how those features are useful? What's the problem you are trying to solve? |
@bemasc ok , why i wanna a feature。Well, for the limited time, the need to limit the ability to connect to devices and limit the connection time is due to the fact that many times a person uses a server to build shadowsocks that are too extravagant. One person will not use all the traffic at all, so we will share .However, when we share with our friends, there is no guarantee that they will not share their friends with friends indefinitely. This will cause bandwidth congestion and the speed will become very slow. It is precisely because of this that the above functions are needed. . |
i also want to limit the bandwidth, someone using youtube or netflix will just occupy too much bandwidth. |
I also noticed that there are no device limits on shared keys. I would like to add this feature too for the above mentioned reason: sharing the server with friends but not being able to "stop the spread" at all. |
how about adding management of multi cloud instances? for example, if I have one instance from google cloud, one instance from aws and one instance from vultr all managed under the same manager software? |
This feature is being added in 1.2.0 and is not relevant to this issue at all. Please refer to #78 for more info. |
Any update on adding bandwidth limits, number of user per key, connection duration? |
@code243 could you clarify why connection duration is useful? On the bandwidth limits, do you need something like bytes per month or bytes per second? |
Thanks for your reply.
By duration, I mean the amount of time a person can use the server. Like 1
month, 2, 3,...
On bandwidth limit, I mean bytes per second.
I would like to set it to 2Mbps per user.
Thanks
…On Wed, Dec 5, 2018, 8:54 AM Vinicius Fortuna ***@***.*** wrote:
@code243 <https://github.com/code243> could you clarify why connection
duration is useful?
Do you mean the duration of a single TCP connection, or the amount of time
a user can use a server?
On the bandwidth limits, do you need something like bytes per month or
bytes per second?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#32 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ArX2XxKaXwDfQH45X56qd7Ujd6_7S9rLks5u1947gaJpZM4S4Xlf>
.
|
As a workaround for the duration, you can set a timer and then call the API to delete the user: I can't think of a workaround for the bandwidth. That will have to be implemented in our shadowsocks backend, specially as we move to a single port for all users. |
Nice,
I will check the API shortly
…On Wed, Dec 5, 2018, 9:24 AM Vinicius Fortuna ***@***.*** wrote:
As a workaround for the duration, you can set a timer and then call the
API to delete the user:
https://github.com/Jigsaw-Code/outline-server/tree/master/src/shadowbox#access-keys-management-api
I can't think of a workaround for the bandwidth. That will have to be
implemented in our shadowsocks backend, specially as we move to a single
port for all users.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#32 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ArX2XxQX4kpKZTpLFbd9SZfoG7pI3Uvxks5u1-UhgaJpZM4S4Xlf>
.
|
@fortuna is it possible to add this feature? If not, is there a workaround? My use case like is like for others - stopping the spread. |
We are looking into implementing quotas in the server manager. We are considering having a sliding window mechanism, where all you need to specify is the window size and the maximum amount of data allowed. So you would specify things like: Allow at most 100 GB per 4 weeks for each access key. In that case the server would be continuously querying the amount of data consumed in the past 4 weeks and checking against the quota, enabling of disabling the key. The window units could be days or weeks, so you could specify a daily quota, for example. Maybe we can add months, but that's trickier, since months have different days. @ ALL: Would that address your data quota needs? |
Sounds good to me! |
@MerdanK @helnokaly Is your concern over use? Would data limits address your concerns? If not, what's your need that is not being met? |
Maybe the "limits number of devices" is the same thing as concurrent use? For example 1 key can only be used on X number of devices at the same time? I do think concurrent use limits is very important for both security and data use.... but is this the same thing that @MerdanK @helnokaly are talking about? |
@fortuna as i requested and understood from @MerdanK and @helnokaly i don't know also if you can restrict key per device so the provided key can work only on one device (based on one of the following IMEI / Adnriod ID / IOS ID / GSM number/ Device ID) |
@fortuna having data limits is good but is not enough. I may want to give a user a generous amount of data bandwidth limit, but I don't want him to abuse that by sharing his key to 100 other users. There is also the possibility of a denial of service by using a single key to use a lot concurrent connections without exceeding data limit. |
This is possible, not using a device ID tho. That would leave unsafe logs on the server. Maybe a hashed one, or better a randomly generated one that both the device and the server know. |
Yes, you understood me correctly. Even more. |
we now have bandwidth usage limit, any updates on concurrent users using one access key? |
@ercxar We are currently doing design work for what an access key sharing feature would look like, including ideas about what controlling re-sharing might look like. |
Notice that it's a bit difficult to enforce concurrent users, since the protocol's notion of user is an access key, and people reshare access keys broadly. We could limit the number of IP addresses that can use the key within a time window. But keep in mind that a single user can change IPs multiple times, by switching networks or requesting a new IP from their network. There are some tricky cases, such as a person walking around a campus, or a corporate office, and switching back and fourth between cell and wifi. Even though it's approximate, limiting the number of IP addresses may still be useful. For example, 2 IP addresses in 5 minutes seems reasonable for a single person with one mobile device. The hard thing is communicating how to pick the limit on the IP addresses, and that it's different from number of users (if you pick 1 you'll run into problems on mobile) A variation of the device ID approach could work. In that case the access key is really just to register the device and establish a secret. But then you've changed the protocol and are not backward-compatible anymore. That's ok, but it will prevent many Shadowsocks users from being able to use Outline Servers. |
yes, that's exactly why limiting concurrent users/keys is important. It is meant to stop resharing. It's a management challenge when 100 journalists share a key and one of those journalist's systems is compromised. Then we end up needing to issue individual keys to each journalist anyway until one or two get lazy and start sharing again and then we do it again>>> i've dealt with this both with other VPNs and with things as seemingly innocuous as door access. Limiting concurrent sessions knocks out the entire triad: confidentiality and integrity and availability. IP addresses work usually fine for relatively immobile devices, but your examples of walking across campus; moving between networks in an office; or even driving or being on public transit create problems. or an office of journalists logging in from the same IP address, each with 2+ devices.... So I think all of these are just short-term solutions until we actually limit concurrent keys. That is really the best way, and unless a much better method is devised it will ultimately be the safest way to implement.... |
I do not know how Outline servers works but I assume it keeps track of open connections, if we can associate these open connections with their related keys. I believe you can limit the number of open connections per a key? |
@helnokaly that open connections limit will be just shared by the users, no? @fortuna device ID is probably the best solution. |
@alashow If for example there is a limit of 1 connection per key, it is highly unlikely a user will share his key or otherwise he may not be able to connect to Outline while an other user is connected using the same key. That is good enough for my use case, and I believe that how it works with commercial VPN providers. |
I don't know much about DeviceID. Is this the MAC address, IMEI, Wifi ID or something else? Can these be easily captured by a MITM or an observer? If not, then perhaps it's a good way to stop concurrent use. |
Correct, many commercial providers use a radius database that monitors this. And it is the deterrent to sharing, you are correct. |
@helnokaly I thought you were referring to TCP connections, i.e 1 network request from the client = 1 connection
@thelonious89 Device ID depends on the device & implementation (it could be MAC, IMEI etc. or combination). If it's hashed, I don't think it would be useful to anyone |
I think it would be a very good approach to implement this idea. If you limit it to two concurrent IPs with a 5 minutes cool down (or even more) then it would eliminate any other errors such as the device ID approach. |
I think a point being missed here is that resharing is positive for many of our users as well. So any kind of concurrent use limiting should be able to be controlled by the admin. SIP002 allows extra metadata (we use outline=1 for this in our access key URIs), we could try to flesh out the concept of a limited key which in some way restricts sharing and access, and then let managers decide which key they want to issue, with limited and "unlimited" keys being differentiated by a metadata bit. So the flow would look something like
@fortuna I think this avoids any backwards compatibility issues, this looks the same regardless of if the client is Outline or not. |
So long as there is an option, it should be fine. My experience managing lots of users is that what's good for the user is not always good for the admin, and usually the admin needs to be the "parent" who controls the naïveté of the end-user. ;-) |
Since this bug was created, we added a data limit feature that applies to all keys. We have plans to have per-device keys. That's complex but we hope to have a robust solution in 2021 Q1. Bandwidth limits are on the table, but we haven't prioritized that yet. |
Since this issue is old and conflates too many things, I'll close it in favor of more focused ones:
/cc @cjhenck |
@fortuna I'm going to sell VPN to my customers. and I need to be sure that just 2 or 3 clients are using one access key. |
Do you release this feature until the end of May? |
@parsalotfy check this: #546 and please ask questions there. This issue is closed, no discussion here, please. |
The text was updated successfully, but these errors were encountered: