Re: [squid-users] sslBump adventures in enterprise production environment
Hi. On 16.11.2015 0:39, Alex Rousskov wrote: > On 11/15/2015 12:03 PM, Eugene M. Zheganin wrote: >> It's not even a HTTPS, its a tunneled HTTP CONNECT. But >> squid for some reason thinks there shoudl be a HTTPS inside. > Hello Eugene, > > Squid currently supports two kinds of CONNECT tunnels: > > 1. A regular opaque tunnel, as intended by HTTP specifications. > > 2. An inspected tunnel containing SSL/TLS-encrypted HTTP traffic. > > Opaque tunnels are the default. Optional SslBump-related features allow > the admin to designate admin-selected CONNECT tunnels for HTTPS > inspections (of various depth). This distinction explains why and when > Squid expects "HTTPS inside". > > There is currently no decent support for inspecting CONNECT tunnels > other than SSL/TLS-encrypted HTTP (i.e., HTTPS) tunnels. > > Splicing a tunnel at SslBump step1 converts a to-be-inspected tunnel > into an opaque tunnel before inspection starts. > > The recently added on_unsupported_protocol directive can automatically > convert being-inspected non-HTTPS tunnels into opaque ones in some > common cases, but it needs more work to cover more cases. > > > AFAICT, you assume that "splicing" turns off all tunnel inspection. This > is correct for step1 (as I mentioned above). This is not correct for > other steps because they happen after some inspection already took > place. Inspection errors that on_unsupported_protocol cannot yet handle, > may result in connection termination and other problems. > > > If Squid behavior contradicts some of the above rules, it is probably a > bug we should fix. Otherwise, it is likely to be a missing feature. > > > Finally, if Squid kills your ICQ (non-HTTPS) client tunnels, you need to > figure out whether those connections are inspected (i.e., go beyond > SslBump step1). If they are inspected, then this is not a Squid bug but > a misconfiguration (unless the ACL code itself is buggy!). If they are > not inspected, then it is probably a Squid bug. I do not have enough > information to distinguish between those cases, but I hope that others > on the mailing list can guide you towards a resolution given the above > information. > Thanks a lot for this explicit explanation. I managed to solve the problem with ICQ using the information above, no matter what port, 5190 or 443 it's tunneled into. Even "on_unsupported_protocol" isn't needed, so the whole thing works just fine on 3.5.x. In case someone will need this too, I decided to post my config part: # # Minimum ICQ configuration, # works for QIP 2012 and squid/ssl_bump, login.icq.com port should be either 443 or 5190 # acl icq dstdomain login.icq.com acl icqport port 443 acl icqport port 5190 # mail.ru network where ICQ servers reside acl icqip dst 178.237.16.0/20 acl step1 at_step SslBump1 # # http_access part is needed; not shown here since it's ordinary, for qip or web clients to work # # this should be somewhere near the top of the ssl_bump directives piece ssl_bump splice step1 icq ssl_bump splice step1 icqip icqport [...other ssl_bump directives...] Thanks. Eugene. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] sslBump adventures in enterprise production environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 17.11.15 15:46, Christos Tsantilas пишет: > On 11/16/2015 08:00 AM, Eugene M. Zheganin wrote: >> Hi. >> >> On 16.11.2015 00:14, Yuri Voinov wrote: >> >>> It's common knowledge. Squid is unable to pass an unknown protocol on >>> the standard port. Consequently, the ability to proxy this protocol does >>> not exist. >>> >>> If it was simply a tunneling ... It is not https. And not just >>> HTTP-over-443. This is more complicated and very marginal protocol. >>> >> I'm really sorry to tell you that, but you are perfectly wrong. These >> non-HTTPS tunnels have been working for years. And this isn't JTTPS >> because of: >> >> # openssl s_client -connect login.icq.com:443 >> CONNECTED(0003) >> 34379270680:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown >> protocol:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_clnt.c:782: > > This is does not looks like an SSL protocol. > It can not be used on SSL-bumping squid port. We know. But this IM also don't work over simple forwarding non-ssl-bumped Squid port too. BTW, why? > > The "on_unsupported_protocol" configuration parameter which exist on squid-trunk and squid-4.x maybe is useful for your case. Heh, back to future.. > > >> --- >> no peer certificate available >> --- >> No client certificate CA names sent >> --- >> SSL handshake has read 7 bytes and written 297 bytes >> --- >> New, (NONE), Cipher is (NONE) >> Secure Renegotiation IS NOT supported >> Compression: NONE >> Expansion: NONE >> --- >> >> Eugene. > > > ___ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWS3uQAAoJENNXIZxhPexGZj4H/1hfrEaDAQU2DSvOw8+IgIqx TVhPxjdbd2eCEHC/UwEriG5QVT3H8O9Pe3itWr/WbfI5/5cp4XzBz15wLq5db9Md qAPEdCCY9wxSoGEBTJ+oHtS9kvY8+YJS8I/KWPMaRdzeKbz79BnfXovblxwnhJa4 znTGJTl55jesHF/u7SkPZmGdBfN9y6fiJAuJY9Tj572NwkvdKVJ99hq8/QwsTjYU aXHJk9evkptbNNZwApMZI4VLrfEph/MBJ2fK8wNVWZU8NOt1E86OhXBqPoe2tnum 8WDJxeT73XAhjSUziR17idTOSAuwYSEwjBE+5+YiHcV8UUt1aMtAnDXN0yRP1Mk= =vkYq -END PGP SIGNATURE- ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] sslBump adventures in enterprise production environment
On 11/16/2015 08:00 AM, Eugene M. Zheganin wrote: Hi. On 16.11.2015 00:14, Yuri Voinov wrote: It's common knowledge. Squid is unable to pass an unknown protocol on the standard port. Consequently, the ability to proxy this protocol does not exist. If it was simply a tunneling ... It is not https. And not just HTTP-over-443. This is more complicated and very marginal protocol. I'm really sorry to tell you that, but you are perfectly wrong. These non-HTTPS tunnels have been working for years. And this isn't JTTPS because of: # openssl s_client -connect login.icq.com:443 CONNECTED(0003) 34379270680:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_clnt.c:782: This is does not looks like an SSL protocol. It can not be used on SSL-bumping squid port. The "on_unsupported_protocol" configuration parameter which exist on squid-trunk and squid-4.x maybe is useful for your case. --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 297 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- Eugene. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] sslBump adventures in enterprise production environment
On 11/15/2015 11:13 PM, Eugene M. Zheganin wrote: > On 16.11.2015 00:39, Alex Rousskov wrote: >> Squid currently supports two kinds of CONNECT tunnels: >> >> 1. A regular opaque tunnel, as intended by HTTP specifications. >> >> 2. An inspected tunnel containing SSL/TLS-encrypted HTTP traffic. >> >> Opaque tunnels are the default. Optional SslBump-related features allow >> the admin to designate admin-selected CONNECT tunnels for HTTPS >> inspections (of various depth). This distinction explains why and when >> Squid expects "HTTPS inside". > Seems like the lack of understanding is my main problem. I read > Peek/Splice article in wiki on an on, but I just cannot catch it: > > - are the sslBump directives evaluated in order and does the order > matter (I assume it does) ? Yes and yes. This is described in squid.conf.documented IIRC. > - (the most difficult thing to understand) I just cannot understand the > "step1" approach. I can understand splice/bump thing - it's like we > splice or we bump. I cannot understand other stepX-related actions, what > they do and when do I need'em (and when I do not). The wiki describes what each step and each action does. I understand that those descriptions may not be sufficient. Better documentation is welcomed, and you are encouraged to ask specific questions to provide that "better documentation" to yourself and others. You are in a better position to improve documentation than I am! > - I cannot understand what is the relation between http_access and > sslBump, and I assume there is one. This is poorly documented indeed. For some additional info, see Squid bug 4340 summary: http://bugs.squid-cache.org/show_bug.cgi?id=4340 > When I first discovered sslBump I > thought I will be able to block HTTP objects inside HTTPS session - like > pictures, or particular scripts, or particular MIME types, and it seems > like I was able to do that, Sure, you can block messages inside a bumped inspected tunnel. Once the tunnel is bumped (not spliced!), it works almost like a regular HTTP message stream (but there are exceptions like authentication and peer selection). Most difficulties are related to blocking tunnelling attempts themselves. In other words, blocking CONNECT messages (at various bumping stages before the tunnel is bumped). > For example this number of directives is straightforward: > > ===Cut=== > acl foo dst 192.168.0.1 > acl bar dst 192.168.0.2 > > sslBump bump foo > sslBump splice bar > ===Cut=== > > It's one dst we bump and the other we splice. The above configuration is not as "straightforward" as you might think: * If you are dealing with real CONNECT requests (not intercepted tunnels), a real CONNECT request may be for a host name and Squid will need to look up the IP address. This may affect dst matching. * You did not tell Squid what to do when neither dst matches. There were bugs in this area. The latest Squids should splice (but if you add more ssl_bump rules, they may affect the default action). IIRC, this is described in squid.conf.documented. * Bumping (even at step1) requires SSL/TLS validations of various kinds. Those validations may lead to errors. * Bumping at step1 may be subject to the following Squid bug: http://bugs.squid-cache.org/show_bug.cgi?id=4327 > Can you describe a situation when I need to peek or stare? You need to peek or stare if you need SSL/TLS handshake information to make a final bump/splice/terminate/block decision. For example, * Your ACLs need host names, not IP addresses. Even in a forwarding environment (i.e., real CONNECT requests), host names may not be available without peeking or staring (or reverse DNS lookups, but those are rarely reliable). * Your ACLs need origin server certificate details. * You do not want to splice connections to origin servers that have revoked SSL certificates. HTH, Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] sslBump adventures in enterprise production environment
16.11.15 12:00, Eugene M. Zheganin пишет: Hi. On 16.11.2015 00:14, Yuri Voinov wrote: It's common knowledge. Squid is unable to pass an unknown protocol on the standard port. Consequently, the ability to proxy this protocol does not exist. If it was simply a tunneling ... It is not https. And not just HTTP-over-443. This is more complicated and very marginal protocol. I'm really sorry to tell you that, but you are perfectly wrong. These non-HTTPS tunnels have been working for years. And this isn't JTTPS because of: Eugene, you don't understand me. I told, that this is non-HTTPS-over-443-port. And this is well-known information. The problem is: Now Squid don't know, how to operate this tunnels. # openssl s_client -connect login.icq.com:443 CONNECTED(0003) 34379270680:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_clnt.c:782: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 297 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- Eugene. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] sslBump adventures in enterprise production environment
On 11/15/2015 12:03 PM, Eugene M. Zheganin wrote: > It's not even a HTTPS, its a tunneled HTTP CONNECT. But > squid for some reason thinks there shoudl be a HTTPS inside. Hello Eugene, Squid currently supports two kinds of CONNECT tunnels: 1. A regular opaque tunnel, as intended by HTTP specifications. 2. An inspected tunnel containing SSL/TLS-encrypted HTTP traffic. Opaque tunnels are the default. Optional SslBump-related features allow the admin to designate admin-selected CONNECT tunnels for HTTPS inspections (of various depth). This distinction explains why and when Squid expects "HTTPS inside". There is currently no decent support for inspecting CONNECT tunnels other than SSL/TLS-encrypted HTTP (i.e., HTTPS) tunnels. Splicing a tunnel at SslBump step1 converts a to-be-inspected tunnel into an opaque tunnel before inspection starts. The recently added on_unsupported_protocol directive can automatically convert being-inspected non-HTTPS tunnels into opaque ones in some common cases, but it needs more work to cover more cases. AFAICT, you assume that "splicing" turns off all tunnel inspection. This is correct for step1 (as I mentioned above). This is not correct for other steps because they happen after some inspection already took place. Inspection errors that on_unsupported_protocol cannot yet handle, may result in connection termination and other problems. If Squid behavior contradicts some of the above rules, it is probably a bug we should fix. Otherwise, it is likely to be a missing feature. Finally, if Squid kills your ICQ (non-HTTPS) client tunnels, you need to figure out whether those connections are inspected (i.e., go beyond SslBump step1). If they are inspected, then this is not a Squid bug but a misconfiguration (unless the ACL code itself is buggy!). If they are not inspected, then it is probably a Squid bug. I do not have enough information to distinguish between those cases, but I hope that others on the mailing list can guide you towards a resolution given the above information. HTH, Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] sslBump adventures in enterprise production environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 16.11.15 1:39, Alex Rousskov пишет: > On 11/15/2015 12:03 PM, Eugene M. Zheganin wrote: >> It's not even a HTTPS, its a tunneled HTTP CONNECT. But >> squid for some reason thinks there shoudl be a HTTPS inside. > > > Hello Eugene, > > Squid currently supports two kinds of CONNECT tunnels: > > 1. A regular opaque tunnel, as intended by HTTP specifications. > > 2. An inspected tunnel containing SSL/TLS-encrypted HTTP traffic. > > Opaque tunnels are the default. Optional SslBump-related features allow > the admin to designate admin-selected CONNECT tunnels for HTTPS > inspections (of various depth). This distinction explains why and when > Squid expects "HTTPS inside". > > There is currently no decent support for inspecting CONNECT tunnels > other than SSL/TLS-encrypted HTTP (i.e., HTTPS) tunnels. > > Splicing a tunnel at SslBump step1 converts a to-be-inspected tunnel > into an opaque tunnel before inspection starts. > > The recently added on_unsupported_protocol directive can automatically > convert being-inspected non-HTTPS tunnels into opaque ones in some > common cases, but it needs more work to cover more cases. > > > AFAICT, you assume that "splicing" turns off all tunnel inspection. This > is correct for step1 (as I mentioned above). This is not correct for > other steps because they happen after some inspection already took > place. Inspection errors that on_unsupported_protocol cannot yet handle, > may result in connection termination and other problems. > > > If Squid behavior contradicts some of the above rules, it is probably a > bug we should fix. Otherwise, it is likely to be a missing feature. > > > Finally, if Squid kills your ICQ (non-HTTPS) client tunnels, you need to > figure out whether those connections are inspected (i.e., go beyond > SslBump step1). If they are inspected, then this is not a Squid bug but > a misconfiguration (unless the ACL code itself is buggy!). If they are > not inspected, then it is probably a Squid bug. I do not have enough > information to distinguish between those cases, but I hope that others > on the mailing list can guide you towards a resolution given the above > information. I do not think it's killing them. It looks like an outgoing connection goes to the server, and then silence - of the reaction in the log is not there. Client hangs waiting for a response from server. > > > HTH, > > Alex. > > ___ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWSOR0AAoJENNXIZxhPexGeMYH/jWi9I1CtBwzSUbDiwp4kjvy wqvJ63lT/l11t4cgBPOjrSVvLbtt5OJY6C+4Z6xkFZX4PgUKnLu6zaIVH1Dg9LrN 2WjgAL/Tks/d4mLKDIM/0LzlIDaJprigjCcWWngRVJRVivkgI5Fz4VxqDThP+qCc n6oL1XUE9qjrpbat+N2/0FlOG4/w5koLObxY8vYVWjcEAiHMcChIgoDR/ijQ3qen ZDRmE7uw8aOi7Fa1+M0TJUOLo8fF3EzPQI9Q5Xvfq4orn2lhn3LVXJCFho3s1qpa 8AxeGqmYs4+te5L9gOvuF0Y5RPzo71TOIA9hHz0loHAGPye2D1Uygi7gJYp87zo= =FMhF -END PGP SIGNATURE- ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] sslBump adventures in enterprise production environment
On 11/15/2015 01:00 PM, Yuri Voinov wrote: > 16.11.15 1:39, Alex Rousskov пишет: >> Squid currently supports two kinds of CONNECT tunnels: >> 1. A regular opaque tunnel, as intended by HTTP specifications. >> 2. An inspected tunnel containing SSL/TLS-encrypted HTTP traffic. >> Opaque tunnels are the default. Optional SslBump-related features allow >> the admin to designate admin-selected CONNECT tunnels for HTTPS >> inspections (of various depth). This distinction explains why and when >> Squid expects "HTTPS inside". >> There is currently no decent support for inspecting CONNECT tunnels >> other than SSL/TLS-encrypted HTTP (i.e., HTTPS) tunnels. >> Splicing a tunnel at SslBump step1 converts a to-be-inspected tunnel >> into an opaque tunnel before inspection starts. >> The recently added on_unsupported_protocol directive can automatically >> convert being-inspected non-HTTPS tunnels into opaque ones in some >> common cases, but it needs more work to cover more cases. >> AFAICT, you assume that "splicing" turns off all tunnel inspection. This >> is correct for step1 (as I mentioned above). This is not correct for >> other steps because they happen after some inspection already took >> place. Inspection errors that on_unsupported_protocol cannot yet handle, >> may result in connection termination and other problems. >> If Squid behavior contradicts some of the above rules, it is probably a >> bug we should fix. Otherwise, it is likely to be a missing feature. >> Finally, if Squid kills your ICQ (non-HTTPS) client tunnels, you need to >> figure out whether those connections are inspected (i.e., go beyond >> SslBump step1). If they are inspected, then this is not a Squid bug but >> a misconfiguration (unless the ACL code itself is buggy!). If they are >> not inspected, then it is probably a Squid bug. I do not have enough >> information to distinguish between those cases, but I hope that others >> on the mailing list can guide you towards a resolution given the above >> information. > I do not think it's killing them. It looks like an outgoing connection > goes to the server, and then silence - of the reaction in the log is not > there. Client hangs waiting for a response from server. Same difference. "Killing" == "breaking" == "preventing from working correctly" in this context. Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] sslBump adventures in enterprise production environment
Hi. On 16.11.2015 00:14, Yuri Voinov wrote: > It's common knowledge. Squid is unable to pass an unknown protocol on > the standard port. Consequently, the ability to proxy this protocol does > not exist. > > If it was simply a tunneling ... It is not https. And not just > HTTP-over-443. This is more complicated and very marginal protocol. > I'm really sorry to tell you that, but you are perfectly wrong. These non-HTTPS tunnels have been working for years. And this isn't JTTPS because of: # openssl s_client -connect login.icq.com:443 CONNECTED(0003) 34379270680:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_clnt.c:782: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 297 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- Eugene. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] sslBump adventures in enterprise production environment
Hi. On 15.11.2015 0:43, Walter H. wrote: > On 13.11.2015 14:53, Yuri Voinov wrote: >> There is no solution for ICQ with Squid now. >> >> You can only bypass proxying for ICQ clients. > from where do the ICQ clients get the trusted root certificates? > maybe this is the problem, that e.g. the squid CA cert is only > installed in FF > and nowhere else ... From nowhere. It's not even a HTTPS, its a tunneled HTTP CONNECT. But squid for some reason thinks there shoudl be a HTTPS inside. Eugene. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] sslBump adventures in enterprise production environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-ICQ-contest-td4673938.html 16.11.15 1:03, Eugene M. Zheganin пишет: > Hi. > > On 15.11.2015 0:43, Walter H. wrote: >> On 13.11.2015 14:53, Yuri Voinov wrote: >>> There is no solution for ICQ with Squid now. >>> >>> You can only bypass proxying for ICQ clients. >> from where do the ICQ clients get the trusted root certificates? >> maybe this is the problem, that e.g. the squid CA cert is only >> installed in FF >> and nowhere else ... > From nowhere. It's not even a HTTPS, its a tunneled HTTP CONNECT. But > squid for some reason thinks there shoudl be a HTTPS inside. > > Eugene. > ___ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWSNp/AAoJENNXIZxhPexGU7QIAK+/EQGHac3kW8sYkzDWAazO qZ/WZzMU7NyZAjIKc9n9u8CvVq2KiIQHaS3yL0VVUZ+wzd28wToASHto73oJrmGw SECUE066a72SqQx0eC5thuT9PSrBwnger7uCy1DmxmU5OmBVdSLMCnFioTdIqzJV 3sWyYqedo/2mfXpgj3AMR3eZ/6y62diAO6GjD7pP3Qp8r0as4hcJUfC9UcPXFNOz Vx3okSMdaCfd+H0hyeKFZ/ZCSYHUosh4nk7vR0Y0QFed3mgRBEoeKw6F2ykNhQy/ vxWetXucVm+8ugk5CW56ON2YsPWTRjY/PObNZ2f1pnyzhD6xSBKz/hMHg3G3cOg= =90Z3 -END PGP SIGNATURE- ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] sslBump adventures in enterprise production environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 It's common knowledge. Squid is unable to pass an unknown protocol on the standard port. Consequently, the ability to proxy this protocol does not exist. If it was simply a tunneling ... It is not https. And not just HTTP-over-443. This is more complicated and very marginal protocol. 16.11.15 1:03, Eugene M. Zheganin пишет: > Hi. > > On 15.11.2015 0:43, Walter H. wrote: >> On 13.11.2015 14:53, Yuri Voinov wrote: >>> There is no solution for ICQ with Squid now. >>> >>> You can only bypass proxying for ICQ clients. >> from where do the ICQ clients get the trusted root certificates? >> maybe this is the problem, that e.g. the squid CA cert is only >> installed in FF >> and nowhere else ... > From nowhere. It's not even a HTTPS, its a tunneled HTTP CONNECT. But > squid for some reason thinks there shoudl be a HTTPS inside. > > Eugene. > ___ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWSNmbAAoJENNXIZxhPexGb3EH/iF1kJQvvNODlf8YysuYZofc vXqGhM+BERZenp1OgMVWt0MDEianQ/4C2zIoOgvDqyMD10in5bMDo54mT0HShBEC kP92NGPGmNTjJXWARUNWZAELx1Mzn+Z5XfY0ySxQDyHxpmkvpX/g7IE7uzdGiRJp 0Sn4x5WOUUbdUAbeSGTyC4rSpZr94vBDGHfWsKsCFaYqH2XkPCbrmg9YzxL20+6Q W8UUtsval65Wima7QwyFEY08kIKP+mj1uOesQOM4A/Qd7jo+tsX86xdvXuAUiLo+ bgj2Hd3fEIijzb7c/sIZBO2OUnKPILiYe7UZr4nkFu6NB1f4FX2qYtHxXKT5BMQ= =yhB5 -END PGP SIGNATURE- ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] sslBump adventures in enterprise production environment
Hi. On 13.11.2015 18:53, Yuri Voinov wrote: > There is no solution for ICQ with Squid now. > > You can only bypass proxying for ICQ clients. > There is: I can disable sslBump, and I did it already. It doesn't look production-ready anyway. Eugene. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] sslBump adventures in enterprise production environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 This will decrease request hit ratio minimum at 50% 14.11.15 20:11, Eugene M. Zheganin пишет: > Hi. > > On 13.11.2015 18:53, Yuri Voinov wrote: >> There is no solution for ICQ with Squid now. >> >> You can only bypass proxying for ICQ clients. >> > There is: I can disable sslBump, and I did it already. It doesn't look > production-ready anyway. > > Eugene. > ___ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWR1ADAAoJENNXIZxhPexGYq0H/0Q3T11WPX42hevtp6Fu7Vyq BV9o3bSpvISZ+HwnM55FLIyGM/nQi5+7xRVcLWEC/tERVCa/vz2ucmUeTC7anrc5 O0erhLimzlixMAfKPp+UzmIXv0/NoDqa2y6T5lRMhqY0ta5oyecZzEJXZb8aZz23 n53Lkw3bHOTLuB7o6Zvjz1TnLjwv/FBTKjTBauIJ6geDsj1RNLsDPzFGXV6u2RPZ AbJjsSjItIuuH34jHzjGpEgzkD8mDOz6bm445FQ31vx6NTsf82XMHMkuJ5Lp2bDl TO5Ht3SesMnzoUHcIE8sN4kvNLsoVn02/Tl34+oIISL0UJVEe87bm8OUAl249aE= =2FE0 -END PGP SIGNATURE- ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] sslBump adventures in enterprise production environment
On 13.11.2015 14:53, Yuri Voinov wrote: There is no solution for ICQ with Squid now. You can only bypass proxying for ICQ clients. from where do the ICQ clients get the trusted root certificates? maybe this is the problem, that e.g. the squid CA cert is only installed in FF and nowhere else ... 13.11.15 14:41, Eugene M. Zheganin пишет: Hi. Today I discovered that a bunch of old legacy ICQ clients that some people till use have lost the ability to use HTTP CONNECT tunneling with sslBump. No matter what I tried to allow direct splicing for them, all was useless: - arranging them by dst ACL, and splicing that ACL - arranging them by ssl::server_name ACL, and splicing it So I had to turn of sslBumping. Looks like it somehow interferes with HTTP CONNECT even when splicing it. Last version of sslBump part in the config was looking like that: acl icqssl ssl::server_name login.icq.com acl icqssl ssl::server_name go.icq.com acl icqssl ssl::server_name ars.oscar.aol.com acl icqssl ssl::server_name webim.qip.ru acl icqssl ssl::server_name cb.icq.com acl icqssl ssl::server_name wlogin.icq.com acl icqssl ssl::server_name storage.qip.ru acl icqssl ssl::server_name new.qip.ru acl icqlogin dst 178.237.20.58 acl icqlogin dst 178.237.19.84 acl icqlogin dst 94.100.186.23 ssl_bump splice children ssl_bump splice sbol ssl_bump splice icqlogin ssl_bump splice icqssl icqport ssl_bump splice icqproxy icqport ssl_bump bump interceptedssl ssl_bump peek step1 ssl_bump bump unauthorized ssl_bump bump entertainmentssl ssl_bump splice all I'm not sure that ICQ clients use TLS, but in my previous experience they were configured to use proxy, and to connect through proxy to the login.icq.com host on port 443. Sample log for unsuccessful attempts: 1447400500.311 21 192.168.2.117 TAG_NONE/503 0 CONNECT login.icq.com:443 solodnikova_k HIER_NONE/- - 1447400560.301 23 192.168.2.117 TAG_NONE/503 0 CONNECT login.icq.com:443 solodnikova_k HIER_NONE/- - 1447400624.832359 192.168.2.117 TCP_TUNNEL/200 0 CONNECT login.icq.com:443 solodnikova_k HIER_DIRECT/178.237.20.58 - 1447400631.038108 192.168.2.117 TCP_TUNNEL/200 0 CONNECT login.icq.com:443 solodnikova_k HIER_DIRECT/178.237.20.58 - maybe give 3.4.x a try, 3.5 seems to have bugs 3.4.x don't have ... or this is caused by the above ... smime.p7s Description: S/MIME Cryptographic Signature ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] sslBump adventures in enterprise production environment
Hi. Today I discovered that a bunch of old legacy ICQ clients that some people till use have lost the ability to use HTTP CONNECT tunneling with sslBump. No matter what I tried to allow direct splicing for them, all was useless: - arranging them by dst ACL, and splicing that ACL - arranging them by ssl::server_name ACL, and splicing it So I had to turn of sslBumping. Looks like it somehow interferes with HTTP CONNECT even when splicing it. Last version of sslBump part in the config was looking like that: acl icqssl ssl::server_name login.icq.com acl icqssl ssl::server_name go.icq.com acl icqssl ssl::server_name ars.oscar.aol.com acl icqssl ssl::server_name webim.qip.ru acl icqssl ssl::server_name cb.icq.com acl icqssl ssl::server_name wlogin.icq.com acl icqssl ssl::server_name storage.qip.ru acl icqssl ssl::server_name new.qip.ru acl icqlogin dst 178.237.20.58 acl icqlogin dst 178.237.19.84 acl icqlogin dst 94.100.186.23 ssl_bump splice children ssl_bump splice sbol ssl_bump splice icqlogin ssl_bump splice icqssl icqport ssl_bump splice icqproxy icqport ssl_bump bump interceptedssl ssl_bump peek step1 ssl_bump bump unauthorized ssl_bump bump entertainmentssl ssl_bump splice all I'm not sure that ICQ clients use TLS, but in my previous experience they were configured to use proxy, and to connect through proxy to the login.icq.com host on port 443. Sample log for unsuccessful attempts: 1447400500.311 21 192.168.2.117 TAG_NONE/503 0 CONNECT login.icq.com:443 solodnikova_k HIER_NONE/- - 1447400560.301 23 192.168.2.117 TAG_NONE/503 0 CONNECT login.icq.com:443 solodnikova_k HIER_NONE/- - 1447400624.832359 192.168.2.117 TCP_TUNNEL/200 0 CONNECT login.icq.com:443 solodnikova_k HIER_DIRECT/178.237.20.58 - 1447400631.038108 192.168.2.117 TCP_TUNNEL/200 0 CONNECT login.icq.com:443 solodnikova_k HIER_DIRECT/178.237.20.58 - Thanks. Eugene. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] sslBump adventures in enterprise production environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 There is no solution for ICQ with Squid now. You can only bypass proxying for ICQ clients. 13.11.15 14:41, Eugene M. Zheganin пишет: > Hi. > > Today I discovered that a bunch of old legacy ICQ clients that some > people till use have lost the ability to use HTTP CONNECT tunneling with > sslBump. No matter what I tried to allow direct splicing for them, all > was useless: > > - arranging them by dst ACL, and splicing that ACL > - arranging them by ssl::server_name ACL, and splicing it > > So I had to turn of sslBumping. Looks like it somehow interferes with > HTTP CONNECT even when splicing it. > Last version of sslBump part in the config was looking like that: > > > acl icqssl ssl::server_name login.icq.com > acl icqssl ssl::server_name go.icq.com > acl icqssl ssl::server_name ars.oscar.aol.com > acl icqssl ssl::server_name webim.qip.ru > acl icqssl ssl::server_name cb.icq.com > acl icqssl ssl::server_name wlogin.icq.com > acl icqssl ssl::server_name storage.qip.ru > acl icqssl ssl::server_name new.qip.ru > > acl icqlogin dst 178.237.20.58 > acl icqlogin dst 178.237.19.84 > acl icqlogin dst 94.100.186.23 > > ssl_bump splice children > ssl_bump splice sbol > ssl_bump splice icqlogin > ssl_bump splice icqssl icqport > ssl_bump splice icqproxy icqport > > ssl_bump bump interceptedssl > > ssl_bump peek step1 > ssl_bump bump unauthorized > ssl_bump bump entertainmentssl > ssl_bump splice all > > I'm not sure that ICQ clients use TLS, but in my previous experience > they were configured to use proxy, and to connect through proxy to the > login.icq.com host on port 443. > Sample log for unsuccessful attempts: > > 1447400500.311 21 192.168.2.117 TAG_NONE/503 0 CONNECT > login.icq.com:443 solodnikova_k HIER_NONE/- - > 1447400560.301 23 192.168.2.117 TAG_NONE/503 0 CONNECT > login.icq.com:443 solodnikova_k HIER_NONE/- - > 1447400624.832359 192.168.2.117 TCP_TUNNEL/200 0 CONNECT > login.icq.com:443 solodnikova_k HIER_DIRECT/178.237.20.58 - > 1447400631.038108 192.168.2.117 TCP_TUNNEL/200 0 CONNECT > login.icq.com:443 solodnikova_k HIER_DIRECT/178.237.20.58 - > > Thanks. > Eugene. > ___ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWRetRAAoJENNXIZxhPexGbikH/0EqoRzosGamhDwM9h0tVMOJ 4rpARbMvHK3wejCgFkh+yp/X2kZi1+nRU9+baJ9vWAmKz6nqf7loFA3S+2s6HzNC 3WyAc+ICO5O2TtC+hSwPVOn4YCjbdROKSGTc/T6MoAnlfnEVIP9IV+Qb29F53bIE vcMovH4iH2zE7XfPwtZY7eBqEiBsiSG51dg744LHfTzJEYZWmGwTjd7LAQtIwO5e p+4FwG4oDxFksPXWEs4L2mpk8meKZvqP6CGTzTULYZdcokXcozTNw0YTz468MIzx 4zyDBZNdZXEZTLA5kL89OCVjfuXSm8WqggVvxq9SHqUYs2aJBVUHZRWNnvLhFMU= =v1X4 -END PGP SIGNATURE- ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
