Search squid archive

Re: ssl bump and url_rewrite_program (like squidguard)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux