On 21/08/2013 1:59 p.m., Daniel Niasoff wrote:
Hi,
We are using Squid with SslBump/
Our users are sporadically getting "access denied" errors so I did a bit of
debugging and saw this.
2013/08/21 01:24:49.900 kid1| Acl.cc(336) matches: ACLList::matches: checking
authenticated
2013/08/21 01:24:49.900 kid1| Acl.cc(319) checklistMatches:
ACL::checklistMatches: checking 'authenticated'
2013/08/21 01:24:49.900 kid1| Acl.cc(28) AuthenticateAcl: SslBumped request: It
is an encapsulated request do not authenticate
2013/08/21 01:24:49.900 kid1| UserRequest.cc(93) valid: Validated.
Auth::UserRequest '0x7f0ce933b8c0'.
2013/08/21 01:24:49.900 kid1| User.cc(38) authenticated: User not authenticated
or credentials need rechecking.
Does this mean it's impossible to authenticate a SslBumped request.
Yes it does. Sort of.
What's strange is the access log is showing the request with a username which
indicates the request was authenticated!
Proxy authentication can be done on the CONNECT tunnel request which was
bumped. If that CONNECT is authenticated then each internally bumped
sub-request is given those same credentials. If it is not authenticated
then all sub-requests are treated as un-authenticated like you see above.
Also when the user refreshes the problem usually disappears.
Currently the authentication helper was set to 6 minutes (for testing) and I
have increased it to 60 minutes.
The credentials should be "pinned" to the CONNECT tunnel and not expire
for any of the sub-requests. If you find them expiring that is a bug.
Please ensure that you are using the latest 3.3 series release and
provide details of it in bugzilla.
Amos
