Re: [squid-users] Mutual TLS for the upstream example

[Eliezer Croitoru]

Can we try to understand the issue again?

 

In this setup, should squid know about the client certificate and pass it to 
the service  backend 

Or maybe just terminate the clients certificate?

 

I am not sure I understood what you need/want to do with squid.

 

Eliezer

 



Eliezer Croitoru

Tech Support

Mobile: +972-5-28704261

Email: ngtech1...@gmail.com  

Zoom: Coming soon

 

 

From: Sergey Maslyakov  
Sent: Friday, January 15, 2021 1:38 AM
To: Eliezer Croitoru 
Cc: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] Mutual TLS for the upstream example

 

Thank you, Eliezer! I will look into it but it appears that the underlying 
problem is not solvable by design of the mTLS handshake... There are corner 
cases that can be solved but not the original issue.

 

 

On Thu, Jan 14, 2021 at 2:39 PM Eliezer Croitoru mailto:ngtech1...@gmail.com> > wrote:

I don’t know about Squid but I assume varnish has this feature:

https://docs.varnish-software.com/varnish-cache-plus/features/backend-ssl/

 

If you just need a GW without caching it should work as expected.

 

Eliezer

 



Eliezer Croitoru

Tech Support

Mobile: +972-5-28704261

Email: ngtech1...@gmail.com  

Zoom: Coming soon

 

 

From: squid-users mailto:squid-users-boun...@lists.squid-cache.org> > On Behalf Of Sergey 
Maslyakov
Sent: Thursday, January 14, 2021 9:41 PM
To: squid-users@lists.squid-cache.org 
 
Subject: [squid-users] Mutual TLS for the upstream example

 

Folks,

 

Is the CONNECT tunnel designed in a way that enables it to "enrich" the 
outgoing connection with mTLS authentication? "tls_outgoing_options" does not 
seem to work the way I was hoping it does.

 

My destination server requires mTLS authentication of the client. I have a 
valid key-cert pair and I can successfully execute a "curl" command to fetch a 
document from that server using the key-cert pair at hand.

 

I want to put Squid between my clients (Maven, Gradle, Docker Engine, etc) and 
the server so that clients would be configured to use the instance of Squid as 
an HTTPS proxy but would not have to be configured with the mTLS key-cert pair.

 

Here is how I see it:

 

Maven --- (HTTPS/CONNECT) ---> Squid (stores my mTLS key-cert pair) --- 
(mTLS/SSL) ---> Server

 

Is this doable within Squid architecture?

 

I got it working using NGINX with some minor hiccups and I was hoping I can do 
it more elegantly with Squid.

 

 

Thank you,

/Sergey

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

Re: [squid-users] Mutual TLS for the upstream example

[Sergey Maslyakov]

Thank you, Eliezer! I will look into it but it appears that the underlying
problem is not solvable by design of the mTLS handshake... There are corner
cases that can be solved but not the original issue.


On Thu, Jan 14, 2021 at 2:39 PM Eliezer Croitoru 
wrote:

> I don’t know about Squid but I assume varnish has this feature:
>
> https://docs.varnish-software.com/varnish-cache-plus/features/backend-ssl/
>
>
>
> If you just need a GW without caching it should work as expected.
>
>
>
> Eliezer
>
>
>
> 
>
> Eliezer Croitoru
>
> Tech Support
>
> Mobile: +972-5-28704261
>
> Email: ngtech1...@gmail.com
>
> Zoom: Coming soon
>
>
>
>
>
> *From:* squid-users  *On
> Behalf Of *Sergey Maslyakov
> *Sent:* Thursday, January 14, 2021 9:41 PM
> *To:* squid-users@lists.squid-cache.org
> *Subject:* [squid-users] Mutual TLS for the upstream example
>
>
>
> Folks,
>
>
>
> Is the CONNECT tunnel designed in a way that enables it to "enrich" the
> outgoing connection with mTLS authentication? "tls_outgoing_options" does
> not seem to work the way I was hoping it does.
>
>
>
> My destination server requires mTLS authentication of the client. I have a
> valid key-cert pair and I can successfully execute a "curl" command to
> fetch a document from that server using the key-cert pair at hand.
>
>
>
> I want to put Squid between my clients (Maven, Gradle, Docker Engine, etc)
> and the server so that clients would be configured to use the instance of
> Squid as an HTTPS proxy but would not have to be configured with the mTLS
> key-cert pair.
>
>
>
> Here is how I see it:
>
>
>
> Maven --- (HTTPS/CONNECT) ---> Squid (stores my mTLS key-cert pair) ---
> (mTLS/SSL) ---> Server
>
>
>
> Is this doable within Squid architecture?
>
>
>
> I got it working using NGINX with some minor hiccups and I was hoping I
> can do it more elegantly with Squid.
>
>
>
>
>
> Thank you,
>
> /Sergey
>
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Mutual TLS for the upstream example

