On 3/02/25 18:25, NgTech LTD wrote:
What i was talking about is using both the auth helper and the external
ack helper.
Using an ACL helper is just extra complication that is not needed and
the "Keep It Simple" (KIS) principle of design is very important for
security systems.
For "global" access you can authorize OR authenticate. Doing "validate +
authorize + authorize" is pointless for this use-case.
You only need to add authorization on top of authentication (eg user
login + group access) if you have some non-global resources/area needing
special authorization that is not granted by just the login.
At the lowest-level of operations:
* the auth_param helper performs security action "Validate". The
http_access rules you use to call it perform security action "Authorize".
* the external ACL helper performs "nothing"[0] as far as Squid is
concerned. The http_access rules you use to call it perform security
action "Authorize".
[0] It could actually be doing anything, but Squid cannot know what. In
particular it does **not** trigger Squid to apply any HTTP
authentication-related security requirements on the HTTP request/reply
handling (where the HTTP headers used by auth_param does trigger those)
- which can potentially be **extremely** dangerous.
The password is static but the authorization itself is done via some
push or another totp method that will authorize the login for a specific
amount of time.
Sure. But you do not need an external ACL for that.
In my earlier suggested design the altered ERR_* page has a HTML form
for POST'ing the 2FA token somewhere directly from the clients Browser
to a server. That other service is what grants the "Valid" status to
complete the 2FA login.
**IF** that POST goes through Squid it should use an unrelated TCP
connection and/or HTTPS security - so there is no way for Squid or any
other service than your auth server to know which previous client login
it applies to.
And indeed it will kind of degrade the connection to 1fa for a period of
time, but, it will protect against couple specific attacks.
So, if the proxy connection is encrypted inside a tunnel then it's ok.
To be 2FA by definition the entire process has to happen over two
distinct channels, each being used to pass a different token (a.k.a.
"factor").
case 1: client does not send any user+pass at all:
channel 1: client -> Squid : (no login)
: Squid->client : 401 login required
channel 2: auth server -> email : token
channel 1: client -> Squid : POST username + pass + token
: Squid->client : 200 login confirmed,
case 2: client sends login details, but no 2FA yet:
channel 1: client -> Squid : HTTP username + pass
: Squid->client : 401 login required
channel 2: auth server -> email : token
channel 1: client -> Squid : POST username + pass + token
: Squid->client : 200 login confirmed,
NB: in both cases you could do a 307 redirect back to the original
requested URL if it is known at that late stage.
As for a directly accessible proxy over plain http, it will be
vulnerable to many auth attacks..
This is not relevant. Any login system faces the same risks of attack
floods.And the "plain HTTP" is not required. It is only part of this
discussion because Squid is an HTTP proxy. Thus messages are interpreted
by Squid as HTTP regardless if they were received as "plain" or HTTPS.
HTH
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
