Re: [squid-users] Assertion failed on Squid 4 when peer restarted.

[Amos Jeffries]

On 28/03/18 03:24, Alex Crow wrote:
> I have a squid 4.0.22 running peered with a 3.5.24 proxy. The latter
> machine stopped responding and I had to reboot it, and then the 4.0.22
> one crashed. Here's a log snippet:
> 
> 2018/03/27 15:01:48 kid1| WARNING: failed to unpack metadata because
> store entry metadata is too big
> 2018/03/27 15:04:09 kid1| Detected DEAD Sibling: webproxy.ifa.net
> 2018/03/27 15:04:09 kid1| Detected REVIVED Sibling: webproxy.ifa.net
> 2018/03/27 15:06:01 kid1| Detected DEAD Sibling: webproxy.ifa.net
> 2018/03/27 15:06:01 kid1| Detected REVIVED Sibling: webproxy.ifa.net
> 2018/03/27 15:06:44 kid1| Error negotiating SSL connection on FD 216:
> (104) Connection reset by peer
> 2018/03/27 15:06:57 kid1| Error negotiating SSL connection on FD 199:
> (104) Connection reset by peer
> 2018/03/27 15:06:57 kid1| Error negotiating SSL connection on FD 169:
> (104) Connection reset by peer
> 2018/03/27 15:06:57 kid1| Error negotiating SSL connection on FD 29:
> (104) Connection reset by peer
> 2018/03/27 15:06:57 kid1| Error negotiating SSL connection on FD 188:
> (104) Connection reset by peer
> 2018/03/27 15:06:57 kid1| Error negotiating SSL connection on FD 190:
> (104) Connection reset by peer
> 2018/03/27 15:07:12 kid1| Error negotiating SSL connection on FD 912:
> (104) Connection reset by peer
> 2018/03/27 15:07:13 kid1| Error negotiating SSL connection on FD 514:
> (104) Connection reset by peer
> 2018/03/27 15:07:26 kid1| ERROR: negotiating TLS on FD 236:
> error::lib(0):func(0):reason(0) (5/-1/104)
> 
> 2018/03/27 15:07:41 kid1| Error negotiating SSL connection on FD 129:
> (104) Connection reset by peer
> 2018/03/27 15:08:17 kid1| assertion failed: store.cc:1690: "!mem_obj"
> 
> Any ideas?
> 

First idea is to check bugzilla. I see nothing there.

Second is to upgrade to the latest v4 beta release (4.0.24 right now).

Third idea is to report to bugzilla or ask on squid-dev.

Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid 4.0.x stable?

[Amos Jeffries]

On 28/03/18 01:31, Mika Ristimäki wrote:
> Thanks. I was trying to find these issues
> from https://bugs.squid-cache.org/ but I couldn’t figure out how to do
> that. Could you pinpoint me to the issues that still need fixing? I
> guess the regression may be
> this https://bugs.squid-cache.org/show_bug.cgi?id=4831 but I’m not sure.
> 

Yes, 4831 the regression and 4710 is the outstanding critical bug. There
is now 4840 too, but that is looking like the issue is maybe not a Squid
bug.

FYI: the "Open Bugs" section at the end of
 (or similar for each Squid
version) links to the two bug lists I work from. They are also on the
RoadMap page for beta and alpha/development versions.

Our release policy is that for Squid versions in beta all the second
list bugs ("new in this version") which are rated major/critical/blocker
have to be closed for the release to become candidate for production
release.
 

 Squid-4 is at step #3 in that process now.


Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] How to configure a "proxy home" page ?

[Matus UHLAR - fantomas]

On 26.03.18 19:16, Yuri wrote:

SSH immediately notice you
when server key surprisingly changed.



26.03.2018 21:36, Matus UHLAR - fantomas пишет:

only when you already have the host key installed in your client. If
there's
MITM attack before you get the key, you will not notice that, unless you
get the key by other (secure) way.


On 26.03.18 21:45, Yuri wrote:

By analogue with TLS - let's imagine I've already been on site. With SSH
client notify me - "Hey, man, you trying to connect to server with 
fingerprint. Add it Yes/No?"

Instead this, TLS never notify me if third-party CA is known to client.


TLS was designed with periodic key rollout after a time, while SSH was not.
you must take care of it manually, or not atall.

SSH was (apparently) designed with possibility of (semi-)physical access to the
server, so you can verify keys personally.

This is not applicable with TLS, where everyone should be able to
communicate with everyone.

this way SSH is more similar to PGP where users have to exchange their
public keys to be trusted.

(you can get keys from trusted friend which is in fact simmilar to CA).


unlike SSL, SSH was not designed to be used globally between everyone,
more
within one or more "friend" organizations, so it didn't specify how host
keys are verified (the SSHFP DNS record just transfers trust to DNS,
which
can be hijacked too).

To be honest, a weak argument. A secure connection should always be
encrypted end-to-end and should not "trusted" third-parties as well.
Never. Otherwise it is insecure connection. IMHO.


the SSL is encrypted end-to-end. Trusted third-party CAs are just way to
avoid the need of everyone going to every company owning a site for the
server keys once in its lifetime (uaually a year).

even CA doesn't see your communication, unless they make the MITM attack
themselves.


Yes, users is involved in both cases. However the difference still here.
SSH is end-to-end always by design (we're not talking about things like
Kerberos here), TLS is not.



TLS was designed to be end-to-end encryption and the certificate
authority



As Stanislavsky said, "I do not believe it!"

