[squid-users] Using Squid as forward http proxy failing to complete request?

[Amos Jeffries]

On 24/08/2015 6:41 p.m., asad wrote:
> Amos, sorry for late reply. I wanted to test the config in office
> environment, good news is that it worked:). Only two issues:-
> 
> 1) the client is repeatedly prompted for credentials when even in
> background the website is loading.
> 

Thats the way HTTP authentication is designed. Nothing can happen
without authentication credentials.

And HTTP is not aware what is displayed on the users screen (or not).
There is not even a real concept of "user" or "screen". Just clients and
servers messaging each other.


> 2) It doesn't work for ssl websites. Does squid do MITM?
> 

Yes, but MITM will not help you here.

Because the only case where HTTP authentication is possible with MITM is
when intercepting traffic destined to a forward-proxy. Your setup is
very close to that edge case, but the HTTPS CONNECT requests will still
be having the same user-end behaviour in either format.

There are three suspects for CONNECT not authentiation. In order of
likelihood they are;

1) on recent Squid you are probably running into one of the edge cases
where our fix for CVE-2015-5400 causes unwanted blocking. That makes two
that I've now found since the security fix went out.

But its worth double-checking that suspicion. Please check if your proxy
is actually relaying the CONNECT to its parent. And when the parent
replies 407 if proxy is sending the client a 502 or 407.

2) the client software just being broken when its asked to authenticate
for a CONNECT.

3) Needing to configure "nonheirarchical_direct off" so the CONNECT
actually get sent to the parent. This shows up as clients receiving 503
status responses generated by your proxy after CONNECT.

You can see the details clients are getting with this:
 squidclient -m CONNECT example.com:443


[pPS. *ssl* sites not working is good because SSLv2 and SSLv3 are
terribly broken security. *HTTPS* on the other hand ...]

Amos