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

[Amos Jeffries]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/11/2014 5:00 p.m., Jason Haar wrote:
> 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

Since you are experimenting and learning ... it is very important at
present to know where the HTTPS support is coming from as well as
going to.

In particular that for classical HTTPS support the proxy offloads all
SSL configuration setup and port 443 traffic to the OpenSSL library.
So Squid-3.1 and older never had anything at all to do with the
handshakes.

Bumping is gradually changing that, with Squid taking on more and more
responsibility for ever lower levels of the TLS encryption. Initial
client-first mode jumped in to replace the ServerHello wth a static
cert. Then client-first/server-first +mimic taking responsibility for
the high level certificate exchange process. Now 3.5 peek-n-splice
makes Squid responsible for the individual low-level bytes being
transferred around in TLS - though mostly as a spy-in-the-middle.
 Its an arms race, with Squid (in the persons of Measurement Factory
and sponsors) vs the entire TLS security community.

Personally I think we should have just applied QoS limiting on CONNECT
tunnels or started issuing 426 responses mandating TLS to the proxy.
But sponsors pay the bills and that kind of paradigm shift leads to
some obvious pain, whereas ssl-bump hides the pain until reality bites
back.

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

That is a direct result specific to the server-first logic in your
Squid version being applied to the traffic. It will change if
client-first is applied, and as version upgrades change the logic
itself. Neat idea though :-)

Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUYZOoAAoJELJo5wb/XPRjfRYIAJQ4CjWUpj+ZMw8ViLgeeu3D
hQHPbx9ln1NXAyk9KwiEGdwEBuVe6rTk4X3q+fCvdl8/1kHdVrRw3mNeIIJJRW8h
gbH6h0E+Oi6tL6jBs4pMsTqSjCsNK01nQtkDylHIVDKPLo7KUUyhJWBjiy4npxoq
VC37ufs8vtqrU76d7seTBGOCRWHQ+DoOAv+kPzJDQ3Z9YOfd/peD8qxfhHiHbw3R
fmkOh8n66f8qDwKUtnJjTUqvww3/akrAKFlIFnTcWvsED9vwHnxrNChTg8rdq27n
DgVF9GY5QZ3bFsScmMCQbl96lPE12SE+jIZU6aYrKOxCEC/D5izGBb5Dsmt3peI=
=+JVQ
-----END PGP SIGNATURE-----