[Sergey Maslyakov]

Thank you for the very detailed explanation, Alex!

Having looked at the sequence diagram of the mTLS handshake, I now see why
I cannot get what I want.

I can either get plain-text HTTP to mTLS-secured forwarding, or I have to
have two independent legs of communication when the authenticity of
client-to-Squid connection is ensured using its (Squid's) own key-cert
pair, which is different from authentication credentials of the handshake
between Squid and my target server.

I cannot afford to have unencrypted the client-to-Squid leg, otherwise, I
could do it in a single "socat" invocation.

I don't have the server key-cert pair, which makes the sslbump impractical
too.

In NGINX, I implemented the reverse proxy model (option 2 on your list),
when the proxy terminated SSL with its own cert, received the request,
rewrote some headers, and forwarded it over an mTLS-secured connection. The
problem is that under some circumstances I also need to rewrite the body of
the HTTP request and this was taking the whole solution to a whole new
level of complexity...

I guess I need to start looking into automation that would allow me to
manage mTLS configuration of clients at scale instead of trying to defeat
the whole purpose of the mTLS integrity mechanism :)

On Thu, Jan 14, 2021 at 2:42 PM Alex Rousskov <
rouss...@measurement-factory.com> wrote:

> On 1/14/21 2:41 PM, Sergey Maslyakov wrote:
>
> > Is the CONNECT tunnel designed in a way that enables it to "enrich" the
> > outgoing connection with mTLS authentication?
>
> If, by "designed", you are asking about HTTP protocol design, then the
> CONNECT tunnel is a blind TCP tunnel by that design. Hence, by design, a
> proxy dealing with CONNECT tunnels does not assume they are related to TLS.
>
> Squid SslBump feature allows the admin to disregard the general design
> principles above and interpret the CONNECT tunnel bytes as TLS. Usually,
> when folks ask about "enriching" TLS, they talk about SslBump. It is not
> yet clear to me whether you need SslBump.
>
> Neither Squid nor any other proxy can enrich a client TLS connection.
> TLS is designed to protect from such fiddling by proxies. I suspect that
> what you need is for Squid to use mTLS when forwarding a client request
> to the origin server. This is supported in principle, but the devil is
> in the details.
>
>
> > My destination server requires mTLS authentication of the client. I have
> > a valid key-cert pair and I can successfully execute a "curl" command to
> > fetch a document from that server using the key-cert pair at hand.
>
> Squid supports mTLS authentication with HTTPS cache_peers (including
> origin servers) via the cache_peers sslcert option.
>
>
> > I want to put Squid between my clients (Maven, Gradle, Docker Engine,
> > etc) and the server so that clients would be configured to use the
> > instance of Squid as an HTTPS proxy but would not have to be configured
> > with the mTLS key-cert pair.
>
> 1. "HTTPS proxy" is a proxy that accepts TLS connections opened by
> clients that want to explicitly ask that proxy to forward their request
> to some origin server. I suspect that is not what you meant by "HTTPS
> proxy". Whether there are CONNECT requests in this case depends on the
> client, but all popular clients I know about do send CONNECT requests
> inside that secure TLS connection to the proxy (unfortunately). For
> those clients, SslBump is required.
>
> 2. It is possible that you are talking about an HTTPS surrogate or HTTPS
> reverse proxy/accelerator. In this configuration, clients talk to Squid
> thinking that Squid is an HTTPS origin server. There are no CONNECT
> requests in this case. Clients receive Squid certificates. No SslBump.
>
> 3. If you meant that Squid should intercept/hijack client TCP
> connections to HTTPS origin servers, then it is a third kind of
> configuration. There are no CONNECT requests in this case. Clients
> receive Squid certificates. SslBump is required.
>
> 4. If you meant that Squid, as a regular HTTP forward proxy, should
> hijack client CONNECT tunnels to HTTPS origin servers, then it is a yet
> another kind of configuration. There are CONNECT requests in this case.
> Clients receive Squid certificates. SslBump is required.
>
> Each scenario above would present its own Squid challenges. Please
> clarify what you are dealing with.
>
>
> > Here is how I see it:
>
> > Maven --- (HTTPS/CONNECT) ---> Squid (stores my mTLS key-cert pair) ---
> > (mTLS/SSL) ---> Server
>
> > Is this doable within Squid architecture?
>  The "HTTPS/CONNECT" part can be misinterpreted as any of the four cases
> above. Please clarify what it means to you. If this is all too
> overwhelming, we can start with a simple question: Do your clients
> establish TCP connections to a Squid port (cases 1, 2, 4)? Or do they
> open TCP connections to origin servers instead (case 3)?
>
>
> Cheers,
>
> Alex.
>
___
squid-users mailing list

