Problem with https_port intercept and ssl-bump

Hello,

I've sent something similar to the squid-users list, however upon
further inspection I think it is more of a development issue. I'm trying
to get ssl-bump going with v3.2 and having a lot of issues getting it
going. This was working for me with v3.1.9, so I think it may be related
to the new ssl_crtd work.

The relevant lines (I think) of my config are:
# And finally deny all other access to this proxy
http_access allow all
sslproxy_cert_error allow all
always_direct allow HTTPS
ssl_bump allow all
http_port 3128 ssl-bump cert=/etc/sslkeys/inspectcert.pem
key=/etc/sslkeys/inspectkey.pem
http_port 60080 intercept
# I have tried using both transparent and intercept options with the
same outcome
#https_port 60443 transparent ssl-bump cert=/etc/sslkeys/inspectcert.pem
key=/etc/sslkeys/inspectkey.pem
https_port 60443 intercept ssl-bump cert=/etc/sslkeys/inspectcert.pem
key=/etc/sslkeys/inspectkey.pem

The firewall rules I'm using are:
-t nat -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 60080
-t nat -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 60443

It is working great on port 80, however for port 443 it is not playing
nice. From what I can tell with traffic dumps, once the SSL negotiation
on the client side is complete (using the inspectcert.pem configured
above), it appears to be passing through the encrypted traffic to the
remote host (as sent from the client - ie: no decryption and
re-encryption with the remote host), then it appears to be returning the
first few bytes of the SSL stream back from the remote host (before the
remote host drops the connection because it is not an SSL setup, rather
stuff from mid an SSL stream).

I have tried with the following versions, built with RPM, with no
patches on a CentOS 5 machine.:
3.2.0.8
3.2.0.10
3.2.0.13
3.2.0.14
3.2.0.15
3.HEAD-20120404-r12109

I have also testing with v3.2.0.14 on Fedora 16 using the Fedora 16 RPM
(ie: yum install squid)

What I have found is with versions:
3.2.0.8
3.2.0.10
3.2.0.13
When I try the SSL connection, it just sits there, appearing to do
nothing (I give up after 60 seconds).

With all other later versions from 3.2.0.14, I get the above behaviour
where it does not actually negotiate with the remote host, and just
passes the encrypted traffic from the client through to the remote host.

It works fine with the direct proxy. It will also work if I do a wget
via the proxy, then straight after do a wget via interception (ie: have
a bash script to do one, then the next). From traffic dumps it appears
to be using the same connection (ie: the SSL negotiation is already done).

I'm not a C++ programmer, but from looking at the code, it appears the
use of ssl-bump on the https_port (httpsAccept function) is very
different from when using the CONNECT method on a http_port with a
direct proxy connection with ssl-bump (ConnStateData::getSslContextStart
method on the ConnStateData class - there is no class for https_port
connections???). So my assumption is something here is causing the issue
such that a call to something to SSL negotiate with the remote host is
not happening.

I understand the above will result in ALL sites getting the same cert to
the client - my goal is to just scan a couple of sites once is get this
very basic config working.

 From the RPM build process, I think these are the configure options
used in the build:
./configure --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu
--target=i586-redhat-linux-gnu --program-prefix= --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--sysconfdir=/etc --datadir=/usr/share --inc
ludedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec
--localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man
--infodir=/usr/share/info --exec_prefix=/usr --libexecdir=/usr/lib/squid
--localstatedir=/var --datad
ir=/usr/share/squid --sysconfdir=/etc/squid
'--with-logdir=$(localstatedir)/log/squid'
'--with-pidfile=$(localstatedir)/run/squid.pid'
--disable-dependency-tracking --enable-arp-acl
--enable-follow-x-forwarded-for --enable-auth --enable-
auth-basic=DB,LDAP,MSNT,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB,getpwnam
--enable-auth-ntlm=smb_lm,fake --enable-auth-digest=file,LDAP,eDirectory
--enable-auth-negotiate=kerberos
--enable-external-acl-helpers=ip_user,ldap_gro
up,session,unix_group,wbinfo_group --enable-cache-digests
--enable-cachemgr-hostname=localhost --enable-delay-pools --enable-epoll
--enable-icap-client --enable-ident-lookups --with-large-files
--enable-linux-netfilter --enable-referer-l
og --enable-removal-policies=heap,lru --enable-snmp --enable-ssl
--enable-ssl-crtd --enable-storeio=aufs,diskd,ufs --enable-useragent-log
--enable-wccpv2 --with-aio --with-default-user=squid
--with-filedescriptors=16384 --with-dl --with-
openssl --with-pthreads --disable-ipv6 --disable-loadable-modules

I have also tried with only minimal configure flags, and still had the
same result.

If anyone has any other ideas of things I can try, I'm happy to try
anything that may make sense.

I'm also happy to add plenty of debug lines and logs and rebuild if that
would help, I just don't have the background to know where to go,
however I think this should be easy to replicate.

Thanks!
Received on Tue Apr 10 2012 - 04:38:34 MDT