On 17/07/2015 9:46 p.m., HackXBack wrote: > yes there is real problem and not only log lines, > you can read my first post i described what is happening ... > all applications in mobiles cant run till we make ssl_bump none to the ip's > that these applications use .. > and this is to much job to do .. > "Its not working" is back to very unhelpful info again. Specific details are critical. As is confirming the very latest code still has the problem. I mean details like; * "client is sending bytes XYZ instead of a TLS ClientHello packet", or * "client is sending clientHello with settings U,V which causes Squid to do W", or * "server is responding to client E,F,G,M settings with TLS alert Q, Squid then does R". TLS is hugely complicated set of details and a whole protocol by itself. Any one of those could be causing what appears to you as a failure even with Squid operating perfectly fine. Or Squid may be breaking something deeply subtle while othewise appearing to run fine. If I assume this is in regards to one of the other bugs you have brought up (like the halfClosedReader one). How is Squid to identify in advance that a certain request (but not the one before it, or after) is going to hit a bug that we cannot even track down a cause for yet? If the problem cause is known, we (mostly Christos) probably already fixed it. I know its frustrating, but sometimes reality really sucks. Intercepting TLS in the first place is a nasty can of worms. The resulting problems are plentiful and new ones continually being added (it is an actual literal "arms race" situation). The best help we can do to support Christos whose working on fixing it all is to keep up with his development progress and trying to avoid noise about already fixed things. (Sorry dont mean to lecture the choir). Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
