Re: [squid-users] Getting SSL Connection Errors (Eliezer Croitoru)

[Usama Mehboob]

ery https website
> acl step1 at_step SslBump1
> acl step2 at_step SslBump2
> acl step3 at_step SslBump3
> ssl_bump peek step1 all
>
> # Deny requests to proxy instance metadata
> acl instance_metadata dst 169.254.169.254
> http_access deny instance_metadata
>
> # Filter HTTP Only requests based on the whitelist
> #acl allowed_http_only dstdomain .veevasourcedev.com <
> http://veevasourcedev.com>  .google.com <http://google.com>  .pypi.org <
> http://pypi.org>  .youtube.com <http://youtube.com>
> #acl allowed_http_only dstdomain .amazonaws.com <http://amazonaws.com>
> #acl allowed_http_only dstdomain .veevanetwork.com <
> http://veevanetwork.com>  .veevacrm.com <http://veevacrm.com>  .
> veevacrmdi.com <http://veevacrmdi.com>  .veeva.com <http://veeva.com>  .
> veevavault.com <http://veevavault.com>  .vaultdev.com <http://vaultdev.com>
> .veevacrmqa.com <http://veevacrmqa.com>
> #acl allowed_http_only dstdomain .documentforce.com <
> http://documentforce.com>   .sforce.com <http://sforce.com>  .force.com <
> http://force.com>  .forceusercontent.com <http://forceusercontent.com>  .
> force-user-content.com <http://force-user-content.com>  .lightning.com <
> http://lightning.com>  .salesforce.com <http://salesforce.com>  .
> salesforceliveagent.com <http://salesforceliveagent.com>  .
> salesforce-communities.com <http://salesforce-communities.com>  .
> salesforce-experience.com <http://salesforce-experience.com>  .
> salesforce-hub.com <http://salesforce-hub.com>  .salesforce-scrt.com <
> http://salesforce-scrt.com>  .salesforce-sites.com <
> http://salesforce-sites.com>  .site.com <http://site.com>  .sfdcopens.com
> <http://sfdcopens.com>  .sfdc.sh .trailblazer.me <http://trailblazer.me>
> .trailhead.com <http://trailhead.com>  .visualforce.com <
> http://visualforce.com>
>
>
> # Filter HTTPS requests based on the whitelist
> acl allowed_https_sites ssl::server_name .pypi.org <http://pypi.org>  .
> pythonhosted.org <http://pythonhosted.org>  .tfhub.dev <http://tfhub.dev>
> .gstatic.com <http://gstatic.com>  .googleapis.com <http://googleapis.com>
>
> acl allowed_https_sites ssl::server_name .amazonaws.com <
> http://amazonaws.com>
> acl allowed_https_sites ssl::server_name .documentforce.com <
> http://documentforce.com>   .sforce.com <http://sforce.com>  .force.com <
> http://force.com>  .forceusercontent.com <http://forceusercontent.com>  .
> force-user-content.com <http://force-user-content.com>  .lightning.com <
> http://lightning.com>  .salesforce.com <http://salesforce.com>  .
> salesforceliveagent.com <http://salesforceliveagent.com>  .
> salesforce-communities.com <http://salesforce-communities.com>  .
> salesforce-experience.com <http://salesforce-experience.com>  .
> salesforce-hub.com <http://salesforce-hub.com>  .salesforce-scrt.com <
> http://salesforce-scrt.com>  .salesforce-sites.com <
> http://salesforce-sites.com>  .site.com <http://site.com>  .sfdcopens.com
> <http://sfdcopens.com>  .sfdc.sh .trailblazer.me <http://trailblazer.me>
> .trailhead.com <http://trailhead.com>  .visualforce.com <
> http://visualforce.com>
> ssl_bump peek step2 allowed_https_sites
> ssl_bump splice step3 allowed_https_sites
> ssl_bump terminate step2 all
>
>
> connect_timeout 60 minute
> read_timeout 60 minute
> write_timeout 60 minute
> request_timeout 60 minute
>
> ## http filtering ###
> #http_access allow localnet allowed_http_only
> #http_access allow localhost allowed_http_only
> http_access allow localnet allowed_https_sites
> http_access allow localhost allowed_https_sites
> # And finally deny all other access to this proxy
> http_access deny all
>
> # Uncomment and adjust the following to add a disk cache directory.
> #cache_dir ufs /var/spool/squid 100 16 256
>
> # Leave coredumps in the first cache dir
> coredump_dir /var/spool/squid
>
> #
> # Add any of your own refresh_pattern entries above these.
> #
> refresh_pattern ^ftp: 1440 20% 10080
> refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
> refresh_pattern . 0 20% 4320
>
>
>
> thanks
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.squid-cache.org/pipermail/squid-users/attachments/20220225/9f94f144/attachment-0001.htm
> >
>
>
>
> --
>
> End of squid-users Digest, Vol 90, Issue 38
> ***
>
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] peek & splice only to log ssl info