Re: [squid-users] Mutual TLS for the upstream example

[Alex Rousskov]

On 1/14/21 2:41 PM, Sergey Maslyakov wrote:

> Is the CONNECT tunnel designed in a way that enables it to "enrich" the
> outgoing connection with mTLS authentication?

If, by "designed", you are asking about HTTP protocol design, then the
CONNECT tunnel is a blind TCP tunnel by that design. Hence, by design, a
proxy dealing with CONNECT tunnels does not assume they are related to TLS.

Squid SslBump feature allows the admin to disregard the general design
principles above and interpret the CONNECT tunnel bytes as TLS. Usually,
when folks ask about "enriching" TLS, they talk about SslBump. It is not
yet clear to me whether you need SslBump.

Neither Squid nor any other proxy can enrich a client TLS connection.
TLS is designed to protect from such fiddling by proxies. I suspect that
what you need is for Squid to use mTLS when forwarding a client request
to the origin server. This is supported in principle, but the devil is
in the details.


> My destination server requires mTLS authentication of the client. I have
> a valid key-cert pair and I can successfully execute a "curl" command to
> fetch a document from that server using the key-cert pair at hand.

Squid supports mTLS authentication with HTTPS cache_peers (including
origin servers) via the cache_peers sslcert option.


> I want to put Squid between my clients (Maven, Gradle, Docker Engine,
> etc) and the server so that clients would be configured to use the
> instance of Squid as an HTTPS proxy but would not have to be configured
> with the mTLS key-cert pair.

1. "HTTPS proxy" is a proxy that accepts TLS connections opened by
clients that want to explicitly ask that proxy to forward their request
to some origin server. I suspect that is not what you meant by "HTTPS
proxy". Whether there are CONNECT requests in this case depends on the
client, but all popular clients I know about do send CONNECT requests
inside that secure TLS connection to the proxy (unfortunately). For
those clients, SslBump is required.

2. It is possible that you are talking about an HTTPS surrogate or HTTPS
reverse proxy/accelerator. In this configuration, clients talk to Squid
thinking that Squid is an HTTPS origin server. There are no CONNECT
requests in this case. Clients receive Squid certificates. No SslBump.

3. If you meant that Squid should intercept/hijack client TCP
connections to HTTPS origin servers, then it is a third kind of
configuration. There are no CONNECT requests in this case. Clients
receive Squid certificates. SslBump is required.

4. If you meant that Squid, as a regular HTTP forward proxy, should
hijack client CONNECT tunnels to HTTPS origin servers, then it is a yet
another kind of configuration. There are CONNECT requests in this case.
Clients receive Squid certificates. SslBump is required.

Each scenario above would present its own Squid challenges. Please
clarify what you are dealing with.


> Here is how I see it:

> Maven --- (HTTPS/CONNECT) ---> Squid (stores my mTLS key-cert pair) ---
> (mTLS/SSL) ---> Server

> Is this doable within Squid architecture?
 The "HTTPS/CONNECT" part can be misinterpreted as any of the four cases
above. Please clarify what it means to you. If this is all too
overwhelming, we can start with a simple question: Do your clients
establish TCP connections to a Squid port (cases 1, 2, 4)? Or do they
open TCP connections to origin servers instead (case 3)?


Cheers,

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

Re: [squid-users] Mutual TLS for the upstream example

[Eliezer Croitoru]

I don’t know about Squid but I assume varnish has this feature:

https://docs.varnish-software.com/varnish-cache-plus/features/backend-ssl/

 

If you just need a GW without caching it should work as expected.

 

Eliezer

 



Eliezer Croitoru

Tech Support

Mobile: +972-5-28704261

Email:   ngtech1...@gmail.com

Zoom: Coming soon

 

 

From: squid-users  On Behalf Of 
Sergey Maslyakov
Sent: Thursday, January 14, 2021 9:41 PM
To: squid-users@lists.squid-cache.org
Subject: [squid-users] Mutual TLS for the upstream example

 

Folks,

 

Is the CONNECT tunnel designed in a way that enables it to "enrich" the 
outgoing connection with mTLS authentication? "tls_outgoing_options" does not 
seem to work the way I was hoping it does.

 

My destination server requires mTLS authentication of the client. I have a 
valid key-cert pair and I can successfully execute a "curl" command to fetch a 
document from that server using the key-cert pair at hand.

 

I want to put Squid between my clients (Maven, Gradle, Docker Engine, etc) and 
the server so that clients would be configured to use the instance of Squid as 
an HTTPS proxy but would not have to be configured with the mTLS key-cert pair.

 

Here is how I see it:

 

Maven --- (HTTPS/CONNECT) ---> Squid (stores my mTLS key-cert pair) --- 
(mTLS/SSL) ---> Server

 

Is this doable within Squid architecture?

 

I got it working using NGINX with some minor hiccups and I was hoping I can do 
it more elegantly with Squid.

 

 

Thank you,

/Sergey

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

[squid-users] Mutual TLS for the upstream example

[Sergey Maslyakov]

Folks,

Is the CONNECT tunnel designed in a way that enables it to "enrich" the
outgoing connection with mTLS authentication? "tls_outgoing_options" does
not seem to work the way I was hoping it does.

My destination server requires mTLS authentication of the client. I have a
valid key-cert pair and I can successfully execute a "curl" command to
fetch a document from that server using the key-cert pair at hand.

I want to put Squid between my clients (Maven, Gradle, Docker Engine, etc)
and the server so that clients would be configured to use the instance of
Squid as an HTTPS proxy but would not have to be configured with the mTLS
key-cert pair.

Here is how I see it:

Maven --- (HTTPS/CONNECT) ---> Squid (stores my mTLS key-cert pair) ---
(mTLS/SSL) ---> Server

Is this doable within Squid architecture?

I got it working using NGINX with some minor hiccups and I was hoping I can
do it more elegantly with Squid.


Thank you,
/Sergey
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Incomplete Certificate Chain for wiki.squid-cache.org

[Dieter Bloms]

Hello Amos,

On Thu, Jan 14, Amos Jeffries wrote:

> On 13/01/21 11:27 pm, Dieter Bloms wrote:
> > Hello,
> > 
> > the wiki of squid cache project (wiki.squid-cache.org) has an incomplete
> > certificate chain.
> > I can't access the website with enabled sslbump and tlsv1.3 support,
> > because squid isn't able to download the missing intermediate
> > certificate on its own.
> 
> What version of Squid are you using?

we use squid 4.13 and it works for tls version <1.3
 
> These certificates generated by LetsEncrypt use the AIA mechanism which
> latest Squid versions should be downloading intermediate certs as-needed.

but for tls1.3 it doesn't work, because the certificate is encrypted.
Please have a look at the bugreport 
https://bugs.squid-cache.org/show_bug.cgi?id=5067


-- 
Gruß

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
From field.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] generate-host-certificates=on fails to generate certificates for _some_ hosts

