Re: [squid-users] RES: Squid 4.13 does not access Facebook

[Alex Rousskov]

On 1/7/22 4:39 PM, Graminsta wrote:
> I thought it was filtered by you guys before make it public.
> Other sensitive content I sent was erased before it came in this list.

Just to avoid misunderstanding: squid-users emails from subscribers are
not moderated by default. Content erasure, if any, is essentially
accidental (e.g., a side effect of the message hitting some attachment
size limits). System administration aside, there are no "guys" behind
this Project service -- just Squid users helping Squid users.

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

Re: [squid-users] RES: Squid 4.13 does not access Facebook

[Antony Stone]

On Friday 07 January 2022 at 22:39:41, Graminsta wrote:

> Now I have to change the pw of about 200 VPSs, hell.

I have to question the wisdom of using the same root PW on multiple servers, 
even when that PW has not been posted on a public mailing list.


Antony.

-- 
I bought a book on memory techniques, but I've forgotten where I put it.

   Please reply to the list;
 please *don't* CC me.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] RES: Squid 4.13 does not access Facebook

[Graminsta]

I I thought it was filtered by you guys before make it public.
Other sensitive content I sent was erased before it came in this list.

Its to bad.
Now I have to change the pw of about 200 VPSs, hell.

 

Marcelo Rodrigo

 

De: Bruno de Paula Larini [mailto:bruno.lar...@riosoft.com.br] 
Enviada em: sexta-feira, 7 de janeiro de 2022 17:13
Para: Graminsta; squid-users@lists.squid-cache.org
Assunto: Re: [squid-users] Squid 4.13 does not access Facebook

 

This is a public mailing list my friend.
Your IP address and password are available on the internet now.

I recommend you to disable that SSH service.

Take care next time.


Em 07/01/2022 16:11, Graminsta escreveu:



Hello :)

 

I have a specific problem with facebook access in squid 4.13 with Ubuntu 20.

It can access all other IPV6 websites but not https://www.facebook.com. Or any 
other facebook URL.

 

Outside of squid, the access is working via curl in the same server with the 
same IPV6 addresses.

It happens with all IPV6 servers I have.

 

 

Please don’t make the following data public from here:

I am a IPV6 proxy provider

You can use the proxy access to test it. Its 181.191.73.174:4000 user hugoebah 
pw senhabesta11

I will provide you with a SSH access to avoid you all the trouble to you make a 
lab.

SSH 181.191.73.174 user root pw esqueci11@

I am using this server in my Instagram automation but if you have to reboot it 
or do testing, you can do it. Its just dummy accounts.

 

Tks a lot ;)

 

Marcelo Rodrigo

Whatsapp 11 9 6854-3878





___
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

[squid-users] Squid 4.13 does not access Facebook

[Graminsta]

Hello :)

 

I have a specific problem with facebook access in squid 4.13 with Ubuntu 20.

It can access all other IPV6 websites but not https://www.facebook.com. Or
any other facebook URL.

 

Outside of squid, the access is working via curl in the same server with the
same IPV6 addresses.

It happens with all IPV6 servers I have.

 

 

Please don't make the following data public from here:

I am a IPV6 proxy provider

You can use the proxy access to test it. Its 181.191.73.174:4000 user
hugoebah pw senhabesta11

I will provide you with a SSH access to avoid you all the trouble to you
make a lab.

SSH 181.191.73.174 user root pw esqueci11@

I am using this server in my Instagram automation but if you have to reboot
it or do testing, you can do it. Its just dummy accounts.

 

Tks a lot ;)

 

Marcelo Rodrigo

Whatsapp 11 9 6854-3878

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

Re: [squid-users] Significant memory leak with version 5.x (not with 4.17)

[Alex Rousskov]

On 1/7/22 12:12 AM, Praveen Ponakanti wrote:

> Is there a build with the fix, or do you have some recommended steps
> to manually pull the source, patch the fix and then recompile?

Yes, applying the patch to official Squid sources and then bootstrapping
and building from patched sources is what folks using patches usually
have to do. Roughly speaking:

