Re: ssl-bump options

On Tue, 2007-11-06 at 12:24 +1300, Amos Jeffries wrote:
> > Update of cvs.devel.squid-cache.org:/cvsroot/squid/squid3/src
> >
> > Modified Files:
> > Tag: ssl-bump
> > client_side_request.cc client_side_request.h
> > Log Message:
> > Switch to SslBump mode when a CONNECT request is detected. Will need to
> > add an on/off switch or an ACL to control which CONNECT requests should be lifted
> > off the wire and into Squid (creating a "bump on the wire").
> >
> > When SslBump is activated, Squid responds to CONNECT request with HTTP 200
> > "Connection established" and switches to SSL encryption on the connection.
> >
> > This code appears to work in limited tests, but it relies on https_port
> > being set (to get SSL certificates and related info) even though no requests
> > reach that port in those tests. There are many other hacks that need to be
> > polished or removed.
>
> It makes sense to consider the https_port as the explicit *incoming*
> address for SSL connections.

In case of a CONNECT intercept, the https_port is not really used. The
browser is connecting to a regular http_port, sending a mixture of
regular unencrypted and CONNECT requests (also unencrypted from HTTP
point of view). Thus, https_port cannot be used as an explicit incoming
address. Or did I misinterpret your suggestion?

> I would propose an option in line with the other components:
> ssl_outgoing_address a.b.c.d
> with options such as cert, keyfile etc identical in name and purpose to
> https_port but that configure a specific server-side certificate for
> squids bumped outbound links (MAY be the same as the inbound https_port
> ones), these could apply to bump'd requests and to other outbound SSL
> links.

I am using the existing sslproxy_* options for the outgoing connections.
Is that similar to what you are proposing above? There is no
sslproxy_address, but there are options to specify SSL details...

Thank you,

Alex.
Received on Mon Nov 05 2007 - 17:43:50 MST