Re: [squid-users] ERROR: Unknown TLS option clientca

[login mogin]

I have just checked with the debug_options and saw that
sslflags=DELAYED_AUTH made it skip the client cert request. Just commented
that on the config and now it works!

Thanks a lot!

Amos Jeffries , 19 Tem 2018 Per, 11:35 tarihinde şunu
yazdı:

> On 18/07/18 23:54, login mogin wrote:
> > Hi there,
> >
> > I have just tried with the patch and it is still not working. Do you
> > want any particular log or debug output?
> >
>
> If you could provide the cache.log output with:
>   debug_options ALL,1 3, 5, 83,9
>
> ... and a full-data packet trace of the TLS handshake.
>
> There may be more clues as to what is happening in there.
>
> (you can post that to me privately if you wish).
>
> Amos
>
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] FTP recursive directory CWD

[senor]

Hi Guys,
I've run into an issue with proxy and FTP. Squid is doing more than a browser 
would do to display a directory listing but I'm not sure why.
The FTP site has a directory structure like /top/dir1/dir2/dir3/files where 
dir2 is not readable. Using a browser without proxy, you can navigate to 
/top/dir1/dir2/dir3/ and get a listing of files in dir3 as well as download any 
of them. Accessing via squid will fail and I've found through packet caps and 
poking around code that it does a CWD on each of the directories starting at 
top. It runs into dir2 where it has no permissions, receives and error and 
quits.

I'm sure there is a reason for recursively listing each directory but, in this 
case, I don't think a fail should be the end of the road. It may cause a 
specific possible future action unavailable. Is there a workaround? Is this 
something that should be submitted as a feature request? Am I misunderstanding 
something?

Enlightenment is appreciated. Thanks,

-Senor

[cid:part1.C62E7EC8.EA524190@hotmail.com]
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] question about squid and https connection .

[Alex Rousskov]

On 07/19/2018 12:08 PM, Eliezer Croitoru wrote:

> So the ROOT CA key which squid is using is being used for all the fake 
> certificates, why do we need so many copies of it?

FWIW, I cannot think of any reason to store the CA certificate key in
the database of generated certificates. That key is only used to sign a
freshly generated certificate, and the certificate generator never
regenerates certificates, so I do not see the need to reuse that CA key.

Alex.


> -Original Message-
> From: Alex Rousskov [mailto:rouss...@measurement-factory.com]
> Sent: Wednesday, July 18, 2018 11:45 PM
> To: Eliezer Croitoru ; 'Squid Users' 
> 
> Subject: Re: [squid-users] question about squid and https connection .
> 
> On 07/18/2018 02:23 PM, Eliezer Croitoru wrote:
> 
> 
>> Every certificate have the same properties of the original one except 
>> the "RSA key" part which it's certifiying.
> 
> Assuming you are talking about the generated certificates for the same real 
> certificate X, then yes, they will all have the same (mimicked) fields. 
> Whether they will be signed by the same CA depends on Squid configuration. In 
> my answers, I assumed that all those Squids are configured with the same CA 
> (including the same private key).
> 
> 
>> So what I'm saying is that you cannot say that every certificate which 
>> will be created with the same CA will be the same for two different 
>> 2048 bits RSA keys.
> 
> ... unless the keys are also the same, which was my and, AFAICT, OP 
> assumption.
> 
> Also, unless you are doing something nasty, it probably does not make sense 
> to configure a bumping Squid with a public CA certificate that is identical 
> to some other public CA certificate but has a different private key. In other 
> words, if you are using 200 Squids with a single public CA certificate, then 
> all those Squids should use the same private key.
> 
> Alex.
> 
> 
> 
>> -Original Message-
>> From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] 
>> On Behalf Of Alex Rousskov
>> Sent: Friday, July 13, 2018 2:01 AM
>> To: 'Squid Users' 
>> Subject: Re: [squid-users] question about squid and https connection .
>>
>> On 07/12/2018 02:35 PM, Eliezer Croitoru wrote:
>>
>>> Every RSA key and certificate pair regardless to the origin server 
>>> and the SSL-BUMP enabled proxy can be different.
>>
>> I cannot find a reasonable interpretation of the above that would 
>> contradict what I have said. Yes, each unique certificate has its own 
>> private key, but that is not what Ahmad was asking about AFAICT.
>>
>>
>>> Will it be more accurate to say that just as long as these 200 squid 
>>> instances(different squid.conf and couple other local variables) use 
>>> the same exact ssl_db cache directory  then it's probable that they 
>>> will use the same certificate.
>>
>> That statement is incorrect. Squids configured with different CA 
>> certificates will generate different fake certificates for the same 
>> real certificate.
>>
>> I assume that Ahmad was asking about a situation where 200 Squid 
>> instances had the same configuration (including CA certificates).
>>
>> Please note that the certificate generator helper gets the signing 
>> (CA) certificate as a parameter with each generation request (because 
>> different Squid ports may use different CA certificates). Also, Squid 
>> probably does not officially support sharing the certificate directory 
>> across Squid instances (even if it works).
>>
>>
>>> Or these 200 squid instances are in SMP mode with 200 workers... If 
>>> these 200 instances do not share memory and certificate cache then 
>>> there is a possibility that the same site from two different sources 
>>> will serve different certificates(due to the different RSA key which 
>>> is different).
>>
>> 200 SMP workers or 200 identically-configured Squid instances will 
>> generate the same fake certificates for the same real certificate.
>> "Stable certificates" is an important requirement for many distributed 
>> Squid deployments.
>>
>> Alex.
>>
>>
>>
>>> -Original Message-
>>> From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] 
>>> On Behalf Of Alex Rousskov
>>> Sent: Thursday, July 12, 2018 11:27 PM
>>> To: --Ahmad-- ; Squid Users 
>>> 
>>> Subject: Re: [squid-users] question about squid and https connection .
>>>
>>> On 07/12/2018 01:17 PM, --Ahmad-- wrote:
>>>
 if i have pc# 1 and that pc open facebook .

 then i have other pc # 2 and that other pc open facebook .


 now  as we know facebook is https .

 so is the key/ cert that used on pc # 1 is same as cert in pc # 2 to 
 decrypt the fb encrypted traffic ?
