[squid-users] ssl bump and url_rewrite_program (like squidguard)

[Amos Jeffries]

On 13/11/2015 1:02 a.m., Edouard Gaulué wrote:
> 
> In the https case I observe just 1 stream:
> CONNECT ad.doubleclick.net:443 HTTP/1.1
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:42.0)
> Gecko/20100101 Firefox/42.0
> Proxy-Connection: keep-alive
> Connection: keep-alive
> Host: ad.doubleclick.net:443
> 
> HTTP/1.1 302 Found
> Server: squid/3.5.10
> Date: Thu, 12 Nov 2015 10:35:57 GMT
> Content-Length: 0
> Location:
> https://proxyweb.echoppe.lan/cgi-bin/squidGuard-simple.cgi?clientaddr=192.168.0.74pipo&clientname=192.168.0.74&clientuser=&clientgroup=marine&targetgroup=adv
> 
> X-Cache: MISS from squid
> X-Cache-Lookup: MISS from squid:3128
> Via: 1.1 squid (squid/3.5.10)
> Connection: keep-alive
> 
> CONNECT ad.doubleclick.net:443 HTTP/1.1
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:42.0)
> Gecko/20100101 Firefox/42.0
> Proxy-Connection: keep-alive
> Connection: keep-alive
> Host: ad.doubleclick.net:443
> 
> 
> All this is between my client and proxy server.
> 
> Why is the browser not taking account of the redirect?

Think about *exactly* what is being redirected.

CONNECT is a request to setup a blind packet relaying tunnel.


> Why is it redoing the same connect?

Because its a browser. They do some really weird things when confused.

It was told a TCP relay tunnel existed at
"https://proxyweb.echoppe.lan/cgi-bin/...". Thats a pretty weird place
for a network socket to exist.


> Why is there no trace at all in the proxy logs of this second CONNECT?
> 

Only if it was handled would it be logged. It seems it may have been
read in (or maybe not) but definitely not processed for some reason.

Amos