[squid-users] https intercept breaks non-HTTPS port 443 traffic?

[Jason Haar]

Hi there

Now that I've got ssl-bump working with port 443 intercept, I now find
non-HTTPS apps that operate on port 443 no longer work. eg for ssl-bump
in standard proxy mode I had an ACL to disable bump when an application
(like Skype, which doesn't use HTTPS) tried CONNECT-ing to ip addresses,
but with intercept mode that needed to be removed as all outbound https
intercepted sessions begin with them being to an ip address.

I just brought up a remote SSH server on port 443 and when I try to
telnet to it, instead of getting the OpenSSH banner, I see nothing, but
the remote server receives a SSL transaction from squid. All makes
sense, but is there a way for bump to "fail open" on non-SSL traffic? I
see squid 3.5 mentions "peek" and "at_step" - are those components going
to be the mechanism to solve this issue? Just curious, I'm only
testing/playing with intercepting port 443, but it's interesting to see
where this is going

Finally, when I attempted this connection, cache.log reported

fwdNegotiateSSL: Error negotiating SSL connection on FD 25:
error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol (1/-1/0)

I guess that's it squealing about getting non-SSL content back from the
server (ie the SSH banner). Shouldn't that be a bit more verbose - to
help sysadmins figure out what was behind it. eg

fwdNegotiateSSL: Error negotiating SSL connection from
192.168.22.11:44382 -> 1.2.3.4:443 (FD 25): error:140770FC:SSL
routines:SSL23_GET_SERVER_HELLO:unknown protocol (1/-1/0)

At the very least, with that I could have a cronjob grep through my
cache.log to auto-create a "bump none" acl ;-)

Thanks

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