On Wed, 1 Jul 2009 20:55:06 -0400, Fulko Hew <fulko.hew_at_gmail.com> 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
Received on Thu Jul 02 2009 - 01:13:41 MDT
This archive was generated by hypermail 2.2.0 : Thu Jul 02 2009 - 12:00:01 MDT