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
