Hey Yuri,

I think that the bug solution or identification is requiring a full tcpdump trace for a single request as was mentioned on the bug report:
http://bugs.squid-cache.org/show_bug.cgi?id=4497#c39
http://bugs.squid-cache.org/show_bug.cgi?id=4497#c40

I have opened the port to my proxy, so you would be able to run couple requests to verify that your curl and wget and other clients doesn't have this "handshake" issue when accessing https://cloudflare.com using my local testing proxy.
Send me privately your origin IP address so I would add an exception in my proxy for it.

Eliezer

On 12/04/2016 14:55, Yuri Voinov wrote:
Does anybody faces this problem with 4.0.8:

https://i1.someimage.com/3lD2cvV.png

?

It accomplished this error in cache.log:

2016/04/12 17:39:38 kid1| Error negotiating SSL on FD 54: error:00000000:lib(0):func(0):reason(0) (5/0/0)

and "NONE/503" in access.log.

Without proxy works like sharm. 3.5.16 with the similar squid.conf works like sharm.

NB: Cloudflare support said, that they key feature for SSL is SNI and ECDSA now. AFAIK, 4.0.8 is fully supports this features.

Any advice will be helpful.

Yes, I know this looks like DDoS protection on Cloudflare. But WTF? Any workaround required. Half-Internet is hosted on Cloudflare.

WBR, Yuri
_______________________________________________
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

Reply via email to