[squid-users] how to capture https transactions
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. Is this actually possible, and if so... what directives should I be looking at for the config file. Any suggestions and/or comments are welcome. TIA Fulko
Re: [squid-users] how to capture https transactions
On Wed, 1 Jul 2009 20:55:06 -0400, Fulko Hew fulko@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
Re: [squid-users] how to capture https transactions
On Wed, 1 Jul 2009 18:46:32 -0700, George Herbert george.herb...@gmail.com wrote: On Wed, Jul 1, 2009 at 6:13 PM, Amos Jeffriessqu...@treenet.co.nz wrote: On Wed, 1 Jul 2009 20:55:06 -0400, Fulko Hew fulko@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. I don't know if Squid knows how to do this (haven't checked), but other load balancers, accelerators, and firewalls can sometimes have the site SSL / https keys installed to allow them to interact with https content going back and forth. There's a ethereal / wireshark module to provide it your site key to decrypt that traffic. That does only work if: a) you own both ends of the link (not clear from first email), b) your software supports it c) you trust your proxies with your site keys That is exactly the SslBump feature I mentioned. It causes browser popups when they validate the cert and discover that the domain they are contacting has the wrong credentials. Users often ignore such popups, but for this public kiosk situation its very likely to lead to complaints and a minor scandal. Amos
Re: [squid-users] how to capture https transactions
On Wed, Jul 1, 2009 at 6:13 PM, Amos Jeffriessqu...@treenet.co.nz wrote: On Wed, 1 Jul 2009 20:55:06 -0400, Fulko Hew fulko@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. I don't know if Squid knows how to do this (haven't checked), but other load balancers, accelerators, and firewalls can sometimes have the site SSL / https keys installed to allow them to interact with https content going back and forth. There's a ethereal / wireshark module to provide it your site key to decrypt that traffic. That does only work if: a) you own both ends of the link (not clear from first email), b) your software supports it c) you trust your proxies with your site keys -- -george william herbert george.herb...@gmail.com