End-to-end encryption and the (/trusted third-party/) certificate
authority these are antonyms.


Well, you can tell this to your clients but the main point - breaking into
users' communication that is supposed to be unbreakable by you - is
something you must explain to your clients and possibly to the lawyers.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
We are but packets in the Internet of life (userfriendly.org)
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] How to configure a "proxy home" page ?

[Matus UHLAR - fantomas]

On 26.03.18 21:47, Yuri wrote:

Waaa, Matus,

the idea is trivial.

Catch SSL UNKNOWN ISSUER error on squid's acl and redirect by 302 to
proxy page with instructions. Which requires user's involving.

How much can repeat the obvious 


you can't catch the "SSL UNKNOWN ISSUER" on squid, since it's a client error
(so squid can't see it) and it happens BEFORE squid sends ANYTHING to the
client.


26.03.2018 21:41, Matus UHLAR - fantomas пишет:

On 25.03.18 23:47, Eliezer Croitoru wrote:

I do not know your level of JS or other thing but... a splash page is
mearly a transition step.
Since you can check using JS if the certificate is installed


And how do you push the JS into the client?

when client tries to fetch https://www.google.com/ and you don't have
cert
for www.google.com, answering with any other certificate by unknown
authority will produce error before the JS is loaded.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux - It's now safe to turn on your computer.
Linux - Teraz mozete pocitac bez obav zapnut.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Assertion failed on Squid 4 when peer restarted.

[Alex Crow]

I have a squid 4.0.22 running peered with a 3.5.24 proxy. The latter 
machine stopped responding and I had to reboot it, and then the 4.0.22 
one crashed. Here's a log snippet:


2018/03/27 15:01:48 kid1| WARNING: failed to unpack metadata because 
store entry metadata is too big

2018/03/27 15:04:09 kid1| Detected DEAD Sibling: webproxy.ifa.net
2018/03/27 15:04:09 kid1| Detected REVIVED Sibling: webproxy.ifa.net
2018/03/27 15:06:01 kid1| Detected DEAD Sibling: webproxy.ifa.net
2018/03/27 15:06:01 kid1| Detected REVIVED Sibling: webproxy.ifa.net
2018/03/27 15:06:44 kid1| Error negotiating SSL connection on FD 216: 
(104) Connection reset by peer
2018/03/27 15:06:57 kid1| Error negotiating SSL connection on FD 199: 
(104) Connection reset by peer
2018/03/27 15:06:57 kid1| Error negotiating SSL connection on FD 169: 
(104) Connection reset by peer
2018/03/27 15:06:57 kid1| Error negotiating SSL connection on FD 29: 
(104) Connection reset by peer
2018/03/27 15:06:57 kid1| Error negotiating SSL connection on FD 188: 
(104) Connection reset by peer
2018/03/27 15:06:57 kid1| Error negotiating SSL connection on FD 190: 
(104) Connection reset by peer
2018/03/27 15:07:12 kid1| Error negotiating SSL connection on FD 912: 
(104) Connection reset by peer
2018/03/27 15:07:13 kid1| Error negotiating SSL connection on FD 514: 
(104) Connection reset by peer
2018/03/27 15:07:26 kid1| ERROR: negotiating TLS on FD 236: 
error::lib(0):func(0):reason(0) (5/-1/104)


2018/03/27 15:07:41 kid1| Error negotiating SSL connection on FD 129: 
(104) Connection reset by peer

2018/03/27 15:08:17 kid1| assertion failed: store.cc:1690: "!mem_obj"

Any ideas?

Thanks,

Alex

--
This message is intended only for the addressee and may contain
confidential information. Unless you are that person, you may not
disclose its contents or use it in any way and are requested to delete
the message along with any attachments and notify us immediately.
This email is not intended to, nor should it be taken to, constitute advice.
The information provided is correct to our knowledge & belief and must not
be used as a substitute for obtaining tax, regulatory, investment, legal or
any other appropriate advice.

"Transact" is operated by Integrated Financial Arrangements Ltd.
29 Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608 5300.
(Registered office: as above; Registered in England and Wales under
number: 3727592). Authorised and regulated by the Financial Conduct
Authority (entered on the Financial Services Register; no. 190856).
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Squid 4.0.x stable?

[Mika Ristimäki]

Thanks. I was trying to find these issues from https://bugs.squid-cache.org/ 
but I couldn’t figure out how to do that. Could you pinpoint me to the issues 
that still need fixing? I guess the regression may be this 
https://bugs.squid-cache.org/show_bug.cgi?id=4831 but I’m not sure.


-Mika

On 27 Mar 2018, 11.19 +0300, Amos Jeffries , wrote:
> On 27/03/18 19:50, Mika Ristimäki wrote:
> > Hi,
> >
> > According to http://www.squid-cache.org/Versions/ version 4.0.x is still
> > in beta. Are there any timelines/plans when it becomes stable?
> >
>
> We are now down to one major bug and one more recent regression to fix.
> I'm hoping for a few weeks, but then the plan was to release it a year
> ago now.
>
> Amos
> ___
> 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] Squid 4.0.x stable?

[Amos Jeffries]

On 27/03/18 19:50, Mika Ristimäki wrote:
> Hi,
> 
> According to http://www.squid-cache.org/Versions/ version 4.0.x is still
> in beta. Are there any timelines/plans when it becomes stable?
> 

We are now down to one major bug and one more recent regression to fix.
I'm hoping for a few weeks, but then the plan was to release it a year
ago now.

Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users