>>>
>>> Certificates themselves are not used (directly) to decrypt traffic 
>>> AFAIK, but yes, both PCs will see the same server certificate 
>>> (ignoring CDNs and other complications).
>>>
>>>
>>>
 now in the presence of squid .

 if i used tcp connect method  , will it be different 

Re: [squid-users] store_id_extras to access request header

[Michael Pro]

If you want, please support this topic in the bug-report
http://lists.squid-cache.org/pipermail/squid-users/2018-July/018743.html
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] store_id_extras and http Request Headers

[Eliezer Croitoru]

Thanks!

I didn't had much time to file the report due to some overload at work.
And I kind of overcome some level of this issue with a tiny ICAP REQMOD hack.
It's not the best solution but if it works and removes from the StoreID helper 
the
burden to reach any form of DB like MySql or Redis or MemCached it will remove 
many
blocking operations and will help the server and service work faster.

Eliezer

* I will try to follow up in the bug report.


Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il



-Original Message-
From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf 
Of Michael Pro
Sent: Thursday, July 19, 2018 8:21 PM
To: Alex Rousskov 
Cc: squid-users@lists.squid-cache.org
Subject: Re: [squid-users] store_id_extras and http Request Headers

On your recommendation posted it in bug-story of squid
https://bugs.squid-cache.org/show_bug.cgi?id=4873

