Re: [squid-users] squid 4.5, can't download certificate?

2019-01-21 Thread Dmitry Melekhov

21.01.2019 22:29, Alex Rousskov пишет:

On 1/21/19 9:08 AM, Dmitry Melekhov wrote:


Your Squid (or some helper) appears to be adding an
"-/...GETmyip=-myport=0" suffix to the crt.sectigo.com URL,
resulting in a 404 response from that server.

Is there any reasons squid sends :::::::
to redirector?

What Squid logformat %code or url_rewrite_extras %code does that address
come from?



default on my case


  Should the corresponding request have that address? For
example, internally-generated requests do not have HTTP client addresses.

Will the redirector work if that address is sent as a "-" instead of
"ff...fff"?


rejik redirector developer thinks its better to use 127.0.0.1 as squid 
address,


but said that this is squid preference...

if can read discussion here 
https://rejik.ru/bb_rus/viewtopic.php?f=1&t=1979 in russian.


Thank you!



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


[squid-users] TCP_TUNNEL and ecap

2019-01-21 Thread Michael Hendrie
Hi All,

I have an ecap adapter that amongst other things tracks response size.  This 
works fine for HTTP and ssl-bump'd HTTPS but not for TCP_TUNNEL responses as 
they are not seen by the ecap adapter.

I understand that in most cases adaptation of a tunnelled HTTPS response is 
pointless as it would result message corruption but wondering if it is at all 
possible to get the TCP_TUNNEL response seen by ecap, I cant see a config 
option for it in 3.5 or 4.5.

Thanks, 

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


Re: [squid-users] squid 4.5, can't download certificate?

2019-01-21 Thread Alex Rousskov
On 1/21/19 9:08 AM, Dmitry Melekhov wrote:

>> Your Squid (or some helper) appears to be adding an
>> "-/...GETmyip=-myport=0" suffix to the crt.sectigo.com URL,
>> resulting in a 404 response from that server.

> Is there any reasons squid sends :::::::
> to redirector?

What Squid logformat %code or url_rewrite_extras %code does that address
come from? Should the corresponding request have that address? For
example, internally-generated requests do not have HTTP client addresses.

Will the redirector work if that address is sent as a "-" instead of
"ff...fff"?


Cheers,

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


Re: [squid-users] External acl on delay_access directive

2019-01-21 Thread Alex Rousskov
On 1/21/19 5:22 AM, Luca Savarino wrote:

> Attached is a patch which seems to fix the issue.

Glad you have a fix that works for you, but this mailing list is not the
right place for patch reviews. If you want to submit your changes to the
Squid project, I suggest creating a GitHub pull request. The procedure
is outlined at https://wiki.squid-cache.org/MergeProcedure


> Does it seem correct to you ?

The patch is buggy: Setting AccessLogEntry::reply field like that may
lead to memory leaks and/or crashes. Ideally, the reply field should be
set when the reply becomes known. I do not know whether that is already
done (elsewhere in the code). If it is done, than the reply setting line
in the patch can be removed. You can answer that question for your
particular use case by checking (e.g., in a debugger or by adding a
debugs() message) whether http->al->reply is nil before the assignment.


HTH,

Alex.


> On 1/17/19 5:39 PM, Alex Rousskov wrote:
>> On 1/17/19 9:13 AM, Luca Savarino wrote:
>>
>>> WARNING: ip_list ACL is used in context without an ALE
>>> state. Assuming mismatch.
>>> delay_access 1 allow ip_list
>> Looks like a Squid bug to me -- Squid should supply ALE (a blob
>> containing various transaction details) to the delay_access code but
>> evidently does not.
>>
>> If you are a developer or can hire a developer to fix this bug, a good
>> starting point could be the missing ACLFilledChecklist::al
>> initialization in DelayId::DelayClient().
>>
>>
>> HTH,
>>
>> 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] ICAP and 403 Encapsulated answers (SSL denied domains)

2019-01-21 Thread Alex Rousskov
On 1/21/19 3:35 AM, FredB wrote:

> I'm playing with Squid4 and e2guardian as ICAP server.
> 
> I'm seeing something I misunderstand, when a SSL website is blocked
> e2guardian returns a encapsulated "HTTP/1.1 403 Forbidden" header this
> part seems good to me with an encrypted website a denied or redirection
> page can't be added

> But unfortunately Squid adds a "Connection: keep-alive" header

It is not clear _why_ you consider that header "unfortunate" and the
connection "wasted". That header may or may not be wrong, and the
connection may or may not be reusable, depending on many factors (that
you have not shared).


> and if I
> just reload the page I'm waiting a timeout a long moment, (and there is
> no ICAP request between squid and e2) it's like the previous connection
> still opened.
> 
> So the first request is well denied, but the second is without answer