[Alex Rousskov]

On 1/14/21 1:22 AM, Greg Hulands wrote:

> Can you point me to the rough location in code where the certs are sent to 
> the client.

I would start with the following log line:

> 2021/01/13 18:09:11.655 kid1| 33,5| client_side.cc(2700) sslCrtdHandleReply: 
> Certificate for arstechnica.com was successfully recieved from ssl_crtd

You can see the exact code location of each low-level debug statement.
Unfortunately, Squid uses a somewhat unusual filename(linenumber)
notation for that, but the information is there -- client_side.cc line
2700. After the source code location, Squid prints the function name
where the message was generated -- sslCrtdHandleReply.

The above line points to a method that receives the (parsed) certificate
from the code that talks to the helper. IIRC, Squid then calls
Ssl::configureSSLUsingPkeyAndCertFromMemory() to apply the certificate
to the client-Squid TLS connection. It would be good to confirm that the
certificate Squid applies is the right one and that all the application
functions were successful (e.g., Squid may forget to check some OpenSSL
function result). This will require some development skills.


> I tried with TLS 1.2 with openssl s_client and it returned the certs the same.

Noted. You may prefer to test with TLS v1.2 (first) because it may
produce simpler debugging logs and create fewer uncertainties. The code
mentioned above is used for all TLS versions.


Good luck,

Alex.


>> On Jan 13, 2021, at 8:44 PM, Alex Rousskov 
>>  wrote:
>>
>> On 1/13/21 9:47 PM, Greg Hulands wrote:
>>> I have put the ALL,9 log
>>> here https://gist.github.com/ghulands/4a689db93fc87f9e7f69174f292f1914
>>
>>> I can see it generates the certificate correctly,
>>
>> Agreed. Squid receives (from the helper) a generated certificate with
>> the right wildcard CN, not a CA certificate.
>>
>>
>>> but couldn’t identify why it didn’t return the cert to the client.
>>
>> Yeah... Squid is calling the code that should set the certificate for
>> the client connection. Unfortunately, I cannot easily tell whether that
>> code is using the right certificate -- the existing debugging may not
>> even reveal that detail.
>>
>> If you see a different certificate received by the client -- something I
>> cannot verify from the logs -- then perhaps Squid incorrectly switched
>> the right certificate to a different one or Squid failed to set the
>> right certificate but forgot to report the problem (and the CA
>> certificate from the related context was used?). These are just wild
>> guesses.
>>
>> If you do not get better suggestions for going forward, consider these
>> last-straw ideas:
>>
>> * Testing with a client like openssl, try disabling TLS v1.3. It is
>> being used by the client in your logs. Perhaps there is something in TLS
>> v1.3 that requires special handing when talking to the client. I know
>> that Squid has problems with TLS v1.3 on the Squid-to-server
>> connections... (In your case, the Squid-to-server connection is TLS v1.2
>> AFAICT).
>>
>> * Upgrade to the latest v5 or even v6. I see no relevant fixes in v5 but
>> I could miss them.
>>
>> * If you are a developer, add more debugging or use gdb to find out what
>> happens with the Squid-to-client certificate. Otherwise, find a
>> developer who can do that for you.
>>
>> Sorry I cannot think of any good options here.
>>
>> Alex.

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

Re: [squid-users] generate-host-certificates=on fails to generate certificates for _some_ hosts

[Eliezer Croitoru]

Hey Greg,

I am trying to test it with 5.0.4 and it seems that this site works for me with 
SSL BUMP.
The CN and the SAN are the same so it makes sense that it should work the same 
on your proxy.
However I do see that this domain has 2 IP addresses which might affect what 
you see.
I am trying to verify this issue locally.

I wrote the next ruby script to help others with some insights.
https://github.com/elico/tls-check-script

Both ip addresses seem to give the same certificate.
I am using openssl to see the certificate:
openssl s_client -showcerts -servername arstechnica.com -connect 
arstechnica.com:443 /dev/null | openssl x509 -noout -text

Let me know if something specific is seen in your environment.

It shouldn't matter too much but, what OS are you running squid ontop and what 
is "squid -v" output?

Thanks,
Eliezer