[Alex Rousskov]

On 2/25/22 14:36, Matus UHLAR - fantomas wrote:

I only intend to splice connections but after repeated reading 
https://wiki.squid-cache.org/Features/SslPeekAndSplice I still don't 
understand parts of the logic.


- is the combination described at:
https://wiki.squid-cache.org/Features/SslPeekAndSplice#Basic_Splicing_and_Bumping 


enough for logging SNI and cert info?


There are three combinations described in that section. The first peeks 
at SNI and certificate info (so the answer is "yes"). The other two are 
more complex and may not have access to some of that info in some cases.




- are peek and they completely equal at step 1?


Bugs notwithstanding, Squid does the same thing right after discovering 
that a peek or stare rule matched during step1 -- Squid tries to look at 
the TLS client Hello message (where SNI is stored).


The difference, if any, only comes after Squid looks at that 
ClientHello. Bugs notwithstanding(*), if no ssl_bump rule matches during 
step2, then the next Squid action will be either splice or bump, 
depending on which rule (peek or stare) matched at the first step.


By using "peek", you tell Squid that you intend to splice if everything 
goes alright; and by using stare, you tell Squid that you intend to 
bump. After step1, you can still change your mind (because the immediate 
Squid operations are the same -- look at ClientHello). After step2, you 
cannot (because Squid operations differ and, in modern environments, 
peeking precludes future bumping and staring precludes future splicing 
as detailed further below).


(*) There are recently discovered bugs in this area (that we are 
fixing), so you should not rely on this, but that is what Squid will be 
doing when those bugs are fixed. I do not recommend relying on such 
"defaults" anyway -- make sure the step after a peek or stare rule match 
has a matching rule.



- what's the difference between peek and splice that makes it impossible 
   (most of the time) to splice (stare) or bump (peek) the connection?


* When Squid peeks, it forwards the user agent TLS client Hello message 
to the TLS server intact. After forwarding that virgin Hello, Squid 
cannot become a part of the TLS conversation. Squid has to splice or 
terminate the connections, which are both TCP- not TLS-level operations.


* When Squid stares, Squid modifies the TLS client Hello received from 
the user agent to use Squid-specific TLS secrets and then sends the 
adapted ClientHello to the TLS server. After that, it is impossible for 
Squid to get out of the loop -- the conversation is now based on 
Squid-provided secrets. Squid has to bump or terminate the connections.



HTH,

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

Re: [squid-users] Trying to set up SSL cache - solved!

[Dave Blanchard]

On Sat, 26 Feb 2022 02:06:23 +1300
Amos Jeffries  wrote:

> Agreed. Luckily we hear you (Alex and I are pretty much "them" these days).
> 

Hopefully I don't sound unappreciative; I'm thankful for the work you've put 
into Squid, and the quick and useful responses you've given here on the list, 
which has resolved my problem. It's not always easy to properly document 
something that you are close to and see every day; it's often difficult to 
really see things how a stranger would, and as you've pointed out, proxy'ing in 
general isn't a simple subject. Squid is a powerful tool and I'm happy to have 
it available. Keep up the good work!

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

Re: [squid-users] Random trouble with image downloads

[Dave Blanchard]

On Sat, 26 Feb 2022 02:09:14 +1300
Amos Jeffries  wrote:

> I suspect you are seeing 
> 
> Unfortunately we do not have a good fix for it yet.

OK, it looks like the work is still ongoing, so I will implement some kind of 
workaround for now and check back on this later. Thanks for the info.

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

[squid-users] peek & splice only to log ssl info

[Matus UHLAR - fantomas]

Hello,