Can the browser reuse the connection after receiving the HTTP 403
(Forbidden) response? Does it? If you provide a sample of client-Squid
request and response headers (including CONNECT messages, if any), and
specify whether they were all sharing the same TCP connection, then we
may be able to assign the blame for the "timeout".

If (some of) the messages are encrypted, providing ALL,2 cache.log may
work. Otherwise, a packet capture (in pcap format) is probably the
easiest sharing method.


> I tried to add "Connection: close" in encapsulated header from
> e2guardian without more success, but anyway "Connection: close" value is
> removed by squid

Yes, by ICAP design, an ICAP service does not have direct control over
HTTP connections maintained by the host application (e.g., Squid).

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


Re: [squid-users] squid 4.5, can't download certificate?

2019-01-21 Thread Dmitry Melekhov


21.01.2019 14:30, Dmitry Melekhov пишет:

Your Squid (or some helper) appears to be adding an

"-/...GETmyip=-myport=0" suffix to the crt.sectigo.com URL,
resulting in a 404 response from that server.
Yes, I suspected this, there is no helper which can add this, as 
far as

I know


These mangled URLs are the expected result of a URL-rewrite/redirector
helper written to use the long ago deprecated Squid-1.x version of
helper protocol. Being used in a Squid configured to allow 
whitespace in

URLs.

When those two features are combined there is no way for Squid to
identify garbage after the end of URL in helper 1.0 syntax response,
from a v2.x syntax response with whitespace in the URL.

Squid-3.5 and later are only backward compatible to the Squid-2.0 
helper

protocol. The older syntax is no longer supported at all.


Details of the Squid helper protocol can be found at
.




Thank you!

You are absolutely right.

This is redirector, if I disable it, everything works.

Will contact redirector developer.



There is  new rejik (rejik.ru) version, if somebody uses it, you can 
solve this problem by upgrade.




btw, according to redirector developer problem is in lack of ipv6 support.

Is there any reasons squid sends ::::::: 
to redirector?



Thank you!


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


Re: [squid-users] External acl on delay_access directive

2019-01-21 Thread Luca Savarino

Hello Alex,


        Thank you for your help. Attached is a patch which seems to fix 
the issue. Does it seem correct to you ?



Regards,


Luca

On 1/17/19 5:39 PM, Alex Rousskov wrote:

On 1/17/19 9:13 AM, Luca Savarino wrote:


WARNING: ip_list ACL is used in context without an ALE
state. Assuming mismatch.
delay_access 1 allow ip_list

Looks like a Squid bug to me -- Squid should supply ALE (a blob
containing various transaction details) to the delay_access code but
evidently does not.

If you are a developer or can hire a developer to fix this bug, a good
starting point could be the missing ACLFilledChecklist::al
initialization in DelayId::DelayClient().


HTH,

Alex.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
>From 284dbfccf8e5de22721d6480d97e20b43954cec7 Mon Sep 17 00:00:00 2001
From: Luca Savarino 
Date: Mon, 21 Jan 2019 13:09:26 +0100
Subject: [PATCH] Initializa ALE for delay_pools.

---
 src/DelayId.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/DelayId.cc b/src/DelayId.cc
index fbce786a8..a69d7d91d 100644
--- a/src/DelayId.cc
+++ b/src/DelayId.cc
@@ -97,6 +97,8 @@ DelayId::DelayClient(ClientHttpRequest * http, HttpReply *reply)
 #endif /* FOLLOW_X_FORWARDED_FOR */
 ch.src_addr = r->client_addr;
 ch.my_addr = r->my_addr;
+	ch.al = http->al;
+	ch.al->reply = reply;
 
 if (http->getConn() != NULL)
 ch.conn(http->getConn());
@@ -174,4 +176,3 @@ DelayId::delayRead(DeferredRead const &aRead)
 }
 
 #endif /* USE_DELAY_POOLS */
-
-- 
2.11.0

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


[squid-users] ICAP and 403 Encapsulated answers (SSL denied domains)

2019-01-21 Thread FredB

Hello all,

I'm playing with Squid4 and e2guardian as ICAP server.

I'm seeing something I misunderstand, when a SSL website is blocked 
e2guardian returns a encapsulated "HTTP/1.1 403 Forbidden" header this 
part seems good to me with an encrypted website a denied or redirection 
page can't be added


But unfortunately Squid adds a "Connection: keep-alive" header and if I 
just reload the page I'm waiting a timeout a long moment, (and there is 
no ICAP request between squid and e2) it's like the previous connection 
still opened.


So the first request is well denied, but the second is without answer

I tried to add "Connection: close" in encapsulated header from 
e2guardian without more success, but anyway "Connection: close" value is 
removed by squid


