After upgrading to Core Update 127 (yes, I did not test this, forgive me), there is some bug in the proxy WebUI: If authentication is enabled (tested with setting "local"), any concurrent IP address limit set causes the CGI to output this error: "Authentifizierungscache TTL darf nicht 0 sein wenn IP-Adressbeschränkungen verwendet werden" However, the authentication cache _is_ not set to 0. Using any value causes this message to appear, by setting the IP address limit to blank value, it works - but IP address limit is now not defined. Since I am not very deep into this, could I ask you to have a look at it? Steps to reproduce: (a) Use "local" authentication for the proxy. (b) Set IP address limit to "1". (c) Set authentication cache to any value > 0 (e.g. 10 minutes). (d) Update to Core Update 127. (e) Try to edit anything via the proxy GUI -> error message appears. Thank you. Let me know if there is something to test... :-)
This is a bit of a problem here now. It has been deliberately removed that squid caches an IP address from which a user has successfully authenticated. Any consecutive can be sent from the same IP address for N minutes which I regard as a security issue. It is authentication bypass. Any VM or so on a host may take advantage of this as well as other software that does not have credentials like the browser has. The IP limit feature relies on that. So I guess we have to drop that, too? I think that is the better solution out of the two of them.
So why is this a GoodFirstBug then? What is your idea to do on this?
(In reply to Peter Müller from comment #2) > So why is this a GoodFirstBug then? What is your idea to do on this? Because the check only has to be removed. The input field is no longer available. That would be a simple patch with maybe 4 lines?
I see, thanks.
After some delay and looking at this more closely, I disagree. Corresponding snipped taken from squid.conf.documented: # acl aclname max_user_ip [-s] number # # This will be matched when the user attempts to log in from more # # than <number> different ip addresses. The authenticate_ip_ttl # # parameter controls the timeout on the ip entries. [fast] # # If -s is specified the limit is strict, denying browsing # # from any further IP addresses until the ttl has expired. Without # # -s Squid will just annoy the user by "randomly" denying requests. # # (the counter is reset each time the limit is reached and a # # request is denied) # # NOTE: in acceleration mode or where there is mesh of child proxies, # # clients may appear to come from multiple addresses if they are # # going through proxy farms, so a limit of 1 may cause user problems. This does not seem to be an authentication bypass, it simply prevents user credentials from being shared and (ab)used at the same time by several clients. In relatively static networks, there is no need for a user credential being used by more than one IP address in parallel, so I actually consider this being a security feature. Or am I misguided again?
Okay, what is your proposed solution?
To fix this so IP addresses per user can be limited again.
https://patchwork.ipfire.org/project/ipfire/list/?series=1375
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=0f8251fe64dd8d799713e0f42cc01785f5ce2bc9
https://blog.ipfire.org/post/ipfire-2-25-core-update-147-is-available-for-testing
https://blog.ipfire.org/post/ipfire-2-25-core-update-147-released