I'll upgrade some debian servers to debian 10 where squid-ssl package (4.13) 
is available and I'm searching for way to enhance current logging of CONNECT 
requests to include SSL data - SNI servername and possibly basic certificate 
info.


I only intend to splice connections but after repeated reading 
https://wiki.squid-cache.org/Features/SslPeekAndSplice I still don't 
understand parts of the logic.


- is the combination described at:
https://wiki.squid-cache.org/Features/SslPeekAndSplice#Basic_Splicing_and_Bumping
enough for logging SNI and cert info?

- are peek and they completely equal at step 1?

- what's the difference between peek and splice that makes it impossible 
  (most of the time) to splice (stare) or bump (peek) the connection?

  I guess I don't really need to know this one but I'm curious.


thanks for comments.

--
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.
Your mouse has moved. Windows NT will now restart for changes to take
to take effect. [OK]
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Trying to set up SSL cache

[Dave Blanchard]

On Sat, 26 Feb 2022 00:16:30 +1300
Amos Jeffries  wrote:

> [...]
>
> There are a few things to be aware of while troubleshooting:
> 
> * not all TLS connections can be bump'ed. TLS is designed to prevent 
> exactly the type of decrypt that bump does. If the client and server are 
> using TLS properly bump *will* fail.
> 
> 
> * Google are known to be rather pedantic about security. So having their 
> software at either end of the TLS when testing is more likely to hit 
> such non-decryptable TLS connections.
> 
> 
> * Checking the test web service for TLS certificate pinning or DANE. 
> Both of these lock the/some client into using the original server 
> certificate and they will unavoidably reject the Squid signing CA.
> 
> * Check traffic from the web server for HTTPS-Transport-Security or 
> Alt-Svc HTTP headers. Both of these can break SSL-Bump if they reach a 
> client. What is worse they can force arbitrarily long cache times for 
> the info they contain, causing breakage to extend across the whole 
> period. Only a full client purge of state and never receiving the info 
> again can via any protocol fix these.
> 
> 
> Amos

Hi Amos, this is very useful info; thank you. I've just added in some rules to 
drop the HSTS and Alt-Svc headers to avoid this trouble. Thanks for explaining 
step by step how these bump rules affect the proxy behavior.

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

Re: [squid-users] Trying to set up SSL cache

[Alex Rousskov]

On 2/25/22 06:16, Amos Jeffries wrote:

On 24/02/22 15:26, Dave Blanchard wrote:



ssl_bump peek all


Okay TLS handshake clientHello gets observed by Squid.


... and TLS ServerHello. The "all" ACL will match during SslBump step1 
_and_ step2




ssl_bump bump all


... now (step3) everything gets decrypted.


No, the above ssl_bump configuration line has no effect. In modern 
environments, one cannot bump after peeking at the server.



Squid bugs notwithstanding, the configuration in question is equivalent to:

  ssl_bump peek step1
  ssl_bump peek step2
  ssl_bump splice step3

No HTTP caching is possible for HTTPS transactions with this (or any 
other splicing) configuration, of course.


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

Re: [squid-users] Squid Question regarding tcp handshake

[Alex Rousskov]

On 2/24/22 10:03, Felipe Polanco wrote:

Does squid first complete the tcp handshake on its users and then a 
second handshake on the destination IP 


Yes, kind of. Keep in mind that Squid pretty much does not know anything 
about TCP handshakes, SYN packets, etc. Nearly all TCP-level work is 
done by the kernel and system libraries. Squid uses TCP socket I/O.


Also, there may be no corresponding Squid-server connection at all 
(e.g., errors and cache hits) or, as Amos has already noted, multiple 
Squid-server connections (e.g., trying different IP addresses associated 
with the same DNS name in HTTP request target).



or as soon as it receives the TCP 
SYN flag it does the same with the destination.


No, Squid does not known anything about the SYN flag. Squid does not act 
on the incoming TCP connection until a successful accept(2) system call 
announces/gives that connection to Squid. That system call extracts an 
already established (i.e. post-handshake) TCP connection from the 
queue(s) of TCP connections maintained by the kernel. The TCP handshake 
completes before Squid gets control back from accept() and, in the vast 
majority of cases, before Squid even calls accept().



HTH,

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

Re: [squid-users] Trying to set up SSL cache - solved!

[Alex Rousskov]

