-----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----- _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