We will wait for the release of the patch with impatience.
чт, 19 июл. 2018 г. в 17:46, Alex Rousskov :
>
> On 07/19/2018 05:58 AM, Michael Pro wrote:
> > Not only I have this problem
> > http://lists.squid-cache.org/pipermail/squid-users/2018-July/018637.html
> > Is it worthwhile in the near future to expect to fix this bug, or to
> > hook, I hope temporarily, a bunch of icap-> mysql <->
> > store_id_program?
>
> I am not sure I understand the question -- only you can decide what is
> worthwhile. FWIW, I am not aware of anybody working on this bug. In
> fact, I am not sure this bug has even been properly reported (as
> requested in the thread you linked to above).
>
> https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F
>
> Alex.
>
>
>
> > ср, 18 июл. 2018 г. в 23:35, Alex Rousskov 
> > :
> >>
> >> On 07/18/2018 02:29 PM, Michael Pro wrote:
> >>> In squid.conf
> >>> store_id_extras "%>a/%>A %un %>rm %>h myip=%la myport=%lp
> >>> %{User-Agent}>h %{Referer}>h %{Host}>h %>rP"
> >>>
> >>> Result incoming parameters in store_id_program are:
> >>> 0:  https://2ip.ua/images/icon/IP_calculator.png <--- (requested url)
> >>> 1:  127.0.0.119/127.0.0.119  <--- %>a/%>A
> >>> 2:  -   <--- %un (this is ok, absent at all)
> >>> 3:  GET  <--- %>rm
> >>> 4:  -   <- %>h ---> Where are they !?!?!?
> >>> 5:  myip=127.0.0.1
> >>> 6:  myport=20990
> >>> 7:  Mozilla/5.0%20(iPhone;%20CPU%20iPhone%20OS%2...  <--- %{User-Agent}>h
> >>> 8:  https://2ip.ua/ru/  <--- {Referer}>h
> >>> 9:  2ip.ua  <--- %{Host}>h
> >>> 10: 443  <--- %>rP
> >>>
> >>> How do I get all the request header fields?
> >>> I do not need any separate, I need all fields in the request header.
> >>
> >> The lack of %>h output when %{Name}>h output is present looks like a
> >> Squid bug to me -- %>h output should be there as well.
> >>
> >> 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] question about squid and https connection .

[Eliezer Croitoru]

Sorry a keyboard key broke while reviewing the text...

OK so it doesn't make any sense to store so many copies of the exact same "KEY" 
in the ssl_db/certs files..
I took a sample from my certs directory and extracted the keys that are stored 
at the QA server:
## Start
[root@squid4-testing 1]# ll
total 12
-rw-r--r--. 1 root root 1704 Jul 19 20:58 key1.pem
-rw-r--r--. 1 root root 1704 Jul 19 20:58 key2.pem
-rw-r--r--. 1 root root 1704 Jul 19 20:59 rootCA-key.pem
[root@squid4-testing 1]# cat key1.pem |sha256sum
3db2a55499015a4166f8059d378d79032ee85797f92176d7a4d5ad8a2025bec7  -
[root@squid4-testing 1]# cat key2.pem |sha256sum
3db2a55499015a4166f8059d378d79032ee85797f92176d7a4d5ad8a2025bec7  -
[root@squid4-testing 1]# cat rootCA-key.pem |sha256sum
3db2a55499015a4166f8059d378d79032ee85797f92176d7a4d5ad8a2025bec7
## END

So the ROOT CA key which squid is using is being used for all the fake 
certificates, why do we need so many copies of it?
I think that the helper and the DB store can be simplified or added simplicity 
for single servers.
For small servers this space is nothing but... for large systems it's an issue.
Also for embedded devices which every IO r/w counts before the flash/nand dies 
I think we can do something about it.

Thanks,
Eliezer

-
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il


-Original Message-
From: Alex Rousskov [mailto:rouss...@measurement-factory.com]
Sent: Wednesday, July 18, 2018 11:45 PM
To: Eliezer Croitoru ; 'Squid Users' 

Subject: Re: [squid-users] question about squid and https connection .

On 07/18/2018 02:23 PM, Eliezer Croitoru wrote:


> Every certificate have the same properties of the original one except 
> the "RSA key" part which it's certifiying.

Assuming you are talking about the generated certificates for the same real 
certificate X, then yes, they will all have the same (mimicked) fields. Whether 
they will be signed by the same CA depends on Squid configuration. In my 
answers, I assumed that all those Squids are configured with the same CA 
(including the same private key).


> So what I'm saying is that you cannot say that every certificate which 
> will be created with the same CA will be the same for two different 
> 2048 bits RSA keys.

... unless the keys are also the same, which was my and, AFAICT, OP assumption.

Also, unless you are doing something nasty, it probably does not make sense to 
configure a bumping Squid with a public CA certificate that is identical to 
some other public CA certificate but has a different private key. In other 
words, if you are using 200 Squids with a single public CA certificate, then 
all those Squids should use the same private key.

Alex.