cd squid-x.y.z/
patch -p1 < ...
./bootstrap.sh
./configure
make
make check
sudo make install

The above steps usually require installing a few build-related tools
(and custom options like --prefix and --with-openssl). A capable
sysadmin should be able to get this done in most cases. It is possible
to avoid the bootstrapping step if the patch does not modify
bootstrapping-sensitive files and you can get a bootstrapped version of
the sources from http://www.squid-cache.org/Versions/

I am not aware of anybody providing ready-to-use builds that include the
proposed bug 5132 fix.


HTH,

Alex.


> On Thu, Jan 6, 2022 at 8:16 PM Alex Rousskov wrote:
> 
> On 1/6/22 2:50 AM, Praveen Ponakanti wrote:
> > Hi Alex/Amos,
> >
> > Do you still need memory logs from version 5.3 after stopping traffic
> > through the squid?
> 
> I cannot answer for Amos who asked for those logs, but you may want to
> try a fix posted at
> https://bugs.squid-cache.org/show_bug.cgi?id=5132#c27
> 
> 
> HTH,
> 
> Alex.
> 
> 
> > We have disabled traffic to the 5.3 version squid
> > about 6 hours ago and have not seen any memory being freed up since.
> > This node has used up ~50G more memory compared with 4.17 squid taking
> > similar traffic over the last 3+ weeks. I am collecting hourly memory
> > logs on 5.3 after stopping traffic. Let me know and I can attach the
> > log tomorrow morning.
> >
> > Thanks
> > Praveen
> >
> > On Mon, Dec 27, 2021 at 4:58 PM Praveen Ponakanti
> mailto:pponaka...@roblox.com>
> > >> wrote:
> >
> >     I cant make any changes to our prod squids this week. I have a
> squid
> >     instance (5.3v) in a test env but could not reproduce the leak by
> >     starting & stopping traffic with a bulk http req generator (wrk).
> >     Was able to send 175k rps @ 20k concurrent sessions (each doing a
> >     get on a 1KB object) through the 30-worker squid. This initially
> >     caused a 3G increase in memory usage and then flattened out after
> >     stopping the requests. If I restart the bulk reqs, the memory
> usage
> >     only goes up ~0.5GB and then drops back down. Live traffic is
> >     probably exercising a different code path within squid's
> memory pools.
> >
> >     On Mon, Dec 27, 2021 at 2:26 AM Lukáš Loučanský
> >     mailto:loucansky.lu...@kjj.cz>
> >> wrote:
> >
> >         After one day of running without clients my squid memory
> is stable
> >
> >         29345 proxy 20   0  171348 122360  14732 S   0.0   0.7  
> >         0:25.96 (squid-1) --kid squid-1 -YC -f /etc/squid5/squid.conf
> >         29343 root  20   0  133712  79264   9284 S   0.0   0.5  
> >         0:00.00 /usr/sbin/squid -YC -f /etc/squid5/squid.conf
> >
> >         Storage Mem size: 3944 KB Storage Mem capacity: 0.2% used,
> 99.8%
> >         free Maximum Resident Size: 489440 KB Page faults with
> physical
> >         i/o: 0 Memory accounted for: Total accounted: 15741 KB
> >         memPoolAlloc calls: 1061495 memPoolFree calls: 1071691 Total
> >         allocated 15741 kB So this does not seem to be the
> problem... L
> >
> >         Dne 26.12.2021 v 10:02 Lukáš Loučanský napsal(a):
> >>         ok - as it seems my squid quacked on low memory again today -
> >>
> >>         Dec 26 00:04:25 gw (squid-1): FATAL: Too many queued store_id
> >>         requests; see on-persistent-overload.#012    current master
> >>         transaction: master4629331
> >>         Dec 26 00:04:28 gw squid[15485]: Squid Parent: squid-1
> process
> >>         15487 exited with status 1
> >>         Dec 26 00:04:28 gw squid[15485]: Squid Parent: (squid-1)
> >>         process 28375 started
> >>
> >>         2021/12/26 00:01:20 kid1| helperOpenServers: Starting 5/64
> >>         'storeid_file_rewrite' processes
> >>         2021/12/26 00:01:20 kid1| ipcCreate: fork: (12) Cannot
> >>         allocate memory
> >>         2021/12/26 00:01:20 kid1| WARNING: Cannot run
> >>         '/lib/squid5/storeid_file_rewrite' process.
> >>         2021/12/26 00:01:20 kid1| ipcCreate: fork: (12) Cannot
> >>         allocate memory
> >>
> >>         I'm going to reroute my clients (which are on their days off
> >>         anyway) to direct 