I'm doing something wrong ? This wastes connections and from user point 
of view the proxy is (very) slow, for example with ADS filtering some 
websites freezes


FI the request is well denied in squid and E2 logs

Maybe this is a bug, but I don't known if the issue is from Squid or E2 
? What is the correct response from an ICAP server with a denied SSL 
website request ?


Thank you

Fred



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


Re: [squid-users] squid 4.5, can't download certificate?

2019-01-21 Thread Dmitry Melekhov

21.01.2019 8:39, Dmitry Melekhov пишет:

18.01.2019 21:08, Amos Jeffries пишет:

On 19/01/19 4:31 am, Alex Rousskov wrote:

On 1/18/19 4:35 AM, Dmitry Melekhov wrote:

17.01.2019 21:02, Alex Rousskov пишет:

On 1/16/19 10:30 PM, Dmitry Melekhov wrote:


2019/01/17 09:18:21 kid1| ERROR: negotiating TLS on FD 55:
error:14090086:SSL routines:ssl3_get_server_certificate:certificate
verify failed (1/-1/0)
In access log:
1547702300.945  0 192.168.22.229 NONE/503 329 GET
https://lkk-udm.esplus.ru/Services/Auth.asmx/Safe? dm HIER_NONE/-
text/html
1547702301.304 84 - TCP_MISS/404 162 GET
http://crt.sectigo.com/SectigoRSADomainValidationSecureServerCA.crt-/:::::::-GETmyip=-myport=0 


- HIER_DIRECT/91.199.212.52 text/html

Your Squid (or some helper) appears to be adding an
"-/...GETmyip=-myport=0" suffix to the crt.sectigo.com URL,
resulting in a 404 response from that server.
Yes, I suspected this, there is no helper which can add this, as 
far as

I know


These mangled URLs are the expected result of a URL-rewrite/redirector
helper written to use the long ago deprecated Squid-1.x version of
helper protocol. Being used in a Squid configured to allow whitespace in
URLs.

When those two features are combined there is no way for Squid to
identify garbage after the end of URL in helper 1.0 syntax response,
from a v2.x syntax response with whitespace in the URL.

Squid-3.5 and later are only backward compatible to the Squid-2.0 helper
protocol. The older syntax is no longer supported at all.


Details of the Squid helper protocol can be found at
.




Thank you!

You are absolutely right.

This is redirector, if I disable it, everything works.

Will contact redirector developer.



There is  new rejik (rejik.ru) version, if somebody uses it, you can 
solve this problem by upgrade.



Thank you!



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


Re: [squid-users] What's the best way to ban Let's encrypt based certificates? or whitelist a very narrow list of Root and Intermediates CA?

2019-01-21 Thread Amos Jeffries
On 21/01/19 11:02 am, Eliezer Croitoru wrote:
> OK so from the real world:
> 
> What's the best way to ban Let's encrypt based certificates? or
> whitelist a very narrow list of Root and Intermediates CA?
> 


Besides what Alex has answered to your first question. I think the
simpler approach would be the second, and probably more what you need
anyway...

 tls_outgoing_options default-ca=off cafile=X.pem cafile=Y.pem


That makes Squid outgoing connections *not* use the global Trusted CA
set. Then explicitly load the individual one(s) you *do* want to trust.

A whitelist - but only for the root / self-signed CA certs. Intermediary
CAs inherit their trust (or lack) from their root CA.

If intermediary CA trust matters to your situation then a custom
validator as mentioned by Alex would be necessary.

NP: You can list cafile=... as many times as you wish to load multiple
files and should be able to load multiple CA certs in any of the
file(s). But have not confirmed that latter.

cache_peer has matching options with "tls-" prefix.

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


Re: [squid-users] What's the best way to ban Let's encrypt based certificates? or whitelist a very narrow list of Root and Intermediates CA?

2019-01-21 Thread Andrea Venturoli

On 1/20/19 11:02 PM, Eliezer Croitoru wrote:

The issue is that these sites are encrypted but do not offer any way of 
assuring real ISO and couple other compatibilities of the ORG.


For a simple home user it’s fine most of the time but for some it’s not.


Just out of curiosity, could you better explain this?
Pointer are enough if you prefer.

 bye & Thanks
av.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


Re: [squid-users] https debug

2019-01-21 Thread Amos Jeffries
On 21/01/19 11:15 am, Eliezer Croitoru wrote:
> You probably meant 4.5...
> http://www1.ngtech.co.il/repo/centos/7/x86_64/squid-4.5-1.el7.x86_64.rpm
> 

Time travel ...

> -Original Message-
> From: Amos Jeffries
> Sent: Wednesday, January 2, 2019 12:01

... back when 4.4 was all you had.

;-P

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