Re: [squid-users] SslBumped request: It is an encapsulated request do not authenticate

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
Received on Wed Aug 21 2013 - 09:09:30 MDT