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?

My understanding is that https_port is for when squid is accelerating
https and thus listening. IMHO it should remain an inbound-only config. My
reason for saying this was due to my reading of your comment (see below).

>
>> 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...

Ah, I took your commit comment "but it relies on https_port being set (to
get SSL certificates and related info)" to mean the settings were being
taken from the https_port part of Config, not the sslproxy part (of which
I was only vaguely aware until you pointed it out).

But Yes, looking up the sslproxy_*. My proposal would encompass the
sslproxy_* options as optional arguments in a single ssl_outgoing_address
which could be a per-outgoing-IP setting (due to SSL certs being
per-address/port) or a wildcard if ALL use the same details in a generic
cert. Instead of the many individual options at present.

Amos
Received on Mon Nov 05 2007 - 20:22:29 MST