On 2/24/22 16:49, Dave Blanchard wrote:


This tutorial situation is really out of control. Sadly, this is what
can be expected to happen when the syntax is changed with every
version. Now we're in a real mess. I hope the Squid developers will
make up their minds on how they want the syntax to be structured,
build it that way, then LEAVE IT ALONE!


I do not know what tutorial(s) you are talking about, but ssl_bump 
syntax and the underlying principles have not changed for many years. 
The changing syntax is definitely not the problem. Squid bugs, lack of 
official tutorials, and TLS complexities/changes are.


SslBump is not compatible with a natural human desire to cut-and-paste 
examples from the first place they can find and see whether those 
examples "work" (multiplied by another human desire to publish their 
thoughts/results, regardless of the author level of expertise).


Can we publish an authoritative high-quality tutorial on SslBump? Sure! 
Unfortunately, the current lack of Project resources multiplied by 
chronic Project deficiencies do not leave us enough time to do that.


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

[squid-users] Getting SSL Connection Errors (Eliezer Croitoru)

[Usama Mehboob]

t;
> # Only allow cachemgr access from localhost
> http_access allow localhost manager
> http_access deny manager
>
> # We strongly recommend the following be uncommented to protect innocent
> # web applications running on the proxy server who think the only
> # one who can access services on "localhost" is a local user
> #http_access deny to_localhost
>
> #
> # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
> #
>
> # Example rule allowing access from your local networks.
> # Adapt localnet in the ACL section to list your (internal) IP networks
> # from where browsing should be allowed
>
> # And finally deny all other access to this proxy
>
> # Squid normally listens to port 3128
> #http_port 3128
> http_port 3129 intercept
> https_port 3130 cert=/etc/squid/ssl/squid.pem ssl-bump intercept
> http_access allow SSL_ports #-- this allows every https website
> acl step1 at_step SslBump1
> acl step2 at_step SslBump2
> acl step3 at_step SslBump3
> ssl_bump peek step1 all
>
> # Deny requests to proxy instance metadata
> acl instance_metadata dst 169.254.169.254
> http_access deny instance_metadata
>
> # Filter HTTP Only requests based on the whitelist
> #acl allowed_http_only dstdomain .veevasourcedev.com <
> http://veevasourcedev.com>  .google.com <http://google.com>  .pypi.org <
> http://pypi.org>  .youtube.com <http://youtube.com>
> #acl allowed_http_only dstdomain .amazonaws.com <http://amazonaws.com>
> #acl allowed_http_only dstdomain .veevanetwork.com <
> http://veevanetwork.com>  .veevacrm.com <http://veevacrm.com>  .
> veevacrmdi.com <http://veevacrmdi.com>  .veeva.com <http://veeva.com>  .
> veevavault.com <http://veevavault.com>  .vaultdev.com <http://vaultdev.com>
> .veevacrmqa.com <http://veevacrmqa.com>
> #acl allowed_http_only dstdomain .documentforce.com <
> http://documentforce.com>   .sforce.com <http://sforce.com>  .force.com <
> http://force.com>  .forceusercontent.com <http://forceusercontent.com>  .
> force-user-content.com <http://force-user-content.com>  .lightning.com <
> http://lightning.com>  .salesforce.com <http://salesforce.com>  .
> salesforceliveagent.com <http://salesforceliveagent.com>  .
> salesforce-communities.com <http://salesforce-communities.com>  .
> salesforce-experience.com <http://salesforce-experience.com>  .
> salesforce-hub.com <http://salesforce-hub.com>  .salesforce-scrt.com <
> http://salesforce-scrt.com>  .salesforce-sites.com <
> http://salesforce-sites.com>  .site.com <http://site.com>  .sfdcopens.com
> <http://sfdcopens.com>  .sfdc.sh .trailblazer.me <http://trailblazer.me>
> .trailhead.com <http://trailhead.com>  .visualforce.com <
> http://visualforce.com>
>
>
> # Filter HTTPS requests based on the whitelist
> acl allowed_https_sites ssl::server_name .pypi.org <http://pypi.org>  .
> pythonhosted.org <http://pythonhosted.org>  .tfhub.dev <http://tfhub.dev>
> .gstatic.com <http://gstatic.com>  .googleapis.com <http://googleapis.com>
>
> acl allowed_https_sites ssl::server_name .amazonaws.com <
> http://amazonaws.com>
> acl allowed_https_sites ssl::server_name .documentforce.com <
> http://documentforce.com>   .sforce.com <http://sforce.com>  .force.com <
> http://force.com>  .forceusercontent.com <http://forceusercontent.com>  .
> force-user-content.com <http://force-user-content.com>  .lightning.com <
> http://lightning.com>  .salesforce.com <http://salesforce.com>  .
> salesforceliveagent.com <http://salesforceliveagent.com>  .
> salesforce-communities.com <http://salesforce-communities.com>  .
> salesforce-experience.com <http://salesforce-experience.com>  .
> salesforce-hub.com <http://salesforce-hub.com>  .salesforce-scrt.com <
> http://salesforce-scrt.com>  .salesforce-sites.com <
> http://salesforce-sites.com>  .site.com <http://site.com>  .sfdcopens.com
> <http://sfdcopens.com>  .sfdc.sh .trailblazer.me <http://trailblazer.me>
> .trailhead.com <http://trailhead.com>  .visualforce.com <
> http://visualforce.com>
> ssl_bump peek step2 allowed_https_sites
> ssl_bump splice step3 allowed_https_sites
> ssl_bump terminate step2 all
>
>
> connect_timeout 60 minute
> read_timeout 60 minute
> write_timeout 60 minute
> request_timeout 60 minute
>
> ## http filtering ###
> #http_access allow localnet allowed_http_only
> #http_access allow localhost allowed_http_only
> http_access allow localnet allowed_https_sites
> http_access allow localho

