Add bandwidth, duration, and re-use limits to access keys, and choice of protocol

[wnxkiwi]

 i wanna ask that would Outline-Server add some feature like speed limit, TL(time limit) of connecting , quantity of device limit？  From my opinion, it is very easy to add and integration. 
 And way of encryption of Shadowsocks could give us a right to choose? i more like ase-256-cfb. 

[bemasc]

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.

[ghost]

Now, shadowsocks suggest use following AEAD cipher

• aes-128-gcm
• aes-192-gcm
• aes-256-gcm
• chacha20-ietf-poly1305

And following cipher is marked as DO NOT USE

• bf-cfb
• chacha20
• salsa20
• rc4-md5

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.

[fortuna]

I see the following asks:

• Limit the speed of connections
• Limit the duration of the connections
• Limit the number of devices in a connection

@wnxkiwi Could you give more context on how those features are useful? What's the problem you are trying to solve?

[wnxkiwi]

@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. .
In addition, the reason I prefer aes-256-cfb is that I just like it. I don't know the encryption protocol and cryptography. Just like it, and he is more stable, in my three years in shadowsocks. The diversity of cryptographic protocols is good for breaking through cyber censorship.
I want to say something very interesting ~~ In China, yes China, GFW is very developed and smart, can identify and precisely block VPNs through traffic characteristics, such as IPSec, L2TP, Open VPN and so on. Smart clowwindy rewrites from socks5 to shadowsocks, because the traffic characteristics of shadowsocks are difficult to identify, so he is perfect for breaking the blockade. In the past few years, in China, shadowsocks have been able to commercialize, and commercialization is very mature, as I said that the above-mentioned functions have already been realized. And it is more diverse and diverse, satisfying people with different needs. But our country's genius programmers are under pressure from the government, and programmers who participate in and contribute to shadowsocks' various programming languages ​​and develop new cryptographic protocols are under pressure to delete the source code. Yes, this is a place where even programming is not free. If you can develop more cryptographic protocols and obfuscation protocols to counter the blockade, or to spawn more branches, or to create a whole new protocol, I think this is not only for journalists, but for those who are within the walls of the world. Good thing. I am very looking forward to Google's genius programmers would writing how perfect code.

[Simplici]

i also want to limit the bandwidth, someone using youtube or netflix will just occupy too much bandwidth.

[what-name]

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.

[superhero75]

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?

[NEXUS2345]

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.

[code243]

Any update on adding bandwidth limits, number of user per key, connection duration?
It will be nice to add it to the manager or have a type of web interface to control everything.

[fortuna]

@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?

[code243]

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> .

[fortuna]

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.

[code243]

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> .

[alashow]

Limit the number of devices in a connection

@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.

[fortuna]

We are looking into implementing quotas in the server manager.
We would like to implement the simplest possible solution that fully meets the needs of server admins.

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?

@cjhenck @alalamav FYI

[alashow]

Sounds good to me!

[fortuna]

@MerdanK @helnokaly Is your concern over use? Would data limits address your concerns? If not, what's your need that is not being met?

[thelonious89]

@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?

[baseloo]

@fortuna as i requested and understood from @MerdanK and @helnokaly
for each key there is only one session will be allowed , that is meaning if someone use the key and connected no one can use the same key to connect at the same time cause the session is used so. for each key only one session allowed.

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)

[helnokaly]

@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.
Generally I want to discourage users from sharing keys.

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.

[what-name]

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 / Android ID / IOS ID / GSM number/ Device ID)

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.

[xmerdank]

@fortuna as i requested and understood from @MerdanK and @helnokaly

Yes, you understood me correctly. Even more.

[ercxar]

we now have bandwidth usage limit, any updates on concurrent users using one access key?

[JonathanDCohen]

@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.

[fortuna]

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.

[thelonious89]

people reshare access keys broadly

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....

[helnokaly]

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?

[alashow]

@helnokaly that open connections limit will be just shared by the users, no?

@fortuna device ID is probably the best solution.
If it's implemented as an optional feature (enable or disable for all users / per user), could it made backward-incompatible only for users/keys with the feature enabled? i.e keys are backward compatible if the user/key was not device count limited.

[helnokaly]

@helnokaly that open connections limit will be just shared by the users, no?

@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.

[thelonious89]

@fortuna device ID is probably the best solution.
If it's implemented as an optional feature (enable or disable for all users / per user), could it made backward-incompatible only for users/keys with the feature enabled? i.e keys are backward compatible if the user/key was not device count limited.

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.

[thelonious89]

@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.

Correct, many commercial providers use a radius database that monitors this. And it is the deterrent to sharing, you are correct.

[alashow]

@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.

@helnokaly I thought you were referring to TCP connections, i.e 1 network request from the client = 1 connection

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.

@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

[ercxar]

@fortuna

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)

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.
This way you can define an access key for each device instead of each user. This way it would eliminate other issues simultaneously. It also gives you a better understanding of user usage. Specially in a situation that @thelonious89 mentioned, this way you only need to define access keys for each device once and limit the concurrent IPs only because of the situations such as mobile devices who switch between WiFi/Data.

[JonathanDCohen]

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

1. user1 with key 1 connects through the server
2. user2 with key 1 attempts to connect through the server but the server, upon discovering that this is the same key, refuses the connection.

@fortuna I think this avoids any backwards compatibility issues, this looks the same regardless of if the client is Outline or not.

[thelonious89]

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.

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. ;-)

[fortuna]

Since this bug was created, we added a data limit feature that applies to all keys.
We are now adding a feature to specify a limit on an individual key: Jigsaw-Code/outline-apps#879

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.

[fortuna]

Since this issue is old and conflates too many things, I'll close it in favor of more focused ones:

• Bandwidth limit: Support for Bandwidth Limiting #198
• Per-key data limit: Allow for different data transfer limits per key outline-apps#879
• Limit number of devices: Access key per device or one session per access key #546

/cc @cjhenck

[parsalotfy]

I see the following asks:

• Limit the speed of connections
• Limit the duration of the connections
• Limit the number of devices in a connection

@wnxkiwi Could you give more context on how those features are useful? What's the problem you are trying to solve?

@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.
If this feature does not exist, people share their access key with others who hasn't payed for that.
This is the problem, is there any solution?
Requested this feature in this issue #900

[parsalotfy]

Since this bug was created, we added a data limit feature that applies to all keys.
We are now adding a feature to specify a limit on an individual key: Jigsaw-Code/outline-client#879

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.

Do you release this feature until the end of May?
I'm very enthusiastic to see that happen 🙂

[lgg]

@parsalotfy check this: #546 and please ask questions there.

This issue is closed, no discussion here, please.