Eliezer Croitoru
Tech Support
Mobile: +972-5-28704261
Email: ngtech1...@gmail.com
Zoom: Coming soon


-Original Message-
From: squid-users  On Behalf Of Greg 
Hulands
Sent: Thursday, January 14, 2021 8:22 AM
To: Alex Rousskov 
Cc: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] generate-host-certificates=on fails to generate 
certificates for _some_ hosts

Hey Alex,
Can you point me to the rough location in code where the certs are sent to the 
client.

I tried with TLS 1.2 with openssl s_client and it returned the certs the same.

Thanks,
Greg

> On Jan 13, 2021, at 8:44 PM, Alex Rousskov  
> wrote:
> 
> On 1/13/21 9:47 PM, Greg Hulands wrote:
>> I have put the ALL,9 log
>> here https://gist.github.com/ghulands/4a689db93fc87f9e7f69174f292f1914
> 
>> I can see it generates the certificate correctly,
> 
> Agreed. Squid receives (from the helper) a generated certificate with
> the right wildcard CN, not a CA certificate.
> 
> 
>> but couldn’t identify why it didn’t return the cert to the client.
> 
> Yeah... Squid is calling the code that should set the certificate for
> the client connection. Unfortunately, I cannot easily tell whether that
> code is using the right certificate -- the existing debugging may not
> even reveal that detail.
> 
> If you see a different certificate received by the client -- something I
> cannot verify from the logs -- then perhaps Squid incorrectly switched
> the right certificate to a different one or Squid failed to set the
> right certificate but forgot to report the problem (and the CA
> certificate from the related context was used?). These are just wild
> guesses.
> 
> If you do not get better suggestions for going forward, consider these
> last-straw ideas:
> 
> * Testing with a client like openssl, try disabling TLS v1.3. It is
> being used by the client in your logs. Perhaps there is something in TLS
> v1.3 that requires special handing when talking to the client. I know
> that Squid has problems with TLS v1.3 on the Squid-to-server
> connections... (In your case, the Squid-to-server connection is TLS v1.2
> AFAICT).
> 
> * Upgrade to the latest v5 or even v6. I see no relevant fixes in v5 but
> I could miss them.
> 
> * If you are a developer, add more debugging or use gdb to find out what
> happens with the Squid-to-client certificate. Otherwise, find a
> developer who can do that for you.
> 
> Sorry I cannot think of any good options here.
> 
> Alex.

___
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] generate-host-certificates=on fails to generate certificates for _some_ hosts

[Greg Hulands]

Hey Alex,
Can you point me to the rough location in code where the certs are sent to the 
client.

I tried with TLS 1.2 with openssl s_client and it returned the certs the same.

Thanks,
Greg

> On Jan 13, 2021, at 8:44 PM, Alex Rousskov  
> wrote:
> 
> On 1/13/21 9:47 PM, Greg Hulands wrote:
>> I have put the ALL,9 log
>> here https://gist.github.com/ghulands/4a689db93fc87f9e7f69174f292f1914
> 
>> I can see it generates the certificate correctly,
> 
> Agreed. Squid receives (from the helper) a generated certificate with
> the right wildcard CN, not a CA certificate.
> 
> 
>> but couldn’t identify why it didn’t return the cert to the client.
> 
> Yeah... Squid is calling the code that should set the certificate for
> the client connection. Unfortunately, I cannot easily tell whether that
> code is using the right certificate -- the existing debugging may not
> even reveal that detail.
> 
> If you see a different certificate received by the client -- something I
> cannot verify from the logs -- then perhaps Squid incorrectly switched
> the right certificate to a different one or Squid failed to set the
> right certificate but forgot to report the problem (and the CA
> certificate from the related context was used?). These are just wild
> guesses.
> 
> If you do not get better suggestions for going forward, consider these
> last-straw ideas:
> 
> * Testing with a client like openssl, try disabling TLS v1.3. It is
> being used by the client in your logs. Perhaps there is something in TLS
> v1.3 that requires special handing when talking to the client. I know
> that Squid has problems with TLS v1.3 on the Squid-to-server
> connections... (In your case, the Squid-to-server connection is TLS v1.2
> AFAICT).
> 
> * Upgrade to the latest v5 or even v6. I see no relevant fixes in v5 but
> I could miss them.
> 
> * If you are a developer, add more debugging or use gdb to find out what
> happens with the Squid-to-client certificate. Otherwise, find a
> developer who can do that for you.
> 
> Sorry I cannot think of any good options here.
> 
> Alex.

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