Re: [squid-users] slow down response to broken clients ?

[Amos Jeffries]

On 25/02/22 20:47, Dieter Bloms wrote:

Hello,

Sometimes a client tries to reach a destination that is blocked at the
proxy. The proxy responds with a 403 and the client then immediately
tries again and again, making hundreds of requests per second. Is it
possible to add an artificial delay here so that the proxy answers
the client later?
Best combined with a rate limit, so that the delays only become active
when a certain limit of 403 answers is exceeded?




Squid ships with a helper called ext_delayer_acl for handling this.


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

Re: [squid-users] Random trouble with image downloads

[Amos Jeffries]

On 25/02/22 18:14, Dave Blanchard wrote:

OK, I've got Squid mostly working fine, but have noticed a problem with certain image 
downloads, which in at least one case are coming from storage.googleapis.com. (Profile 
images for a forum.) It's as if Squid sometimes randomly fails to download and correctly 
cache a given image, and instead caches a broken or zero'd file. If I try to open that 
image in a new browser tab, sometimes it will just be blank, and other times the browser 
reports ERR_EMPTY_RESPONSE "The server didn't send any data." In the former 
case the image access shows up in the Squid access log as TCP_REFRESH_UNMODIFIED, and in 
the latter case it doesn't show up at all. If I download it manually using wget with no 
proxy, it downloads fine. What could possibly be happening here?




I suspect you are seeing 

Unfortunately we do not have a good fix for it yet.

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

Re: [squid-users] Trying to set up SSL cache - solved!

[Amos Jeffries]

On 25/02/22 10:49, Dave Blanchard wrote:

On Thu, 24 Feb 2022 15:07:53 -0500
Alex Rousskov wrote:


What is the replacement for client-first?


A "good" answer depends on what exactly you are trying to achieve;
details matter. A "dumb" answer (i.e. a direct replacement without
considering your true needs and Squid bugs) is:

ssl_bump bump all


That's what I had tried first, and was banging my head on the wall for hours trying to 
get it to work right--though the "ssl_bump peek" was in there also, on the 
suggestion of various tutorials. Now I just tried it again, with only that line...and it 
works perfectly! No problem. SMH...

This tutorial situation is really out of control. Sadly, this is what can be 
expected to happen when the syntax is changed with every version. Now we're in 
a real mess. I hope the Squid developers will make up their minds on how they 
want the syntax to be structured, build it that way, then LEAVE IT ALONE!



Agreed. Luckily we hear you (Alex and I are pretty much "them" these days).

If it helps. The config for this stabilized in Squid-3.5.





I prefer to handle the certificate validation externally


It is a common need. Squid supports external certificate validator
programs (a.k.a. helpers). Look for sslcrtvalidator_program in
squid.conf.documented.


