Re: [squid-users] Issues with ssl-bump in 3.HEAD

On 6/12/2014 4:11 PM, Amos Jeffries wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 13/06/2014 7:46 a.m., Guy Helmer wrote:
>> On Jun 12, 2014, at 2:25 PM, Mike <mcsnv96_at_afo.net> wrote:
>>
>>> On 6/12/2014 2:06 PM, Guy Helmer wrote:
>>>> On Jun 12, 2014, at 1:01 PM, Mike <mcsnv96_at_afo.net> wrote:
>>>>
>>>>> I have been racking my brain trying to get this working and
>>>>> each time,it refuses to connect to secure sites. In the end we
>>>>> need a working squid proxy for SSL connections within the
>>>>> company network which will serve over 1000 users (thus the
>>>>> larger 8MB cert cache size). We already have theinsecure HTTP
>>>>> proxy working fine (thus the use of port 3129 below). Since it
>>>>> will be SSL based, I know it needs https_port (not http_port),
>>>>> ssl-bump, and intercept (required by ssl-bump). The https_port
>>>>> and ssl-bump documentation also mentioned the preference for
>>>>> sslflags (which may or may not be working in 3.HEAD) and
>>>>> cipher.
>>>>>
>>>>> OS is Scientific Linux 6.5 (based on CentOS) fully up to date
>>>>> with yum. Server is quad core 3.4GHz, 8GB DDR3 with no other
>>>>> uses (like web server, etc). SELinux has been set to permissive
>>>>> mode so it only reports, doesn't block the needed connections
>>>>> (although I also tested with it disabled and made no
>>>>> difference). [root_at_localhost ~]# sestatus SELinux status:
>>>>> enabled SELinuxfs mount: /selinux Current mode: permissive Mode
>>>>> from config file: permissive Policy version: 24 Policy from
>>>>> config file: targeted
>>>>>
>>>>> Essential squid.conf lines (I have tested it with and without
>>>>> the "sslflags", does not impact it working or not working):
>>>>>
>>>>> https_port 3129 intercept ssl-bump connection-auth=off
>>>>> generate-host-certificates=on dynamic_cert_mem_cache_size=8MB
>>>>> cert=/etc/squid/ssl/squid.pem key=/etc/squid/ssl/squid.key
>>>>> sslflags=DELAYED_AUTH
>>>>> cipher=ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:AES128-SHA:RC4-SHA:HIGH:!aNULL:!MD5:!ADH
>>>>>
>>>>>
> sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/lib/squid_ssl_db -M 8MB
>>>>> sslcrtd_children 50 startup=5 idle=1 ssl_bump server-first all
>>>>> ssl_bump none localhost
>>>>>
>>>>> Local certs have been created and self signed, and the .der
>>>>> cert has been imported into the test browser (Firefox 30.0).
>>>>>
>>>>> Squid info (includes the needed '--enable-ssl'
>>>>> '--enable-ssl-crtd' '--with-openssl'):
>>>>>
>>>>> [root_at_localhost ~]# squid -v Squid Cache: Version
>>>>> 3.HEAD-20140127-r13248 Service Name: squid configure options:
>>>>> '--build=x86_64-redhat-linux-gnu'
>>>>> '--host=x86_64-redhat-linux-gnu'
>>>>> '--target=x86_64-redhat-linux-gnu' '--program-prefix='
>>>>> '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin'
>>>>> '--sbindir=/usr/sbin' '--sysconfdir=/etc'
>>>>> '--datadir=/usr/share' '--includedir=/usr/include'
>>>>> '--libdir=/usr/lib64' '--libexecdir=/usr/libexec'
>>>>> '--sharedstatedir=/var/lib' '--mandir=/usr/share/man'
>>>>> '--infodir=/usr/share/info' '--exec_prefix=/usr'
>>>>> '--libexecdir=/usr/lib64/squid' '--localstatedir=/var'
>>>>> '--datadir=/usr/share/squid' '--sysconfdir=/etc/squid'
>>>>> '--with-logdir=$(localstatedir)/log/squid'
>>>>> '--with-pidfile=$(localstatedir)/run/squid.pid'
>>>>> '--disable-dependency-tracking' '--enable-eui'
>>>>> '--enable-follow-x-forwarded-for' '--enable-auth'
>>>>> '--enable-auth-basic=DB,LDAP,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB,getpwnam'
>>>>> '--enable-auth-ntlm=smb_lm,fake'
>>>>> '--enable-auth-digest=file,LDAP,eDirectory'
>>>>> '--enable-auth-negotiate=kerberos,wrapper'
>>>>> '--enable-external-acl-helpers=wbinfo_group,kerber!
>>> os_ldap_ group,AD_group' '--enable-cache-digests'
>>> '--enable-cachemgr-hostname=localhost' '--enable-delay-pools'
>>> '--enable-epoll' '--enable-icap-client' '--enable-ident-lookups'
>>> '--enable-linux-netfilter' '--enable-removal-policies=heap,lru'
>>> '--enable-snmp' '--enable-ssl' '--enable-ssl-crtd'
>>> '--enable-storeio=aufs,diskd,ufs,rock' '--enable-wccpv2'
>>> '--enable-esi' '--with-aio' '--with-default-user=squid'
>>> '--with-filedescriptors=16384' '--with-dl' '--with-openssl'
>>> '--with-pthreads' '--disable-arch-native'
>>> 'build_alias=x86_64-redhat-linux-gnu'
>>> 'host_alias=x86_64-redhat-linux-gnu'
>>> 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall
>>> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
>>> --param=ssp-buffer-size=4 -m64 -mtune=generic' 'CXXFLAGS=-O2 -g
>>> -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
>>> --param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC'
>>> 'PKG_CONFIG_PATH=/usr/lib64/pkgconfig:/usr/share/pkgconfig'
>>>>>
>>>>> In the end testing with only the SSL proxy set to this server
>>>>> via port3129, it tries loading the secure website for 2-3
>>>>> minutes and then timesout. Checking "top", it shows squid
>>>>> running at 12.1g VIRT, 2.0g RES, 54.5% of MEM (server has 8GB)
>>>>> and using 100% of CPU2. The ../squid/access.log and
>>>>> cache_access.log shows no new entries at all. We had to disable
>>>>> thecache.log (cache_log /dev/null) as it continuously recorded
>>>>> everything and quickly took up all the space on the 80GB hard
>>>>> drive.
>>>>>
>>>>> So the question is what is going wrong that it is refusing to
>>>>> let ANY secure site load and how can we get this resolved? We
>>>>> greatly appreciate any help on this.
> The answer is those cache.og messages you disabled.
>
> Start by re-enabling cache.log with debug_options ALL,0. What is the set
> of logged errors ?
>
>
>>>>> Mike
>>>> If I understand correctly, you are attempting to use port 3129 as
>>>> a forward proxy. If so, you shouldn’t need the “intercept” option
>>>> on 3129, and you should change it to http_port since squid will
>>>> be directly receiving HTTP “CONNECT” requests, not SSL
>>>> connections.
>>>>
>>>> Regards, Guy
>>>>
>>> Guy, According to
>>> http://www.squid-cache.org/Versions/v3/3.HEAD/cfgman/https_port.html
>>> it says:
>>>
>>> https_port: The socket address where Squid will listen for client
>>> requests made over TLS or SSL connections.
>> Correct, but if you are configuring your browser to use this proxy
>> for HTTPS, the browser will start its connection to the specified
>> port with HTTP, not SSL -- the browser will initially send a
>> plaintext "CONNECT xxx:443 HTTP/1.1” command, and then the browser
>> will start using SSL. The plaintext HTTP command needs to be received
>> at an http_port on the squid proxy, not https_port.
>>
>>> ssl-bump - blah blah "Requires tproxy or intercept.”
>> Yes, because browsers can not be configured to do an SSL connection
>> to the proxy - as I mention above, if you are configuring the
>> browser, then the browser starts its HTTPS requests with a plaintext
>> HTTP command before shifting to SSL. The only purpose for the
>> https_port configuration parameter is to setup a port for a
>> “transparent” interception proxy (in which the browser is NOT
>> configured to talk to the proxy, but instead the proxy intercepts TCP
>> connections).
>>
> Small corrections. The reason ssl-bump requires tproxy or intercept is
> that it is an MITM attack for intercepting a TLS sesson.
>
> The ssl-bump interception is only necessary when the browser is
> configured to use plain-test HTTP to the proxy and trying to tunnel
> HTTPS over it via CONNECT, or if NAT/TPROXY is used to divert port 443
> traffic to an https_port.
> In both these cases Squid has to break open the TLS session that it is
> not supposed to be a party to. Thus ssl-bump MITM action is necessary.
>
>
> If the browser is configured explicitly to use a TLS connection to a
> proxy https_port there is no interception necessary. An https_port with
> regular SSL options is perfectly capable of receiving TLS connections
> from any client without bumping the TLS session.
>
> Chrome can be configured via PAC file to open TLS connections to a proxy.
>
> Firefox are making moves in a similar direction although I have yet to
> learn how one configures it.
>
> stunnel and ssh have long been used as tools to setup TLS tunnels ending
> at an https_port and securing plain old "insecure" HTTP over TLS to the
> proxy.
>
>>> I have tried it all 3 ways, both with and without those 2 modes,
>>> and at least with "intercept", it seems that squid is doing
>>> something by the i/o and squid activity, although the logs remain
>>> empty.
> access.log is geared to log HTTP traffic. If the TCP or TLS connection
> setup between the browser and Squid breaks in any way then nothing gets
> logged there.
>
> cache.log logs Squid errors. Failure to setup a TLS connection is not a
> Squid error. AFAIK OpenSSL only logs on syntax or bad problems. Things
> like rejecting the client for a bad set of ciphers or wrong cert are not
> TLS errors. So if the SSL/TLS library is reporting successful operation
> (setup OR reject) then nothing is logged there either.
>
>
>>> Also according to the same documentation, since this will be SSL
>>> proxy (not standard insecure HTTP proxy), "https_port" is
>>> required. Initially I did try it with "http_port" but it tries
>>> to treat CONNECT requests like a normal insecure http request
>>> causing sslcrtd to constantly crash, taking squid down with it.
>>> At least with "https_port 3129 intercept ssl-bump..." it doesn't
>>> crash and is the only time it shows i/o and squid activity, thus
>>> my request to the squid-users group.
>>>
>>> Thank you,
>>>
>>> Mike
>> If you are configuring your browser to use the proxy for SSL, you
>> will need to use http_port with ssl-bump enabled. It does not make
>> it a “standard insecure HTTP proxy” but enables forward proxy of
>> HTTPS traffic. I would suggest that you install wireshark and
>> capture the browser’s traffic to the proxy to verify how this
>> works.
>>
>> If squid then has trouble with the ssl_crtd helpers, that is
>> another issue that requires resolution. The fact that squid does
>> not crash when you are using https_port likely indicates that squid
>> and your browser have a failure to communicate, and that is masking
>> your ssl_crtd issue.
> I agree. It sounds like you are having two problems and they each hide
> whether the other is resolved.
>
> PS. Fact of the day: standard HTTP is only as secure (or insecure) as
> the connection it travels over. Some people run it over TLS
> connections and call that "secure". But HTTPS is usually less secure
> than HTTP (with no 'S') sent over an IPSEC, VPNSSL or SCTP connection.
> Why? HTTPS depends on certificate authorities trust. The private
> VPNSSL, IPSEC, SCTP relies on specific keys setup between the
> end-points no external trust necessary.
>
> Amos
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTmheKAAoJELJo5wb/XPRjpScIALk8Iv+dA7z6ofB4UIU4/LyL
> 1hOfGJBQx53CBnWhXTDiTm5X966/c/q/75GRCU+1uPGPWPRQ2hVt+4fE5DSGyZk5
> 9R0mCx8nYPQmkLNXoPM4zsQ1O8mWhze6x8HErzG+qFuJx6pVhQ6ceUTarjmblAIk
> Hr7JYclgRUbX9nyAFB1INU9es8aH3G7rn/8JGQZ/yamdZVXcnjeUKbNMKf7i5O0c
> 3C9xX3ej6kG+g5NaEeX3FlZQBVZUtLf+SgnHQ6FdJqkgGA8Wd7V3zwmF3IBcNslk
> e1WAnSdwN3NwAV3peg/jkbc3KxQhJWpDvT7AxQ78tIKofXsvql9Fof2Aa5Er1As=
> =DrnB
> -----END PGP SIGNATURE-----
>
Amos,

I've already tried this before.
When using http_port and above mentioned options, the only error shown
in the cache.log is:
ERROR: No forward-proxy ports configured.

So I re-add it for testing:

http_port 3128
http_port 3129 intercept ssl-bump... blah blah

Then:
service squid restart

At this point if I change SSL Proxy back to 3128, traffic is flowing,
but it is not intercepted like we need it to be. It is loading as if the
proxy is not even there.
When I use 3129 in SSL Proxy in the browser, traffic stops and
connection times out with no errors in the logs.

This leads me to believe that ssl-bump does not work at all since it is
not intercepting or "bumping" the ssl as it claims. I checked the
previously mentioned folders (/var/lib/squid_ssl_db) and there are no
certificate files there, meaning my server is not even grabbing the
certificate from the requested site.
Oh and iptables already has the allowance for ports 3128 (already there
for the existing working squid proxy server), and I added 3129 already
so it would not interfere.

Mike
Received on Thu Jun 12 2014 - 22:04:51 MDT