Re: [squid-users] squid 5.3 frequent crash

[Alex Rousskov]

On 1/7/22 9:34 AM, Amos Jeffries wrote:
> On 7/01/22 06:00, Alex Rousskov wrote:
>> On 1/6/22 6:53 AM, Majed Zouhairy wrote:
>>> after upgrading today to 5.3 i'm getting:
>>
>>> 2022/01/06 14:27:18 kid1| FATAL: check failed: opening()
>>>  exception location: FwdState.cc(628) noteDestinationsEnd
>>
>>> what is the cause?
>>
>> This is most likely bug 5055 fixed in August 2021:
>> https://bugs.squid-cache.org/show_bug.cgi?id=5055
>>
>> In many environments, Squid v5 is unusable without that bug fix. I do
>> not know whether the v5 maintainer plans to officially backport the fix
>> from master/v6 to v5, but we would be happy to assist with that.


> The commit message documents that the bug fix is a small part of the
> changes made.

I am unable to separate many of the bug fixes from most other changes in
that commit. I am a fan of surgical fixes, but, sometimes, significant
code changes are required to address a set of bugs. One could, of
course, ignore most of the bugs fixed by the official commit and just
make sure that v5 does not violate the opening() MUST that triggered
this thread, but I see no point in doing that -- we will end up chasing
one known bug after another, sometimes in circles, and often via painful
triage.


> Others include altering the fundamental AsyncJob API behaviour -
> affecting every feature in Squid at their most fundamental levels.

I disagree with the above summary.


> That amount of change is not going into a "stable" release of
> Squid.

FWIW, IMHO, Squid v5 is much better with those changes than it is
without them. Once tested, the changes do not violate any fundamental
stability principles that I know of. However, I think it is best to let
the maintainer (i.e. you) make v5 admission decisions. I am just
providing feedback to facilitate informed decisions.


> I will consider patches for just the bug 5055 issue though.

To avoid misunderstanding, (the backport of) the official set of fixes
is what I am offering for your consideration. If others can address all
those bugs using smaller patches, great! Otherwise, I recommend
backporting the comprehensive fix and am happy to assist with that.


HTH,

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

Re: [squid-users] squid 5.3 frequent crash

[Amos Jeffries]

On 7/01/22 06:00, Alex Rousskov wrote:

On 1/6/22 6:53 AM, Majed Zouhairy wrote:

peace i have squid with ufdb guard, after upgrading today to 5.3 i'm
getting:



2022/01/06 14:27:18 kid1| FATAL: check failed: opening()
 exception location: FwdState.cc(628) noteDestinationsEnd



what is the cause?


This is most likely bug 5055 fixed in August 2021:
https://bugs.squid-cache.org/show_bug.cgi?id=5055

In many environments, Squid v5 is unusable without that bug fix. I do
not know whether the v5 maintainer plans to officially backport the fix
from master/v6 to v5, but we would be happy to assist with that. FWIW,
Factory has an _unofficial_ backport to v5-based code at:
https://github.com/measurement-factory/squid/commit/22b5f78



The commit message documents that the bug fix is a small part of the 
changes made. Others include altering the fundamental AsyncJob API 
behaviour - affecting every feature in Squid at their most fundamental 
levels. That amount of change is not going into a "stable" release of Squid.


I will consider patches for just the bug 5055 issue though.


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

Re: [squid-users] [ext] Re: Significant memory leak with version 5.x (not with 4.17)

[Ralf Hildebrandt]

> > I cannot answer for Amos who asked for those logs, but you may want to
> > try a fix posted at
> > https://bugs.squid-cache.org/show_bug.cgi?id=5132#c27
> > 
> > 
> 
> If that does not work the data you have collected may still be useful to
> figure out what exactly is hitting you.

Update (checked this morning): memory consumption (squid 5.3) seems to be 
stable.

I'll upgrade to 6.0 with the proposed fix, since bug 5055 becomes the
more pressing issue after the memleak is gone.

Ralf Hildebrandt
Charité - Universitätsmedizin Berlin
Geschäftsbereich IT | Abteilung Netzwerk

Campus Benjamin Franklin (CBF)
Haus I | 1. OG | Raum 105
Hindenburgdamm 30 | D-12203 Berlin

Tel. +49 30 450 570 155
ralf.hildebra...@charite.de
https://www.charite.de
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Significant memory leak with version 5.x (not with 4.17)

[Amos Jeffries]

On 7/01/22 17:16, Alex Rousskov wrote:

On 1/6/22 2:50 AM, Praveen Ponakanti wrote:

Hi Alex/Amos,

Do you still need memory logs from version 5.3 after stopping traffic
through the squid?




I asked so anyone taking on the bug would have data to work with. 3 days 
worth should be plenty to work with, so it is fine for you to stop now. 
If/when someone picks up the issue they may have more detailed info 
requests.




I cannot answer for Amos who asked for those logs, but you may want to
try a fix posted at
https://bugs.squid-cache.org/show_bug.cgi?id=5132#c27




If that does not work the data you have collected may still be useful to 
figure out what exactly is hitting you.


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

Re: [squid-users] MITM the MITM

[Amos Jeffries]

On 7/01/22 06:26, Grant Taylor wrote:

On 1/4/22 9:56 AM, Will BMD wrote:

I'm not aware of WCCP, but I'll look into it.


In short, the Web Cache Communications Protocol, "... specifies 
interactions between one or more routers (or Layer 3 switches) and one 
or more web-caches ...".


Link - Web Cache Communications Protocol (WCCP)
  - 
https://www.cisco.com/c/en/us/tech/content-networking/web-cache-communications-protocol-wccp/index.html 



WCCP can be pressed into service between an in-path device (usually L3) 
and a cache.  As such, I would hope ~> expect that the pseudo L3 
firewall can do it's work while using WCCP to allow a backend proxy do 
the actual caching, et la.





FYI, WCCP is one way of routing client traffic to Squid where that Squid 
is doing interception.


The Squid wiki has a whole section on how to setup both router/switch 
and Squid ends of the WCCP. 




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

Re: [squid-users] MITM the MITM

[Amos Jeffries]

FYI people,

When Squid

On 7/01/22 06:33, Grant Taylor wrote:

On 1/4/22 2:35 AM, Will BMD wrote:

HTTP proxy limitation

The system cannot decrypt traffic if an HTTP proxy is positioned 
between a client and your managed device, and the client and server 
establish a tunneled TLS/SSL connection using the CONNECT HTTP method. 
The Handshake Errors undecryptable action determines how the system 
handles this traffic.


I ... don't know what to make of this.  I would have some questions for 
the vendor (Cisco).




This reads to me like the FTDv supports plain-test HTTP on port 80 and 
HTTPS on port 443, not CONNECT tunnel intercept/decrypt, nor TLS between 
proxies.


So when a proxy like Squid is placed in front:

 * it cannot handle being configured as a peer to Squid. Because those 
peers get HTTPS as CONNECT tunnels, or the TLS is proxy-proxy TLS not 
client-server.


 * it probably can handle Squid terminating CONNECT requests and 
tunneling directly to port 443. Because that TLS is done by client, not 
Squid.


 * it probably can handle Squid SSL-Bump splice or bump traffic with 
*no* peers configured. Because Squid is then just another client talking 
over port 443 to a server. However, you will need Squid to trust the 
FTDv signing certificate, just like client for SSL-Bump need to trust 
Squid's.



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