Or at 



For communication details, see the following

wikip age and src/security/cert_validators/fake/

https://wiki.squid-cache.org/Features/AddonHelpers


Awesome! That's very useful.

Thanks a lot for your help!



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

Re: [squid-users] Trying to set up SSL cache - solved!

[Amos Jeffries]

On 25/02/22 05:41, Grant Taylor wrote:

On 2/24/22 9:08 AM, Alex Rousskov wrote:

"more examples" is hardly the answer.


I believe that "more examples" can be additional data that someone can 
derive information ~> knowledge from.


Or said another way, it's a step in the proper direction.



At this point I should remind that it is a *wiki* and largely written by 
all of us in the community.


The ConfigExamples section a collection of configs that people here in 
the community are (or were) actively using and found useful to share.
We (the main devs) have made a point of trying to update the contents to 
prune mistakes and mention when there are Squid version-specific 
differences. That is all.


That said, Francesco is working on converting the wiki content to 
another format so right now is not good for edits.



I think one of the most important things to have with examples is meta 
information about the configuration (both server and client side) that 
it is being used and the version.


E.g. Clients are configured to talk directly to Squid (vX.Y) proxy 
server on port 80 / 443 wherein SSL "bumping" a la. monkey in the middle 
for caching purposes on a low bandwidth / metered connection.




Sounds like you are talking about 
. From that page it is a 
matter of selecting which situation is the use-case and diving into the 
rabbit hole of links.



/Just/ having configuration examples doesn't do much in and of itself 
without knowing the context the examples are from.  If anything /just/ 
examples is worse in that people have no context and are left with 
trying to identify the version, what was being and intended to be done, 
and then translating that to the version & configuration they are 
working with.  This is something that's non-trivial for seasoned (Squid) 
administrators and can be near impossible to new (Squid) administrators.




Nod.

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

Re: [squid-users] Squid Question regarding tcp handshake

[Amos Jeffries]

On 25/02/22 04:03, Felipe Polanco wrote:

Hi,

A question Regarding TCP handshake.

Does squid first complete the tcp handshake on its users and then a 
second handshake on the destination IP or as soon as it receives the TCP 
SYN flag it does the same with the destination.




The TCP connections handshakes are (almost) completely independent. One 
client connection may result in  multiple (or 0) server connections - 
depending on what needs to be done.



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

Re: [squid-users] Trying to set up SSL cache

[Amos Jeffries]

On 24/02/22 15:26, Dave Blanchard wrote:

Hello, I'm trying to configure Squid as a HTTPS cache on my local computer, 
using ssl-bump. I've got it working as a basic proxy, but the traffic seems to 
just be tunneling through and not being cached.


Do you actually get at least *2* (maybe 3) Squid access.log entries per 
client connection demonstrating that?




My web browser shows the site's actual certificate, rather than the locally 
generated self-signed certificate, which I want it to see. I have followed 
every tutorial I can find and none of them are helpful in figuring out what the 
hell is going on here. Here is what my config file looks like:

[...]

http_port 3128 ssl-bump \
generate-host-certificates=on \
dynamic_cert_mem_cache_size=32MB \
cert=/path/to/self-signed.pem \
key=/path/to/self-signed.pem

sslcrtd_program /usr/libexec/security_file_certgen -s /path/to/ssl-database -M 
32MB

ssl_bump peek all


Okay TLS handshake clientHello gets observed by Squid.

At this point you should see 2 CONNECT requests in access.log, first 
(step1) with raw-IP and second (step2) with the TLS SNI from this 
clientHello (if any, otherwise raw-IP again).




ssl_bump bump all


... now (step3) everything gets decrypted.

At this point you should start seeing access.log entries with https:// 
URLs and the actual server name per the serverHello certificate.




ssl_bump splice localhost



The connection is already bump'ed. This rule can never be reached.



[...]

Otherwise, it's pretty much just the default config. The only thing that seems 
to halfway work is removing the line:

http_access deny CONNECT !SSL_ports

and changing to:

http_access deny CONNECT



This actively rejects *all* CONNECT messages. Including the one Squid 
uses internally for SSL-Bump step1.




With that change, an older Chromium just hangs trying to load the page, saying 
"Processing request." On a WebKit-based browser, I get a Squid 'Access Denied' 
error page.


