The latest tests shows that Squid for unknown reasons do outgoing
connection using IPv6 only.
Which leads to "Network unreacheble" with my ISP - it does not support IPv6.
Full wireshark dumps for single outgoing transaction attached to bug
already.
20.04.16 17:14, Eliezer Croitoru пишет:
He
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
18.04.16 22:11, Guy Helmer пишет:
>
>> On Apr 17, 2016, at 5:50 AM, Yuri Voinov wrote:
>>
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> *NIX means UNIX. Solaris is AT&T UNIX. Linux is not UNIX (C) Linus
Torvalds. :) We are not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
18.04.16 22:11, Guy Helmer пишет:
>
>> On Apr 17, 2016, at 5:50 AM, Yuri Voinov wrote:
>>
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> *NIX means UNIX. Solaris is AT&T UNIX. Linux is not UNIX (C) Linus
Torvalds. :) We are not
> On Apr 17, 2016, at 5:50 AM, Yuri Voinov wrote:
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> *NIX means UNIX. Solaris is AT&T UNIX. Linux is not UNIX (C) Linus Torvalds.
> :) We are not speaking about all possible OS'es. I suggests the matter in
> SSL/TLS, not OS or hands
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
http://bugs.squid-cache.org/show_bug.cgi?id=4497
Debul logs are here:
https://drive.google.com/file/d/0B4nS4FYXsqTfdlpqeHJSRWtmcFE/view?usp=sharing
Here is one transaction done from wget on separated testing setup.
17.04.16 20:41, Alex Roussko
On 04/17/2016 06:59 AM, Yuri Voinov wrote:
> IDK whats happening.
The answer is probably in the ALL,9 log. Since you can reproduce this
problem on an isolated system with a single transaction, you may be able
to analyze that log to pinpoint the failure. If you cannot or will not
perform that analy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
17.04.16 15:16, Amos Jeffries пишет:
> On 17/04/2016 4:55 a.m., Yuri Voinov wrote:
>>
>> So.
>>
>> Still has no ideas?
>>
>
> Only things I assume you probably already looked at:
>
> Maybe churn in the CA certificates. Linux and Windows distros h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
*NIX means UNIX. Solaris is AT&T UNIX. Linux is not UNIX (C) Linus
Torvalds. :) We are not speaking about all possible OS'es. I suggests
the matter in SSL/TLS, not OS or hands or something similar.
The problem is in CF, I think. As a maximum in pe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I've tried any ciphersuites, including SSL default. With no effect. I
don't think so the issue is in cipher's negotiation.
The only strange I found - queries to problematic sites directly from
proxy box (via proxy) with curl/wget works.
Only LAN
On 17/04/2016 4:55 a.m., Yuri Voinov wrote:
>
> So.
>
> Still has no ideas?
>
Only things I assume you probably already looked at:
Maybe churn in the CA certificates. Linux and Windows distros have had
CA cert package updates happen in the past few weeks.
The ChaCha cipher you mentioned Cloud
For me it works.
...
The first thing to do is publish the squid.conf with a bug report
and all other related info.
*NIX doesn't mean CentOS since on CentOS this specific issue doesn't
exit.
I assume that if it works on CentOS it will work almost the same for
U
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
So.
Still has no ideas?
16.04.16 22:50, Yuri Voinov пишет:
>
> 3.5.16 on *NIX is also has this issue.
>
> Only 3.5.16 Win64 is works like sharm.
>
> 16.04.16 17:18, Yuri Voinov пишет:
> > mozilla.org now has the same issue on Squid 4 like CloudFl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
3.5.16 on *NIX is also has this issue.
Only 3.5.16 Win64 is works like sharm.
16.04.16 17:18, Yuri Voinov пишет:
> mozilla.org now has the same issue on Squid 4 like CloudFlare:
>
> https://i1.someimage.com/P03GmSY.png
>
> All ok but handshake do
mozilla.org now has the same issue on Squid 4 like CloudFlare:
https://i1.someimage.com/P03GmSY.png
All ok but handshake does not complete:
root @ cthulhu / # /usr/local/bin/openssl s_client -connect
mozilla.org:443 -CApath /etc/ope/csw/ssl/certs
CONNECTED(0003)
depth=2 C = US, O = DigiCe
On 15/04/2016 6:31 a.m., Yuri Voinov wrote:
>
> Ok, nobody.
>
> Well.
>
> I've done my own research.
>
> My suggestions:
>
> CloudFlare now uses it's own custom OpenSSL 1.0.2 with very custom
> patches with CHACHA Poly support.
>
> This patches is not in upstream. Moreover, OpenSSL team no pl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Strange:
connect directly from server via wget using proxy is works:
root @ cthulhu /tmp # wget -S https://cloudflare.com
- --2016-04-15 02:19:41-- https://cloudflare.com/
Connecting to 127.0.0.1:3128... connected.
Proxy request sent, awaiting r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Finally.
1. Squid 4 can be built with LibreSSL.
2. Squid 4 with LibreSSL start supporting CHACHA20_POLY1305 cryptography.
3. Squid 4 with LibreSSL still can't connect with CloudFlare itself.
WBR, Yuri.
PS. I suggests bug in 4.x branch specific f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ok, nobody.
Well.
I've done my own research.
My suggestions:
CloudFlare now uses it's own custom OpenSSL 1.0.2 with very custom
patches with CHACHA Poly support.
This patches is not in upstream. Moreover, OpenSSL team no plans in the
foreseeab
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Any ideas?
Anybody?
13.04.16 2:37, Yuri Voinov пишет:
>
> I suggests the matter can be openssl not OS:
>
> root @ cthulhu /patch # openssl version -a
> OpenSSL 1.0.1s 1 Mar 2016
> built on: Tue Mar 1 15:42:26 2016
> platform: solaris64-x86_64-c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I suggests the matter can be openssl not OS:
root @ cthulhu /patch # openssl version -a
OpenSSL 1.0.1s 1 Mar 2016
built on: Tue Mar 1 15:42:26 2016
platform: solaris64-x86_64-cc-sunw
options: bn(64,64) rc4(16x,int) des(ptr,cisc,16,int) idea(int
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
root @ cthulhu /patch # dig www.cloudflare.com
; <<>> DiG 9.6-ESV-R11-P4 <<>> www.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32548
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0
What "dig www.cloudflare.com" results with?
Also what OS are you using? I am using CentOS 7 up to date...
Eliezer
On 12/04/2016 21:39, Yuri Voinov wrote:
root @
cthulhu /patch # openssl s_client -cipher
'ECDHE-ECDSA-AES128-GCM-SHA256' -connect w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
My openssl test show the next Cloudflare cipher:
ECDHE-ECDSA-AES128-GCM-SHA256
So, result is:
root @ cthulhu /patch # openssl s_client -cipher
'ECDHE-ECDSA-AES128-GCM-SHA256' -connect www.cloudflare.com:443
CONNECTED(0003)
depth=3 C = SE, O
Hey Yuri,
I will try to test it with couple versions of 4.0.x.
But it's weird...
The reason it's weird is since some kind of trust or understand this
test:
https://www.ssllabs.com/ssltest/analyze.html?d=www.cloudflare.com&s=198.41.214.162&latest
I am not an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
UPDATE:
Every failed connect produce the next sequence in access.log:
1460474791.631 15444 192.168.100.103 NONE_ABORTED/200 0 CONNECT
198.41.215.162:443 - ORIGINAL_DST/198.41.215.162 -
1460474791.658 0 192.168.100.103 NONE/503 3951 GET
http
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
UPDATE:
https://i1.someimage.com/b8w5dFz.png
This is answer from Cloudflare support.
But: 3.5.16 can deal with ECDSA TLS 1.2 but 4.0.8 not?
12.04.16 17:55, Yuri Voinov пишет:
> Does anybody faces this problem with 4.0.8:
>
> https://i1.someimag
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::lib(0):func(0):reason(0) (5/0/0)
and "NONE/503" in access.log.
Without proxy works like sharm
28 matches
Mail list logo