> -Original Message-
> From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] 
> On Behalf Of Alex Rousskov
> Sent: Friday, July 13, 2018 2:01 AM
> To: 'Squid Users' 
> Subject: Re: [squid-users] question about squid and https connection .
> 
> On 07/12/2018 02:35 PM, Eliezer Croitoru wrote:
> 
>> Every RSA key and certificate pair regardless to the origin server 
>> and the SSL-BUMP enabled proxy can be different.
> 
> I cannot find a reasonable interpretation of the above that would 
> contradict what I have said. Yes, each unique certificate has its own 
> private key, but that is not what Ahmad was asking about AFAICT.
> 
> 
>> Will it be more accurate to say that just as long as these 200 squid 
>> instances(different squid.conf and couple other local variables) use 
>> the same exact ssl_db cache directory  then it's probable that they 
>> will use the same certificate.
> 
> That statement is incorrect. Squids configured with different CA 
> certificates will generate different fake certificates for the same 
> real certificate.
> 
> I assume that Ahmad was asking about a situation where 200 Squid 
> instances had the same configuration (including CA certificates).
> 
> Please note that the certificate generator helper gets the signing 
> (CA) certificate as a parameter with each generation request (because 
> different Squid ports may use different CA certificates). Also, Squid 
> probably does not officially support sharing the certificate directory 
> across Squid instances (even if it works).
> 
> 
>> Or these 200 squid instances are in SMP mode with 200 workers... If 
>> these 200 instances do not share memory and certificate cache then 
>> there is a possibility that the same site from two different sources 
>> will serve different certificates(due to the different RSA key which 
>> is different).
> 
> 200 SMP workers or 200 identically-configured Squid instances will 
> generate the same fake certificates for the same real certificate.
> "Stable certificates" is an important requirement for many distributed 
> Squid deployments.
> 
> Alex.
> 
> 
> 
>> -Original Message-
>> From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] 
>> On Behalf Of Alex Rousskov

Re: [squid-users] question about squid and https connection .

[Eliezer Croitoru]

OK so it doesn't make any sense to store so many copies of the "KEY" in the 
ssl_db/certs files..
I took a sample from my certs directory and extracted the keys that are stored 
at












]\
[root@squid4-testing 1]# ll
total 12
-rw-r--r--. 1 root root 1704 Jul 19 20:58 key1.pem
-rw-r--r--. 1 root root 1704 Jul 19 20:58 key2.pem
-rw-r--r--. 1 root root 1704 Jul 19 20:59 rootCA-key.pem
[root@squid4-testing 1]# cat key1.pem |sha256sum
3db2a55499015a4166f8059d378d79032ee85797f92176d7a4d5ad8a2025bec7  -
[root@squid4-testing 1]# cat key2.pem |sha256sum
3db2a55499015a4166f8059d378d79032ee85797f92176d7a4d5ad8a2025bec7  -
[root@squid4-testing 1]# cat rootCA-key.pem |sha256sum
3db2a55499015a4166f8059d378d79032ee85797f92176d7a4d5ad8a2025bec7  -


Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il


-Original Message-
From: Alex Rousskov [mailto:rouss...@measurement-factory.com] 
Sent: Wednesday, July 18, 2018 11:45 PM
To: Eliezer Croitoru ; 'Squid Users' 

Subject: Re: [squid-users] question about squid and https connection .

On 07/18/2018 02:23 PM, Eliezer Croitoru wrote:


> Every certificate have the same properties of the original one except
> the "RSA key" part which it's certifiying.

Assuming you are talking about the generated certificates for the same
real certificate X, then yes, they will all have the same (mimicked)
fields. Whether they will be signed by the same CA depends on Squid
configuration. In my answers, I assumed that all those Squids are
configured with the same CA (including the same private key).


> So what I'm saying is that you cannot say that every certificate
> which will be created with the same CA will be the same for two
> different 2048 bits RSA keys.

... unless the keys are also the same, which was my and, AFAICT, OP
assumption.

Also, unless you are doing something nasty, it probably does not make
sense to configure a bumping Squid with a public CA certificate that is
identical to some other public CA certificate but has a different
private key. In other words, if you are using 200 Squids with a single
public CA certificate, then all those Squids should use the same private
key.

Alex.



