[squid-users] can't get bump to work anymore on 3.5.7?

[Jason Haar]

Hi there

I've had bump working before (testing), but went off to different things
for a while, but now I'm back and can't get it to work anymore. I've
upgraded to 3.5.7 (from some previous release - maybe 3.5.4?), so it may
be something that happened in there

I've stripped back my config in order to maximize getting bumping to
work, and is probably best described by:

root]# egrep -i 'crtd|bump|ssl:' squid.conf ssl-bump.inc|grep -v '#'
squid.conf:http_port 3128 ssl-bump cert=/etc/squid/squidCA.cert 
generate-host-certificates=on dynamic_cert_mem_cache_size=256MB options=ALL
squid.conf:https_port 3129 intercept ssl-bump
cert=/etc/squid/squidCA.cert  generate-host-certificates=on
dynamic_cert_mem_cache_size=256MB options=ALL
squid.conf:include /etc/squid/ssl-bump.inc
squid.conf:logformat logdetailed %ts.%03tu %6tr %>a %Ss/%03>Hs %<st %rm
%ru %[un %Sh/%<a %mt %ssl::>sni %ssl::>cert_subject
ssl-bump.inc:sslcrtd_program /usr/lib64/squid/ssl_crtd -s
/var/lib/squid/ssl_db -M 256MB
ssl-bump.inc:sslcrtd_children 32 startup=15 idle=5
ssl-bump.inc:ssl_bump peek all
ssl-bump.inc:ssl_bump bump all

I interpret that as peek at all traffic, then bump all. And that bumping
will involve create new certs signed by squidCA.cert and stored under
/var/lib/squid/ssl_db

However, on an empty system, "curl -vi -xlocalhost:3128
https://facebook.com/" shows a SSL session that *doesn't* involve
squidCA - and indeed there are no changes made under 
/var/lib/squid/ssl_db (yes the files/dirs exists and perms are correct).

ie no matter what https website I go to, they are all spliced -
exclusively "TCP_TUNNEL/200" in the logs

I cranked up debug_options and saw this


2015/08/19 14:13:16.493 kid1| bio.cc(1065) parseV3Hello: Found server
name: facebook.com
2015/08/19 14:13:16.493 kid1| bio.cc(1050) parseV3Hello: TLS Extension:
ff01 of size:1
2015/08/19 14:13:16.493 kid1| bio.cc(1050) parseV3Hello: TLS Extension:
d of size:16
2015/08/19 14:13:16.493 kid1| bio.cc(260) read: Hold flag is set, retry
latter. (Hold 11bytes)
2015/08/19 14:13:16.493 kid1| bio.cc(170) stateChanged: FD 24 now:
0x2002 23RCHA (SSLv2/v3 read client hello A)
2015/08/19 14:13:16.493 kid1| ModEpoll.cc(116) SetSelect: FD 24, type=1,
handler=1, client_data=0x3d9b8f8, timeout=0
2015/08/19 14:13:16.493 kid1| client_side.cc(4240)
clientPeekAndSpliceSSL: SSL_accept failed.

I recall hearing that some new code has been introduced that helps squid
"magically" figure out whether to even bother bumping some traffic
types? Is this related? It smells like squid has already decided to not
bump: based on it's own logic more than the config? (ie is my config
correct - but irrelevant)

This is squid-3.5.7 on Fedora-22

-- 
Cheers

Jason Haar
Corporate Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1