Thanks for the detailed response!
From what I understand until now it seems to me that the main reason
that nobody created a "standard" for MITM proxies authentication is
since the current HTTP implementations and UA are somehow aware of the
option to the wildness of the networks and the Internet world.
While reviewing OAuth and SSO technologies I noticed that it is very
"simple" to attack them using some kind of MITM and I was kind of amazed
by what issues might arise if the UA in some way contacts some public
Internet system.
It gets even more complicated with NAT and until now the solutions for
SSO and OAuth are to somehow use an Internal Authentication and
Authorization system in the UA\Session level.
Maybe I missed something but I am unsure. Authorization and
Authentication can work in a way together or in separated ways(leaving
squid and other acls aside).
What Authorization helpers I have missed?
The ones I know about that a transparent(MITM) proxy can use are:
- Radius(IP)
- Time_quota(IP)
- session(IP)
These are good for specific usages and will probably not be good enough
for full authentication and authorization for VNC\RDP\NAT environments.
I do not argue with the risks that do exists and organizations do
consider them over and over again. Some use VPN connections to somehow
evade every HTTP\HTTPS MITM proxies in the wild but many do not require
that and I really do not know how they make sure that the connections
are secure else then TLS\SSL.
One of the really hard things I have seen lately in the security
industry was Anti Viruses that are doing machine local HTTPS MITM. And
the harder thing was that these programs implement some kind of "sensor"
net which sends data to their main systems. The most weird thing I have
seen is that most of them didn't even used HTTPS connections to these
"sensor" networks main API system.
There is a whole other aspect about CDN security, many offer free domain
level SSL.
The dilemma that stands is:
If these Security firms use plain HTTP for so many delicate things, why
should I trust them or why do I use HTTPS?
As a result to this dilemma and the thread opening subject I was
starting to think about writing a wiki article. In some relation to
squid without providing any code, would it be right to describe in some
technical details this kind of attack?
The pros:
- It will give another aspect when looking at the attack.
- It will make the awareness to the subjects a bit better.
- The time on the research about the subject was already invested.
The cons:
- Many wrote about the subject in the past.
- It's not a caching subject but rather a security one.
What do you and maybe others think about security related articles in
the wiki?
Eliezer
On 18/02/2016 19:19, Amos Jeffries wrote:
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
authorization 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
favorite when attacking websites using OAuth.
Amos
_______________________________________________
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev
_______________________________________________
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev
