On Tue, 06 Sep 2011 15:15:08 +0200, Łukasz Makowski wrote:
W dniu 2011-09-06 08:08, Amos Jeffries pisze:
On 05/09/11 22:03, Łukasz Makowski wrote:
Hello everyone,
I'm using Squid and ldap_authentication, and recently decided do
deploy
ssl_bump feature.
I have made tests for ssl_bump and everything works just fine, but
when
combined with ldap authentication,
it appeared to have one big disadvantage.
For every site user try to visit, squid pops with its
authentication
window.
I see that for regular, http traffic message looks like this :
"Server
My_Squid_Server needs authentication blablabla".
But when ssl_bump triggers during visiting https web page, it
states :
"Server Https_Site_Domain needs authentication blablabla".
I know that this behaviour can be caused by a way that ssl_bump
works.
Please tell me is there any possible method to overcome this ?
Thanks for help.
Lukasz
I suspect you have the recommended "deny !authedUsers" or similar.
Bumped traffic should match "acl HTTPS proto HTTPS". So you should
be able to bypass the auth using that ACL.
Amos
Thanks for your reply.
My auth acl looks like this:
acl password proxy_auth REQUIRED
and rules for traffic:
http_access allow password
ssl_bump allow all
I also tried following, when experimenting with ssl_bump :
acl https_traffic method CONNECT
ssl_bump allow https_traffic
but it works the same for me.
My point when trying to implement ssl_bump was to log https urls and
users accesing them, as I am doing it for http.
I'm concerned about part of your statement "So you should be able to
bypass the auth using that ACL".
Did I understand you correctlly ? Is there no possibility to force
squid to auth my users when accesing https?
The original CONNECT request still passes through the http_access
controls before it gets bumped. So auth will happen on that request.
Which unfortunately is not logged yet, but still happens.
Once the bump occurs the unwrapped requests cannot be individually
authenticated due to the same reasons the other forms of intercepted
traffic cannot. The browser believes it is talking down a secure tunnel
to the host the CONNECT specified and will not send proxy credentials to
MITM agents. This is why you got the error pages showing to the browser
instead of an auth handshake.
NP: I believe we can bind the CONNECT credentials to the unwrapped
requests using the NTLM connection-auth mechanisms. But so far nobody
has worked on that yet.
Amos
