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

Amos Jeffries squid3 at treenet.co.nz
Fri Nov 13 00:31:05 UTC 2015


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



More information about the squid-users mailing list