After playing with couple SSO ideas in general I noticed that something
similar can be done with squid while it will not be as secured as
kerberos and couple other nice implementation.
Deatils:
A transparent proxy cannot authenticate users in the session level. The
current known available options are using some session db(by IP) or
Radius or LDAP(by ip) and couple others.
So for couple specific environments which uses either NAT or multiple
VNC\RDP sessions there is no option to authenticate a specific user but
a whole IP\machine.
The real solution would be to somehow make it possible for a browser to
know about the option of a "transparent proxy" and to also trust it.
Also this specific network must be secured enough so no rough dhcp
services will pop up and couple other network level restrictions will be
applied to ensure that the browser can authenticate to the proxy in the
case he will be there.(There might be some other attacks which I didn't
mentioned)
Another approach to the issue:
Currently browsers use cookies to authenticate banks, police, health and
many other systems. They are not highly secured but they are being used
in many places.
Maybe we can use them for something?
Since the first days of cookies security restrictions was applied on
them to disable phishing, impersonation etc.
Many vendors "secure" the cookies based on user-agent string,
timestamps, origin ip and many others. These in very specific cases can
make it somehow harder on the cookie finder to use them but it still
might not be enough for many systems.
OK so cookies are not 100% secure but as long as my network is under my
"total" control and nobody can use tcpdump\wireshark on the client whole
machine without privileges or some attack can force a network flood it
would be kind of safe to use some cookies on some machines\clients.
What I was testing is a setup like this(which I don't know how to call
if at all):
- Linux router with squid in intercept(ssl-bump)
- Linux machine ICAP service
- Linux machine HTTPs\AUTH service
- Linux machine Shared ram DB service
- A Client with a browser(Firefox\IE\Chrome\Opera\Safari etc)
The client is expected to be authenticated to the AUTH service.
On every http request(to wan) the ICAP service checks for a specific
TOKEN-COOKIE.
If the TOKEN-COOKIE exists it validates the TOKEN VS the DB and if
cleared for this specific IP and maybe other properties the TOKEN-COOKIE
is being stripped from the request and the client request is being
passed to the origin server and the ICAP service returns to squid the
request authenticated users.
In the other case which either the TOKEN-COOKIE is not present or
invalid the ICAP service is redirecting the client to the AUTH service
page with a special REDIRECTION-TOKEN.
If the user was not authenticated to the AUTH service he will be asked
to enter credentials.
When the user press LOGIN the user is being sent an authentication
cookie and receives a redirection with a TOKEN(which can be stored in
the DB) to the original request page.
If the browser has a valid AUTH cookie he will be identified and
redirected automatically without the need to enter any credentials.
Then the ICAP service can verify who the user is and if the TOKEN is
valid and the user is being redirected to the original request page with
a Set-Cookie which contains the TOKEN-COOKIE for this specific domain.
Now this domain and all it's sub-domains requests will contain the
TOKEN-COOKIE which the ICAP service will clear any request to them until
some per-defined cookie expiration property or auto detected cookie abuse.
The above "idea" is being implemented in many SSO systems but in this
specific use case it's being done on the whole Internet HTTP and HTTPS
traffic.
It has couple attacks vectoring points and also lots of "holes" such as
non bumpable HTTPS traffic.
It's not an alternative to simple forward proxy settings in browsers and
gives really bad time to POST requests but it works for many simple use
cases.
But, how would you call this kind of proxy authentication? "cookie"
based? "token" based? SSO?? "cookie bearer" ? ideas?
Thanks,
Eliezer
_______________________________________________
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev
