Re: [squid-users] Transparent deployment VS web services behind DNS load balancing

[Amos Jeffries]

On 26/09/23 05:35, Denis Roy wrote:
My installation is fairly simple: I run Squid 5.8 in transparent mode, 
on a pF based firewall (FreeBDS 14.0) .


I intercept both HTTP 80, and HTTPS 443. Splicing the exceptions I have 
in a whitelist, bumping everything else. Simple.


This is a relatively recent deployment, and it has been working well as 
far as web browser experience is concerned. Nonetheless, I have observed 
a certain amount of 409s sharing similarities (more on that later). Rest 
assured, I have made 100% certain my clients and Squid use the same 
resolver (Unbound), installed on the same box with a fairly basic 
configuration.


When I observe the 409s I am getting, they all share the same 
similarities: the original client request was from an application or OS 
related task,  using  DNS records with very low TTL. 5 minutes or less, 
often 2 minutes.  I could easily identify the vast majority of these 
domains as being load balanced with DNS solutions like Azure Traffic 
Manager, and Akamai DNS.


Now, this make sense: a thread on the client may essentially intiate a 
long running task that will last a couple of minutes (more than the 
TTL), during which it may actually establish a few connections without 
calling the gethostbyname function, resulting in squid detecting a 
forgery attempt since it will be unable to validate the dst IP match the 
intended destination domain. Essentially, creating "false positives'', 
and dropping legitimate traffic.




Aye, pretty good summary of the current issue.


I have searched a lot, and the only reliable way to completely solve 
this issue in a transparent deployment has been to implement a number of 
IP lists for such services (Azure Cloud, Azure Front Door, AWS, Akamai 
and such), bypassing squid completely based on the destination IP address.


I'd be interested to hear what other approaches there might be. Some 
package maintainers have chosen to drop the header check altogether ( 
https://github.com/NethServer/dev/issues/5348 
 ).



Nod. Thus opening everyone using that package to CVE-2009-0801 effects. 
This is a high risk action that IMO should be an explicit choice by 
admin to do, not a package distributor.



  I believe a better 
approach could be to just validate that the SNI of the TLS Client Hello 
match the certificate obtained from the remote web server, perform the 
usual certificate validation (is it trusted, valid, etc), and not rely 
so much on the DNS check


That is just swapping the client-presented Host header for 
client-presented SNI, and remotely-supplied DNS lookup for 
remotely-supplied certificate lookup. All the security considerations 
problems of CVE-2009-0801 open up again, but at the TLS trust layer 
instead of the HTTP(S) trust layer.


which can be expected to fail at times given 
how DNS load balancing is ubiquitous with native cloud solutions and 
large CDNs.  But implementing this change would require serious 
development, which I am completely unable to take care of.


Indeed.

Alternatively the design I have been trying to work towards slowly is 
verifying that all requests on the long-lived connection only go to the 
same origin/server IP. Once trust of that IP has been validated we 
should not have to re-verify every request against new DNS data, just 
against the past history of of the connection.


This approach though is also a lot of development.

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

Re: [squid-users] bug 4906 issue

[Matus UHLAR - fantomas]

On 2023-09-26 07:39, Matus UHLAR - fantomas wrote:

I have just encountered bug 4906 with squid-4.13 (Debian 11)

I could upgrade system fo Debian 12 with squid-5.7 but this issue 
doesn't seem to be resolved in it, at least:

http://www.squid-cache.org/Versions/v5/changesets/

does not mention that.


On 26.09.23 10:09, Alex Rousskov wrote:
We have not (knowingly) fixed bug 4906 yet. Moreover, there are many 
other places in Squid code that would result in problems similar to 
those reported in bug 4906. A comprehensive unofficial fix that 
addresses the root cause got stuck in my unofficial review queue since 
December 2019.

[...]
You can also try a small old unofficial v4.3 workaround patch attached 
to this email. I do not know whether it will apply to and work with 
4.13. If you are lucky, this workaround will address the immediate 
problem in your environment.


Thank you,

the patch itself did not apply cleanly, but only because one difference 
between code.  Modified patch has one line different, and it's not in 
patched code:



- if (const char *value = (*i)->match(request, al->reply, al)) {
+ if (const char *value = (*i)->match(request, al->reply, NULL)) {


I have compiled the core and seems that the line

acl mon src 10.a.b.c # FGT load balancer check

access_log syslog:local0.info squid !mon

ignores logging requests from 10.a.b.c properly

--
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.
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] bug 4906 issue

[Alex Rousskov]

On 2023-09-26 07:39, Matus UHLAR - fantomas wrote:


I have just encountered bug 4906 with squid-4.13 (Debian 11)

I could upgrade system fo Debian 12 with squid-5.7 but this issue 
doesn't seem to be resolved in it, at least:

http://www.squid-cache.org/Versions/v5/changesets/

does not mention that.


We have not (knowingly) fixed bug 4906 yet. Moreover, there are many 
other places in Squid code that would result in problems similar to 
those reported in bug 4906. A comprehensive unofficial fix that 
addresses the root cause got stuck in my unofficial review queue since 
December 2019.




I could try to test patch provided in that bugreport:
https://patch-diff.githubusercontent.com/raw/measurement-factory/squid/pull/20.patch
...but I find trying such complicated patch too risky.


You can also try a small old unofficial v4.3 workaround patch attached 
to this email. I do not know whether it will apply to and work with 
4.13. If you are lucky, this workaround will address the immediate 
problem in your environment.



HTH,

Alex.
Fix src ACL when access logging TCP probes

TCP probe transactions lack HttpRequest object, which is used when
checking ACLs before logging. For this reason, src ACL did not work. To
fix this, we need to supply ACLFilledChecklist with available address
information.

diff --git a/src/client_side.cc b/src/client_side.cc
index d61e278..368c607 100644
--- a/src/client_side.cc
+++ b/src/client_side.cc
@@ -407,91 +407,98 @@ ClientHttpRequest::logRequest()
 
 tvSub(al->cache.trTime, al->cache.start_time, current_time);
 
 if (request)
 prepareLogWithRequestDetails(request, al);
 
 #if USE_OPENSSL && 0
 
 /* This is broken. Fails if the connection has been closed. Needs
  * to snarf the ssl details some place earlier..
  */
 if (getConn() != NULL)
 al->cache.ssluser = sslGetUserEmail(fd_table[getConn()->fd].ssl);
 
 #endif
 
 /* Add notes (if we have a request to annotate) */
 if (request) {
 // The al->notes and request->notes must point to the same object.
 (void)SyncNotes(*al, *request);
 for (auto i = Config.notes.begin(); i != Config.notes.end(); ++i) {
 if (const char *value = (*i)->match(request, al->reply, NULL)) {
 NotePairs  = SyncNotes(*al, *request);
 notes.add((*i)->key.termedBuf(), value);
 debugs(33, 3, (*i)->key.termedBuf() << " " << value);
 }
 }
 }
 
 ACLFilledChecklist checklist(NULL, request, NULL);
+const auto clientConn = getConn() ? getConn()->clientConnection : nullptr;
+if (!request && clientConn) {
+// because could not obtain them from request
+checklist.src_addr = clientConn->remote;
+checklist.my_addr = clientConn->local;
+}
+
 if (al->reply) {
 checklist.reply = al->reply;
 HTTPMSGLOCK(checklist.reply);
 }
 
 if (request) {
 HTTPMSGUNLOCK(al->adapted_request);
 al->adapted_request = request;
 HTTPMSGLOCK(al->adapted_request);
 }
 // no need checklist.syncAle(): already synced
 checklist.al = al;
 accessLogLog(al, );
 
 bool updatePerformanceCounters = true;
 if (Config.accessList.stats_collection) {
 ACLFilledChecklist statsCheck(Config.accessList.stats_collection, 
request, NULL);
 statsCheck.al = al;
 if (al->reply) {
 statsCheck.reply = al->reply;
 HTTPMSGLOCK(statsCheck.reply);
 }
 updatePerformanceCounters = statsCheck.fastCheck().allowed();
 }
 
 if (updatePerformanceCounters) {
 if (request)
 updateCounters();
 
-if (getConn() != NULL && getConn()->clientConnection != NULL)
-clientdbUpdate(getConn()->clientConnection->remote, logType, 
AnyP::PROTO_HTTP, out.size);
+if (clientConn)
+clientdbUpdate(clientConn->remote, logType, AnyP::PROTO_HTTP, 
out.size);
 }
 }
 
 void
 ClientHttpRequest::freeResources()
 {
 safe_free(uri);
 safe_free(redirect.location);
 range_iter.boundary.clean();
 clearRequest();
 
 if (client_stream.tail)
 clientStreamAbort((clientStreamNode *)client_stream.tail->data, this);
 }
 
 void
 httpRequestFree(void *data)
 {
 ClientHttpRequest *http = (ClientHttpRequest *)data;
 assert(http != NULL);
 delete http;
 }
 
 /* This is a handler normally called by comm_close() */
 void ConnStateData::connStateClosed(const CommCloseCbParams &)
 {
 deleteThis("ConnStateData::connStateClosed");
 }
 
 #if USE_AUTH
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] access_log UDP format

[Matus UHLAR - fantomas]

On 22/09/23 01:15, Matus UHLAR - fantomas wrote:

I'm curious if the udp:// logging is syslog-compatible.

Do I just need to congigure proper logformat?


On 26.09.23 12:20, Amos Jeffries wrote:
The Squid "udp" logging module sends your log lines as opaque UDP 
packet payload to the named UDP server:port.


The Squid "syslog" logging module frames that data into the binary 
syslog protocol.


so, IIUC, the difference between feeding to syslog daemon (which would 
further forward it over network), and sending directly over UDP is that the 
latter does not have syslog protocol features like UTF8 encoding?



--
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.
2B|!2B, that's a question!
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users

[squid-users] bug 4906 issue

[Matus UHLAR - fantomas]

Hello,

I have just encountered bug 4906 with squid-4.13 (Debian 11)

I could upgrade system fo Debian 12 with squid-5.7 but this issue doesn't 
seem to be resolved in it, at least:

http://www.squid-cache.org/Versions/v5/changesets/

does not mention that.

when we're at it, seems that release notes for 5.9 have invalid links:
http://www.squid-cache.org/Versions/v5/squid-5.9-RELEASENOTES.html#ss1.2


Can anyone confirm if this problem persists?


I could try to test patch provided in that bugreport:
https://patch-diff.githubusercontent.com/raw/measurement-factory/squid/pull/20.patch
...but I find trying such complicated patch too risky.


I would like to avoid the "has request" ACL to ba able to see problems that 
come from other hosts than the load balancer.
 


--
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.
Christian Science Programming: "Let God Debug It!".
___
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users