> -Original Message-
> From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On 
> Behalf Of Alex Rousskov
> Sent: Friday, July 13, 2018 2:01 AM
> To: 'Squid Users' 
> Subject: Re: [squid-users] question about squid and https connection .
> 
> On 07/12/2018 02:35 PM, Eliezer Croitoru wrote:
> 
>> Every RSA key and certificate pair regardless to the origin server
>> and the SSL-BUMP enabled proxy can be different.
> 
> I cannot find a reasonable interpretation of the above that would
> contradict what I have said. Yes, each unique certificate has its own
> private key, but that is not what Ahmad was asking about AFAICT.
> 
> 
>> Will it be more accurate to say that just as long as these 200 squid
>> instances(different squid.conf and couple other local variables) use
>> the same exact ssl_db cache directory  then it's probable that they
>> will use the same certificate.
> 
> That statement is incorrect. Squids configured with different CA
> certificates will generate different fake certificates for the same real
> certificate.
> 
> I assume that Ahmad was asking about a situation where 200 Squid
> instances had the same configuration (including CA certificates).
> 
> Please note that the certificate generator helper gets the signing (CA)
> certificate as a parameter with each generation request (because
> different Squid ports may use different CA certificates). Also, Squid
> probably does not officially support sharing the certificate directory
> across Squid instances (even if it works).
> 
> 
>> Or these 200 squid instances are in SMP mode with 200 workers... If
>> these 200 instances do not share memory and certificate cache then
>> there is a possibility that the same site from two different sources 
>> will serve different certificates(due to the different RSA key which
>> is different).
> 
> 200 SMP workers or 200 identically-configured Squid instances will
> generate the same fake certificates for the same real certificate.
> "Stable certificates" is an important requirement for many distributed
> Squid deployments.
> 
> Alex.
> 
> 
> 
>> -Original Message-
>> From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On 
>> Behalf Of Alex Rousskov
>> Sent: Thursday, July 12, 2018 11:27 PM
>> To: --Ahmad-- ; Squid Users 
>> 
>> Subject: Re: [squid-users] question about squid and https connection .
>>
>> On 07/12/2018 01:17 PM, --Ahmad-- wrote:
>>
>>> if i have pc# 1 and that pc open facebook .
>>>
>>> then i have other pc # 2 and that other pc open facebook .
>>>
>>>
>>> now  as we know facebook is https .
>>>
>>> so is the key/ cert that used on pc # 1 is same as cert in pc # 2 to 
>>> decrypt the fb encrypted traffic ?
>>
>> Certificates themselves are not used (directly) to decrypt 

Re: [squid-users] store_id_extras and http Request Headers

[Michael Pro]

On your recommendation posted it in bug-story of squid
https://bugs.squid-cache.org/show_bug.cgi?id=4873

We will wait for the release of the patch with impatience.
чт, 19 июл. 2018 г. в 17:46, Alex Rousskov :
>
> On 07/19/2018 05:58 AM, Michael Pro wrote:
> > Not only I have this problem
> > http://lists.squid-cache.org/pipermail/squid-users/2018-July/018637.html
> > Is it worthwhile in the near future to expect to fix this bug, or to
> > hook, I hope temporarily, a bunch of icap-> mysql <->
> > store_id_program?
>
> I am not sure I understand the question -- only you can decide what is
> worthwhile. FWIW, I am not aware of anybody working on this bug. In
> fact, I am not sure this bug has even been properly reported (as
> requested in the thread you linked to above).
>
> https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F
>
> Alex.
>
>
>
> > ср, 18 июл. 2018 г. в 23:35, Alex Rousskov 
> > :
> >>
> >> On 07/18/2018 02:29 PM, Michael Pro wrote:
> >>> In squid.conf
> >>> store_id_extras "%>a/%>A %un %>rm %>h myip=%la myport=%lp
> >>> %{User-Agent}>h %{Referer}>h %{Host}>h %>rP"
> >>>
> >>> Result incoming parameters in store_id_program are:
> >>> 0:  https://2ip.ua/images/icon/IP_calculator.png <--- (requested url)
> >>> 1:  127.0.0.119/127.0.0.119  <--- %>a/%>A
> >>> 2:  -   <--- %un (this is ok, absent at all)
> >>> 3:  GET  <--- %>rm
> >>> 4:  -   <- %>h ---> Where are they !?!?!?
> >>> 5:  myip=127.0.0.1
> >>> 6:  myport=20990
> >>> 7:  Mozilla/5.0%20(iPhone;%20CPU%20iPhone%20OS%2...  <--- %{User-Agent}>h
> >>> 8:  https://2ip.ua/ru/  <--- {Referer}>h
> >>> 9:  2ip.ua  <--- %{Host}>h
> >>> 10: 443  <--- %>rP
> >>>
> >>> How do I get all the request header fields?
> >>> I do not need any separate, I need all fields in the request header.
> >>
> >> The lack of %>h output when %{Name}>h output is present looks like a
> >> Squid bug to me -- %>h output should be there as well.
> >>
> >> Alex.
>
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] store_id_extras and http Request Headers