As expected with a "deny CONNECT" rule on a CONNECT request.

This is actually the best outcome right now. It means the SSL-Bump 
crypto part is working fine for at least this second client.


What you need to do next is figure out which of your other rules is 
causing things to go wrong when the HTTP message inside the TLS is received.


For example; whether it is actually *HTTP/1* messages arriving. Other 
things will revert back to tunneling (see 
)




Another WebKit browser complains about the certificate, but when I tell it to 
continue anyway, it gives the same 'Access Denied' page.
A newer Chromium stops right away with an untrusted SSL certificate error, and 
the details look like it's getting the self-signed certificate, as expected.



These clients do not trust the CA Squid is using as signing cert. That 
will need to be fixed to avoid the cert complaint, but does not 
otherwise make any difference to the main issue.



You could use these browsers to test if you don't mind the popup. But I 
recommend the one which already trusts Squids signing CA until you have 
the rest of the basics working.




There are a few things to be aware of while troubleshooting:

* not all TLS connections can be bump'ed. TLS is designed to prevent 
exactly the type of decrypt that bump does. If the client and server are 
using TLS properly bump *will* fail.



* Google are known to be rather pedantic about security. So having their 
software at either end of the TLS when testing is more likely to hit 
such non-decryptable TLS connections.



* Checking the test web service for TLS certificate pinning or DANE. 
Both of these lock the/some client into using the original server 
certificate and they will unavoidably reject the Squid signing CA.


* Check traffic from the web server for HTTPS-Transport-Security or 
Alt-Svc HTTP headers. Both of these can break SSL-Bump if they reach a 
client. What is worse they can force arbitrarily long cache times for 
the info they contain, causing breakage to extend across the whole 
period. Only a full client purge of state and never receiving the info 
again can via any protocol fix these.



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

Re: [squid-users] getsockopt failures, although direct access to intercept ports is blocked

[Amos Jeffries]

On 24/02/22 12:05, Andreas Weigel wrote:

Hi everyone,

I had the following issue with Squid in Transparent Mode (and SSL 
Interception in mode splice). It is working as expected, however after 
multiple long-running (talking about several seconds) anti-virus 
ecap-Processes have finished, I *sometimes* get the following in the log:


2022/02/23 14:56:40.668 kid1| 5,2| src/comm/TcpAcceptor.cc(224) 
doAccept: New connection on FD 21
2022/02/23 14:56:40.668 kid1| 5,2| src/comm/TcpAcceptor.cc(312) 
acceptNext: connection on local=[::]:2412 remote=[::] FD 21 flags=41
2022/02/23 14:56:40.668 kid1| 89,5| src/ip/Intercept.cc(405) Lookup: 
address BEGIN: me/client= 192.168.180.1:2412, destination/me= 
192.168.180.10:48582
2022/02/23 14:56:40.668 kid1| ERROR: NF getsockopt(ORIGINAL_DST) failed 
on local=192.168.180.1:2412 remote=192.168.180.10:48582 FD 37 flags=33: 
(2) No such file or directory
2022/02/23 14:56:40.669 kid1| 89,9| src/ip/Intercept.cc(151) 
NetfilterInterception: address: local=192.168.180.1:2412 
remote=192.168.180.10:48582 FD 37 flags=33
2022/02/23 14:56:40.669 kid1| ERROR: NAT/TPROXY lookup failed to locate 
original IPs on local=192.168.180.1:2412 remote=192.168.180.10:48582 FD 
37 flags=33



These can happen if the NAT table entries expire or otherwise get 
dropped by conntrack between the client initiating TCP SYN and Squid 
accept(2) receiving the connection.


Your config looks good to me and the lack of regularity indicates the 
issue is likely this type of transient state situation.
 Is this happening at times of unusually high client connections 
through the NAT?

 Is eCAP processing blocking the Squid worker for all those seconds?


2022/02/23 14:56:40.669 kid1| 5,5| src/comm/TcpAcceptor.cc(287) 
acceptOne: non-recoverable error: FD 21, [::] [ job2] handler 
Subscription: 0x55edac3d08d0*1


Sometimes, this only appears on on of the two interception ports, 
sometimes on both. After that, the squid worker does not poll the 
intercept listen port any longer, i.e. stops working.


That part is likely to be the issue recently worked around by 




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