On Wed, 1 Jul 2009 20:55:06 -0400, Fulko Hew <fulko.hew@xxxxxxxxx> wrote: > I'm new to squid, and I thought I could use it as a proxy to detect > transactions > that don't succeed and return a page to the browser that would display > an error page that re-submitted the original request (again) say 15 seconds > later. (I want to use this to hide network and server failure from > end users at a kiosk.) > > I've figured out how to do most of this for http transactions, but my > real target > uses https and when I look at the squid logs I see a transaction called > CONNECT ... DIRECT ... > > and these don't seem to go through, or at the very least it seems as though > the connections are not proxied, and hence DNS resolution and connection > failures aren't captured and don't result in squid error pages returned to > the > browser. Close. For https:// the browser is makign regular HTTP request, wrapped in SSL encryption. Then that itself is wrapped again inside a CONNECT. Squid just opens a CONNECT tunnel and shovels the bytes through. The SSL connection is made inside the tunnel direct for client to server, and the HTTPS stuff happens without Squid. IIRC there was some problem found with browsers displaying any custom response to a CONNECT failure. You want to look at the "deny_info ERR_CONNECT_FAIL" page replacement or such. > > Is this actually possible, and if so... what directives should I be looking > at for the config file. Squid 3.1 provides a SslBump feature to unwrap the CONNECT and proxy the SSL portions. But decrypting the SSL link mid-way is called a man-in-middle security attack. The browser security pops up a warning dialog box to the users every time this happens. I would not think this will be popular or good for a kiosk situation. Amos