[Alex Rousskov]

On 07/19/2018 05:58 AM, Michael Pro wrote:
> Not only I have this problem
> http://lists.squid-cache.org/pipermail/squid-users/2018-July/018637.html
> Is it worthwhile in the near future to expect to fix this bug, or to
> hook, I hope temporarily, a bunch of icap-> mysql <->
> store_id_program?

I am not sure I understand the question -- only you can decide what is
worthwhile. FWIW, I am not aware of anybody working on this bug. In
fact, I am not sure this bug has even been properly reported (as
requested in the thread you linked to above).

https://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F

Alex.



> ср, 18 июл. 2018 г. в 23:35, Alex Rousskov :
>>
>> On 07/18/2018 02:29 PM, Michael Pro wrote:
>>> In squid.conf
>>> store_id_extras "%>a/%>A %un %>rm %>h myip=%la myport=%lp
>>> %{User-Agent}>h %{Referer}>h %{Host}>h %>rP"
>>>
>>> Result incoming parameters in store_id_program are:
>>> 0:  https://2ip.ua/images/icon/IP_calculator.png <--- (requested url)
>>> 1:  127.0.0.119/127.0.0.119  <--- %>a/%>A
>>> 2:  -   <--- %un (this is ok, absent at all)
>>> 3:  GET  <--- %>rm
>>> 4:  -   <- %>h ---> Where are they !?!?!?
>>> 5:  myip=127.0.0.1
>>> 6:  myport=20990
>>> 7:  Mozilla/5.0%20(iPhone;%20CPU%20iPhone%20OS%2...  <--- %{User-Agent}>h
>>> 8:  https://2ip.ua/ru/  <--- {Referer}>h
>>> 9:  2ip.ua  <--- %{Host}>h
>>> 10: 443  <--- %>rP
>>>
>>> How do I get all the request header fields?
>>> I do not need any separate, I need all fields in the request header.
>>
>> The lack of %>h output when %{Name}>h output is present looks like a
>> Squid bug to me -- %>h output should be there as well.
>>
>> Alex.

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

Re: [squid-users] store_id_extras and http Request Headers

[Michael Pro]

Not only I have this problem
http://lists.squid-cache.org/pipermail/squid-users/2018-July/018637.html
Is it worthwhile in the near future to expect to fix this bug, or to
hook, I hope temporarily, a bunch of icap-> mysql <->
store_id_program?
ср, 18 июл. 2018 г. в 23:35, Alex Rousskov :
>
> On 07/18/2018 02:29 PM, Michael Pro wrote:
> > In squid.conf
> > store_id_extras "%>a/%>A %un %>rm %>h myip=%la myport=%lp
> > %{User-Agent}>h %{Referer}>h %{Host}>h %>rP"
> >
> > Result incoming parameters in store_id_program are:
> > 0:  https://2ip.ua/images/icon/IP_calculator.png <--- (requested url)
> > 1:  127.0.0.119/127.0.0.119  <--- %>a/%>A
> > 2:  -   <--- %un (this is ok, absent at all)
> > 3:  GET  <--- %>rm
> > 4:  -   <- %>h ---> Where are they !?!?!?
> > 5:  myip=127.0.0.1
> > 6:  myport=20990
> > 7:  Mozilla/5.0%20(iPhone;%20CPU%20iPhone%20OS%2...  <--- %{User-Agent}>h
> > 8:  https://2ip.ua/ru/  <--- {Referer}>h
> > 9:  2ip.ua  <--- %{Host}>h
> > 10: 443  <--- %>rP
> >
> > How do I get all the request header fields?
> > I do not need any separate, I need all fields in the request header.
>
> The lack of %>h output when %{Name}>h output is present looks like a
> Squid bug to me -- %>h output should be there as well.
>
> Alex.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Question about traffic calculate

[Tiraen]

live access.log streams is probably the most efficient way of doing this.

Concerning this moment

So in the logs only one half of the traffic, and if the incoming + outgoing

https://alter.org.ua/soft/fbsd/squid_tot_sz/

All the patches I found are related to the old versions of the SQUID
for 3.5 this is not

2018-06-21 19:20 GMT+03:00 Alex Rousskov :

> On 06/21/2018 05:14 AM, Tiraen wrote:
> > where i can read more about this (I mean the development of custom
> > ICAP/eCAP modules and their connection to the proxy) ?
>
> The best place to start is probably
> https://wiki.squid-cache.org/SquidFaq/ContentAdaptation
>
> If you decide to go the ICAP route, you will need to find the right ICAP
> server for your project. After that, the development will revolve around
> writing a custom adapter for that ICAP server. The above URL links to a
> page with a list of ICAP servers:
> https://wiki.squid-cache.org/Features/ICAP
>
> If you decide to go the eCAP route, you will need to (find somebody to)
> write an eCAP adapter (no server required).
>
> In either case, the required development is similar to writing a plugin
> or loadable module. Any capable developer can do it, but understanding
> of HTTP concepts and familiarity with the ICAP server or eCAP API helps.
>
>
> HTH,
>
> Alex.
>
>
> > 2018-06-13 18:35 GMT+03:00 Alex Rousskov:
> >
> > On 06/13/2018 07:09 AM, Matus UHLAR - fantomas wrote:
> > > On 13.06.18 13:26, Tiraen wrote:
> > >> ICAP will help provide data on incoming / outgoing traffic?
> >
> > > icap can get the data and work with it.
> > > you don't have to manipulate, just do the accounting.
> > > you just need ICAP module that will do it.
> >
> >
> > Yes, it is possible to collect more-or-less accurate incoming request
> > and incoming response stats using an ICAP service, but doing so
> would be
> > very inefficient. Using eCAP would improve performance, but
> interpreting
> > live access.log streams is probably the most efficient way of doing
> > this.
> >
> > IIRC, both eCAP and ICAP interfaces do not see the exact incoming
> > requests and incoming responses because Squid may strip hop-by-hop
> HTTP
> > headers and decode chunked HTTP message bodies before forwarding the
> > incoming message to the adaptation service. If you need exact headers
> > and exact body sizes, then you need more than just the basic ICAP and
> > eCAP interface. Again, access.log is probably an overall better
> choice
> > for capturing that info.
> >
> > Both eCAP and ICAP interfaces do not see outgoing requests and
> outgoing
> > responses because Squid only supports pre-cache vectoring points.
> >
> >
> > HTH,
> >
> > Alex.
> > P.S. In the above, "incoming" is "to Squid" and "outgoing" is "from
> > Squid".
> >
> >
> > >> 2018-06-13 12:54 GMT+03:00 Matus UHLAR - fantomas <
> uh...@fantomas.sk >:
> > >>
> > >>> On 13.06.18 11:51, Tiraen wrote:
> > >>>
> >  either such a question, perhaps someone in the course
> > 
> >  in the SQUID is still not implemented radius accounting?
> > 
> > >>>
> > >>> authentication - yes. But squid doese not support accounting
> (afaik).
> > >>>
> > >>> Maybe there are any third-party modules working correctly?
> > 
> > >>>
> > >>> maybe iCAP module.
> >
> >
> > ___
> > squid-users mailing list
> > squid-users@lists.squid-cache.org
> > 
> > http://lists.squid-cache.org/listinfo/squid-users
> > 
> >
> >
> >
> >
> > --
> > With best regards,
> >
> > Vyacheslav Yakushev,
> >
> > Unix system administrator
> >
> > https://t.me/kelewind
>
>


-- 
With best regards,

Vyacheslav Yakushev,

Unix system administrator

https://t.me/kelewind
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] ERROR: Unknown TLS option clientca

[Amos Jeffries]

On 18/07/18 23:54, login mogin wrote:
> Hi there,
> 
> I have just tried with the patch and it is still not working. Do you
> want any particular log or debug output?
> 

If you could provide the cache.log output with:
  debug_options ALL,1 3, 5, 83,9

... and a full-data packet trace of the TLS handshake.

There may be more clues as to what is happening in there.

(you can post that to me privately if you wish).

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