Re: [squid-users] Incomplete Certificate Chain for wiki.squid-cache.org

[Matus UHLAR - fantomas]

On 13/01/21 11:27 pm, Dieter Bloms wrote:

the wiki of squid cache project (wiki.squid-cache.org) has an incomplete
certificate chain.
I can't access the website with enabled sslbump and tlsv1.3 support,
because squid isn't able to download the missing intermediate
certificate on its own.


On 14.01.21 17:41, Amos Jeffries wrote:
These certificates generated by LetsEncrypt use the AIA mechanism 
which latest Squid versions should be downloading intermediate certs 
as-needed.


invalid intermediate certifiate is provided:


0 s:CN = master.squid-cache.org
  i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
  i:O = Digital Signature Trust Co., CN = DST Root CA X3



--
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.
- Holmes, what kind of school did you study to be a detective?
- Elementary, Watkins.  -- Daffy Duck & Porky Pig
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] WARNING: no_suid: setuid(0): (1) Operation not permitted

[David Touzeau]

Yes it seems the same bug but the ticket is not relevant (FreeBSD) as 
i'm on Debian and on a modern kernel


The main incomprehensible behavior that is issue occurs sometimes as 
setuid is a sticky bit permission..


squid -v output:

Squid Cache: Version 4.13
Service Name: squid

This binary uses OpenSSL 1.1.1d  10 Sep 2019. For legal restrictions on 
distribution see https://www.openssl.org/source/license.html


configure options:  '--prefix=/usr' '--build=x86_64-linux-gnu' 
'--includedir=/include' '--mandir=/share/man' '--infodir=/share/info' 
'--localstatedir=/var' '--libexecdir=/lib/squid3' 
'--disable-maintainer-mode' '--disable-dependency-tracking' 
'--datadir=/usr/share/squid3' '--sysconfdir=/etc/squid3' 
'--enable-gnuregex' '--enable-removal-policy=heap' 
'--enable-follow-x-forwarded-for' '--enable-removal-policies=lru,heap' 
'--enable-arp-acl' '--enable-truncate' '--with-large-files' 
'--with-pthreads' '--enable-esi' '--enable-storeio=aufs,diskd,ufs,rock' 
'--enable-x-accelerator-vary' '--with-dl' '--enable-linux-netfilter' 
'--with-netfilter-conntrack' '--enable-wccpv2' '--enable-eui' 
'--enable-auth' '--enable-auth-basic' '--enable-snmp' '--enable-icmp' 
'--enable-auth-digest' '--enable-log-daemon-helpers' 
'--enable-url-rewrite-helpers' '--enable-auth-ntlm' 
'--with-default-user=squid' '--enable-icap-client' 
'--disable-cache-digests' '--enable-poll' '--enable-epoll' 
'--enable-async-io=128' '--enable-zph-qos' '--enable-delay-pools' 
'--enable-http-violations' '--enable-url-maps' '--enable-ecap' 
'--enable-ssl' '--with-openssl' '--enable-ssl-crtd' 
'--enable-xmalloc-statistics' '--enable-ident-lookups' 
'--with-filedescriptors=65536' '--with-aufs-threads=128' 
'--disable-arch-native' '--with-logdir=/var/log/squid' 
'--with-pidfile=/var/run/squid/squid.pid' 
'--with-swapdir=/var/cache/squid' 'build_alias=x86_64-linux-gnu'



Le 14/01/2021 à 05:43, Amos Jeffries a écrit :

On 14/01/21 3:17 am, David Touzeau wrote:


Hi

This error is generated every 15 minutes when using any authenticator 
helper (ntlm, kerberos...)


Is there a way to investigate on this issue ?

kidxx| WARNING: no_suid: setuid(0): (1) Operation not permitted



This looks like 


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