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