[squid-dev] [RFC] How would you call this "authentication" way?(a bit long)

[Amos Jeffries]

On 19/02/2016 5:28 a.m., Eliezer Croitoru wrote:
> 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)
> 

"transparent proxy" is a badly overloaded phrase.
 * Taken literally it means the same as "forward-proxy" in HTTP terminology.
 * Taken as a colloquial way of saying "interception proxy", aka. MITM.
It is by definition not possible to have trust since the identity of the
proxy is unverifiable.


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

Let me stop you right there.

In order to set a Cookie that is in any way equivalent to the
authentication/authorization sessions. The proxy has to first be able to
determine whether any two random connections came from the same client UA.
  If it is capable of doing that already then that is how the
authoriation session helper should be operating. No need for Cookie to
be involved.

The ability to set Cookies for generic UA->interceptor authorization is
an *outcome* of having a session. Not the reverse.

They could be used for the much more limited scope of tying two UA
connections for the same domain into a session. But ...

A secondary effect of using Cookie is that the Cookie data is then
delivered by the UA to the origin it thinks that Cookie belongs to.
Including down channels the proxy is not intercepting. This wastes a lot
of bandwidth, reveals not just the proxy existence but its session
credentials as well into the WAN.


There is still the ultimate question of trust needing to verify the
proxies identity. To ensure that the unseen proxy setting the Cookie is
the one its going to be delivered to later.


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

What you go on to describe is a Redirect attack. Its particularly a
favourite when attacking websites using OAuth.

Amos