[squid-users] Some websites doesn't work with squid anymore

[Yuri]

And finally:

root @ cthulhu / # ping s.yimg.com
s.yimg.com is alive
root @ cthulhu / # telnet s.yimg.com 443
Trying 66.196.65.111...
Connected to s.gycs.b.yahoodns.net.
Escape character is '^]'.
^]
telnet> quit
Connection to s.gycs.b.yahoodns.net closed.

root @ cthulhu / # wget -S s.yimg.com
--2016-06-27 20:51:22--  http://s.yimg.com/
Connecting to 127.0.0.1:3128... connected.
Proxy request sent, awaiting response...
   HTTP/1.1 404 Not Found
   Date: Mon, 27 Jun 2016 14:51:22 GMT
   Via: http/1.1 l1.ycs.ams.yahoo.com (ApacheTrafficServer [c s f ])
   Server: ATS
   Cache-Control: no-store
   Content-Type: text/html
   Content-Language: en
   Y-Trace: 
BAEAQAAAAACLMdgmMGHAiwAAAAAAAAAAhCR03RQcuP8AAAAAAAAAAAAFNkOnXjC6AAU2Q6deMogWmZJXAAAAAA--
   Content-Length: 2823
   X-Cache: MISS from cthulhu
   X-Cache-Lookup: MISS from cthulhu:3128
   Connection: keep-alive
2016-06-27 20:51:22 ERROR 404: Not Found.

Aha! Using wget we can connect!

But browser pointed to www.yahoo.com shown only HTML page without any 
image, JS or CSS.

Look at this shit: https://i1.someimage.com/7SX2FRB.png

Yes, ISP can block sites. But only yimg.com and not whole yahoo? :) Ok, 
let's disable squid - viola! All opens right now like charm.

Something wrong with squid, right?


27.06.2016 20:40, Yuri пишет:
> Forgot about it: during testing reddit connectivity via squid squid 
> itself got errors in cache.log:
>
> 2016/06/27 20:37:21 kid1| Error negotiating SSL on FD 7: 
> error:00000000:lib(0):func(0):reason(0) (5/0/0)
> 2016/06/27 20:37:22 kid1| Error negotiating SSL on FD 10: 
> error:00000000:lib(0):func(0):reason(0) (5/0/0)
> 2016/06/27 20:37:36 kid1| Error negotiating SSL on FD 7: 
> error:00000000:lib(0):func(0):reason(0) (5/0/0)
> 2016/06/27 20:37:51 kid1| Error negotiating SSL on FD 7: 
> error:00000000:lib(0):func(0):reason(0) (5/0/0)
> 2016/06/27 20:38:06 kid1| Error negotiating SSL on FD 7: 
> error:00000000:lib(0):func(0):reason(0) (5/0/0)
> 2016/06/27 20:38:21 kid1| Error negotiating SSL on FD 7: 
> error:00000000:lib(0):func(0):reason(0) (5/0/0)
>
> Of course, this can be bug 4497. But it not visible to any excluding 
> me. :)
>
> 27.06.2016 20:32, Amos Jeffries пишет:
>> [ Please reply to the mailing list I dont do private support except for
>> paying customers. And you have not arranged for that in advance. ]
>>
>> On 28/06/2016 2:06 a.m., Adam Wright wrote:
>>> - Ok, ISP will see my http traffic, but will the ISP see which 
>>> websites I'm
>>> surfing?
>> If anyone can see HTTP traffic they can see what the traffic is about.
>>
>>
>>> - Browser is using the proxy. But access.log only shows the websites 
>>> which
>>> the browser connected successfully. For example I see cisco.com which I
>>> entered minutes ago for Yuri.
>>>
>>> 1467035091.072  15004 85.107.208.29 TCP_MISS/200 246 CONNECT
>>> supportforums.cisco.com:443 yeni DIRECT/141.101.115.192
>> The proxy log records every transaction through the proxy, at the time
>> that transaction completed. Whether it succeeded or not. Anything that
>> get started is prone to being logged.
>>
>> In the case above it was a CONNECT tunnel transferring some TLS wrapped
>> protocol - probably HTTPS, SPDY or WebSockets on port 443. It took
>> 15.004 seconds to do whatever took 246 bytes to transfer.
>>
>> So nothing in the log indicates either the browser is *not* using the
>> proxy for those transactions, or they are still ongoing as far as Squid
>> is concerned.
>>
>> It could be a case of browser using SPDY, QUICK or WebSockets protocols
>> instead of HTTP inside a TLS tunnel, or directly without the proxy.
>> Particularly if Chrome is involved.
>>
>> The case of ongoing connections is unfortunate. You can tune Squid
>> timeouts somewhat to make the proxy more sensitive and do its failover
>> to working destinations faster. But otherwise its a browser specific
>> problem that can only be fixed by the browser.
>>
>> It might be that whatever was happening inside that tunnel above got
>> stuck and timed out. To Squid the tunnel is opaque, so any type of error
>> in there is strictly between the browser and server.
>>
>> The tiny size on that log entry makes me suspect its TLS handshake
>> hanging and a 15sec timeout somewhere closes it down. If so the issue is
>> not Squid, its whatever in the server or browser is causing the TLS 
>> to hang.
>>
>>> - Right now I'm using maxthon, it also says "Error code 101
>>> (net::ERR_CONNECTION_RESET)" while I try to connect to those xxx 
>>> websites.
>>>
>> That seems to mean the proxy is closing the connection. But that would
>> mean the proxy is aware of it ending and record in the log what
>> transaction finished with aborting the connection.
>>
>> If there no log record, thats a very strong sign that the browser is not
>> using the proxy for that request.
>>
>> Amos
>>
>> _______________________________________________
>> squid-users mailing list
>> squid-users at lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
>