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

[Edouard Gaulué]

Hi Amos and all,

Learning on HTTP CONNECT, I got 
there:http://serverfault.com/questions/727262/how-to-redirect-https-connect-request-with-squid-explicit-proxy

I read on http://wiki.squid-cache.org/Features/MimicSslServerCert in the 
"Delayed error responses" chapter:
"When Squid fails to negotiate a secure connection with the origin 
server and bump-ssl-server-first is enabled, Squid remembers the error 
page and serves it after establishing the secure connection with the 
client and receiving the first encrypted client request. The error is 
served securely. The same approach is used for Squid redirect messages 
configured via deny_info. This error delay is implemented because (a) 
browsers like FireFox and Chromium do not display CONNECT errors 
correctly and (b) intercepted SSL connections must wait for the first 
request to serve an error."

My ideas/questions:
1/ Is there a way to have the same with new peek and splice feature?
2/ Is there a way to say url_rewrite_program not to work on CONNECT 
request? This way the CONNECT is not redirected, next request the 
browser sends after squid has bumped it  should be a kind of  GET/POST 
one that will be redirected by url_rewrite_program.
3/ Would it works if squidguard were i-cap'ed?

EG


Le 13/11/2015 01:31, Amos Jeffries a écrit :
> On 13/11/2015 1:02 a.m., Edouard Gaulué wrote:
>>
>>
>> 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
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users