[squid-users] Problems with Squid Authentication

[Marcio Demetrio Bacci]

My Kerberos Authentication doesn't work. This is very hard!

My Squid3 is join in the Domain
kinit and klist are ok
wbinfo -g and wbinfo -u are ok too.

I have created the squid3 file in /etc/default with the following content:
KRB5_KTNAME=/etc/squid3/HTTP.keytab
export KRB5_KTNAME

I have two keytab files:
/etc/krb5.keytab and /etc/squid3/HTTP.keytab (both are identical)

I have installed libsasl2-modules-gssapi-mit libsasl2-modules packages
because my Squid server is Debian 8. But I didn't use msktutil tool. I have
only joined Squid server in the Domain (net ads join -U administrator)

How can I debbug the problem?
How can I test kerberos authentication in terminal (command line)?

Below is my squid.conf file:

### Configuracoes Basicas

cache_mgr administra...@empresa.com.br

http_port 3128

#debug_options ALL,111,2 29,9 84,6

cache_mem 512 MB
cache_swap_low 80
cache_swap_high 90

maximum_object_size 512 MB
minimum_object_size 0 KB

maximum_object_size_in_memory 4096 KB

cache_replacement_policy heap LFUDA
memory_replacement_policy heap LFUDA

#Para não bloquear downloads
quick_abort_min -1 KB


#Resolve um problema com conexoes persistentes
detect_broken_pconn on

fqdncache_size 1024

### Parametros de atualizacao da memoria cache
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

### Localizacao dos logs
access_log /var/log/squid3/access.log
cache_log /var/log/squid3/cache.log


### define a localizacao do cache de disco, tamanho, qtd de diretorios pai
e subdiretorios
cache_dir aufs /var/spool/squid3 600 16 256

auth_param negotiate program /usr/lib/squid3/negotiate_kerberos_auth -s
HTTP/proxy.empresa.com...@empresa.com.br
auth_param negotiate children 20
auth_param negotiate keep_alive on

visible_hostname proxy.empresa.com.br

### acls
#acl manager proto cache_object
acl localhost src 192.168.200.7/32
acl to_localhost dst 192.168.200.7/32
acl SSL_ports port 22 443 563 7071 1 # ssh, https, snews, zimbra, webmin
acl Safe_ports port 21 # ftp
acl Safe_ports port 70 # gopher
acl Safe_ports port 80 # http
acl Safe_ports port 88 # kerberos
acl Safe_ports port 210 # wais
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 389 # ldap
acl Safe_ports port 443 # https
acl Safe_ports port 488 # gss-http
acl Safe_ports port 563 # snews
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl Safe_ports port 3001 # imprenssa nacional
acl Safe_ports port 8080 # http
acl Safe_ports port 1025-65535 # unregistered ports

acl purge method PURGE
acl CONNECT method CONNECT


### Regras iniciais do Squid
http_access allow localhost
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

### Exige autenticacao
acl autenticados proxy_auth REQUIRED
http_access allow autenticados



### Rede do Local #
acl rede_local src 192.168.200.0/22


### Nega acesso de quem nao esta na rede local
http_access allow rede_local

#negando o acesso para todos que nao estiverem nas regras anteriores
http_access deny all

### Erros em portugues
error_directory /usr/share/squid3/errors/pt-br

#cache_effective_user proxy
coredump_dir /var/spool/squid3


Regards,

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

Re: [squid-users] Yet another store_id question HIT MISS

[Amos Jeffries]

On 19/08/2016 2:15 a.m., Omid Kosari wrote:
> I was correct .
> 
> If one of following conditions happens then the mentioned urls will not
> cache .
> 
> 1-in squid.conf have this line
> acl storeiddomainregex dstdom_regex
> ^igcdn(\-photos|\-videos)[a-z0-9\-]{0,9}\.akamaihd\.net$ 
> 

How you use that ACL in your access rule logics is just as important as
what it contains / matches.


> 2-in storeid_db have this line
> ^http:\/\/igcdn-.*\.akamaihd\.net/hphotos-ak-.*/(t5.*?)(?:\?|$)
> http://instagramcdn.squid.internal/$1


The pattern is malformed. Several parts of it are impossible to match,
and just make it look complicated when its not.

It is better written as:

^http:\/\/igcdn-[a-z0-9\-\.]+\.akamaihd\.net/hphotos-ak-[a-z0-9]+/(t5.*)
  http://instagramcdn.squid.internal/$2


> 
> Now the problem is with my mentioned squid.conf and store_id rules , the
> mentioned urls will not cache at all.Even if same url reopens many times .
> 

Store-ID does not force caching. All it does is provide Squid with a
different ID under which the item would be stored *IF* (and only if) it
would be stored normally.

I suggest removing the "ignore-no-store ignore-private" from your
.squid.internal refresh_pattern. They trigger actions that break the
image objects you actually want to store at that Store-ID location.

Amos

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

Re: [squid-users] HTTPS - THE PROXY SERVER IS REFUSING CONNECTIONS

[Amos Jeffries]

On 19/08/2016 2:52 a.m., L.P.H. van Belle wrote:
> That you proxy refused you connections is correct. 
> 
> You forgot to define an acl and allow it.  
> 

Aye. Compare the default config file with yours:

  

(the 3.5 one still applies to 3.4)

Amos

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

Re: [squid-users] Malformed HTTP on tproxy squid

[Alex Rousskov]

On 08/17/2016 10:47 AM, Alex Rousskov wrote:
> On 08/17/2016 10:25 AM, Amos Jeffries wrote:
> 
>> I don't think the delayer approach will work because these are parse
>> error/abort responses that don't go near any ACL system.
> 
> If an error response does not go through http_reply_access, then this is
> a Squid bug IMO.

In my primitive test, an error:invalid-request response does go through
the http_reply_access rules, as expected:

2016/08/17 16:10:11.206| 88,2| client_side_reply.cc(2049)
processReplyAccessResult: The reply for NONE error:invalid-request is
ALLOWED

Alex.

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

Re: [squid-users] Kerberos Autenthication doesn't work

[L . P . H . van Belle]

Ok, samba isnt yet in jessie backports.. so you now use the 4.2.10 version. 

 

Look here, these work good. 

I build them and i use them in my office for some time now.  

I?ll try the next version samba ( 4.4.5-3 ) in debian stretch to get in BPO. 

That one has the file overwrite fixed. (just read the readme.txt it explains 
all) 

 

Here you find a signed by me samba 4.4.5 ( amd64 and i386 packages for jessie )

http://downloads.van-belle.nl/samba4/ 

Again, please do read the readme.txt  

 

 

This part. 

STOP SERVICES

/etc/init.d/winbind stop

/etc/init.d/samba stop

update-rc.d winbind remove

update-rc.d samba remove

 

Dont remove winbind/samba inits. you need that to refresh the keytabs.

only winbind for keytab refresh is sufficient. 

 

 

KRB5_KTNAME=/etc/squid3/HTTP.keytab

export KRB5_KTNAME

KRB5RCACHETYPE=none

export KRB5RCACHETYPE

Add that in /etc/default/squid3  and try not to change default init.d debian 
files. 

The /etc/default/squid3 is included in the init script. 

 

 

Enable the kerberos auth line in you squid conf.

auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -s 
HTTP/proxy.empresa.com...@empresa.com.br

 

check both you keytabs, since Im not sure about your keytab files. 

Check where the HTTP SPN is defined. 

klist -k /etc/krb5.keytab 

klist -k /etc/squid3/HTTP.keytab

 

Try with these settings. 

1) /etc/krb5.conf

[libdefaults]

   default_realm = EMPRESA.COM.BR

   dns_lookup_kdc = yes

   dns_lookup_realm = no

 

then if that works, change it back to your needs. 

 

 

You can check if you get users out of winbind

wbinfo ?u 

if that works, set these lines to no, not needed for squid. 

  winbind enum users = yes

  winbind enum groups = yes

 

Try with these changes first. 

 

And last you did configure samba AD DC with ssl support? If not. 

Enable the old behavior. 

More info about that here : 

https://www.samba.org/samba/history/samba-4.4.2.html 

 

 

Greetz, 

 

Louis

 

 

 


Van: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] Namens 
Marcio Demetrio Bacci
Verzonden: donderdag 18 augustus 2016 16:09
Aan: Squid Users
Onderwerp: [squid-users] Kerberos Autenthication doesn't work


 

I have problems with Kerberos Autenthication in Squid3 on Debian 8 and Samba4 DC


My Squid version is: 3.4.8


 


My Kerberos Autenthication doesn't work.


 


PROCEDURES PERFORMED


 


INSTALL OF SAMBA4 AND WINBIND OF DEBIAN BACKPORTS


apt-get -t jessie-backports install samba samba-doc winbind


 


KERBEROS TEST: kinit administra...@empresa.com.br


klist -l


Principal Name                   Cache name


--                   --


administra...@empresa.com.br     FILE:/tmp/krb5cc_0


 


JOIN IN THE DOMAIN: net ads join -U administrator 


net ads testjoin: JOIN OK


 


kdestroy


KERBEROS TEST:kinit administra...@empresa.com.br


klist -l


Principal Name                   Cache name


--                   --


administra...@empresa.com.br     FILE:/tmp/krb5cc_0


 


STOP SERVICES


/etc/init.d/winbind stop


/etc/init.d/samba stop


update-rc.d winbind remove


update-rc.d samba remove


 


export KRB5_KTNAME=FILE:/etc/squid3/HTTP.keytab


 


INSTALL OF SQUID3: apt-get install squid3


 


export KRB5_KTNAME=FILE:/etc/squid3/HTTP.keytab


net ads keytab CREATE


net ads keytab ADD HTTP


unset KRB5_KTNAME


 


chgrp proxy /etc/squid3/HTTP.keytab 


chmod g+r /etc/squid3/HTTP.keytab 


 


/etc/init.d/squid3 restart


 


KRB5_KTNAME=/etc/squid3/HTTP.keytab


export KRB5_KTNAME


KRB5RCACHETYPE=none


export KRB5RCACHETYPE


 


/etc/init.d/squid3 restart


 


 


Below are my configuration files:


 


1) /etc/krb5.conf


[libdefaults]


   default_realm = EMPRESA.COM.BR


   dns_lookup_kdc = no


       dns_lookup_realm = no


       default_keytab_name = /etc/krb5.keytab


 


[realms]


   EMPRESA.COM.BR = {


   kdc = dc1.EMPRESA.COM.BR:88


   admin_server = dc1.EMPRESA.COM.BR


   default_domain = EMPRESA.COM.BR 


   }


 


 


[domain_realm]


   .EMPRESA.COM.BR = EMPRESA.COM.BR


   EMPRESA.COM.BR = EMPRESA.COM.BR


 


[logging]


  kdc = FILE:/var/log/kdc.log


  admin_server = FILE:/var/log/kadmin.log


  default = FILE:/var/log/krb5lib.log


 


2/etc/samba/smb.conf


[global]


  netbios name = proxy 


  workgroup = EMPRESA


  security = ads 


  realm = EMPRESA.COM.BR 


  encrypt passwords = yes


  dedicated keytab file = /etc/krb5.keytab


  kerberos method = secrets and keytab


# password server = dc1.empresa.com.br


  preferred master = no


  idmap config *:backend = tdb


  idmap config *:range = 1000-3000


  idmap config EMPRESA:backend = ad


  idmap config EMPRESA:schema_mode = rfc2307


  idmap config EMPRESA:range = 1-999


 


  winbind nss info = rfc2307


  winbind trusted domains only = no


  winbind use default domain = yes


  winbind enum users = yes


  winbind enum groups = yes


  winbind offline logon = yes


  

Re: [squid-users] Checking SSL bump status in http_access

[Alex Rousskov]

On 08/18/2016 08:54 AM, Alex Rousskov wrote:
> 1. Supported: HTTP request (including fake CONNECTs);

To clarify, s/fake CONNECTs/a single fake CONNECT/

> 2. Supported: Client connection;

> 3. Proposed:  Compound transaction (e.g., all authenticatING requests
> plus the first authenticatED request that follows them; all fake
> CONNECTs plus the first bumped HTTP request that follows them).

Alex.

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

Re: [squid-users] Checking SSL bump status in http_access

[Alex Rousskov]

On 08/18/2016 03:18 AM, Steve Hill wrote:
> On 17/08/16 17:18, Alex Rousskov wrote:
>> This configuration problem should be at least partially addressed by the
>> upcoming annotate_transaction ACLs inserted into ssl_bump rules:
>> http://lists.squid-cache.org/pipermail/squid-dev/2016-July/006146.html

> http://bugs.squid-cache.org/show_bug.cgi?id=4340#c3
> any notes set by an external ACL when
> processing the ssl_bump ACL during step 1 are discarded when handling
> transparent connections.

Annotations lifetime is a different problem IMO. If somebody needs
[more] connection annotations, they should extend existing clt_conn_tag
support to arbitrary key=value pairs, probably by adding a configuration
option that names connection-scope keys.

If somebody needs a third annotation lifetime scope, they should propose
to add support for it. For example:

1. Supported: HTTP request (including fake CONNECTs);
2. Supported: Client connection;
3. Proposed:  Compound transaction (e.g., all authenticatING requests
plus the first authenticatED request that follows them; all fake
CONNECTs plus the first bumped HTTP request that follows them).

Needless to say, compelling use cases must be presented to justify this
addition/complication along with a firm definition of which individual
transactions belong to the new scope, keeping the "HTTP is stateless"
mantra in mind.


> It would greatly reduce the functionality
> of your proposed ACLs if the annotations were sometimes discarded part
> way through a connection or request.

This is a separate issue, but annotations set by annotate_client ACL
will persist for the client connection lifetime and annotations set by
annotate_transaction ACL will persist for the transaction lifetime
(e.g., a single fake CONNECT request). See above if you need a
different/new lifetime scope. I recommend avoiding the term "request"
for labeling that new scope even if it is convenient for you to think of
all fake CONNECT requests as a single request.


> Something I've been wanting to do for a while is attach a unique
> "connection ID" and "request ID" to requests

Yes, we already do that (in clients and servers) for testing purposes.
And some adaptation services do that to match responses with requests,
as you have mentioned. Adding that support to Squid would be a useful
feature. Official support must account for SMP needs and restarts, but
it is certainly doable.


Cheers,

Alex.

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

Re: [squid-users] HTTPS - THE PROXY SERVER IS REFUSING CONNECTIONS

[L . P . H . van Belle]

That you proxy refused you connections is correct. 

You forgot to define an acl and allow it.  

Something like : 
acl internal-net 192.168.x.0/.24 

and 
> http_access allow localhost
http_access allow internal-net
> http_access deny all

Greetz, 

Louis


> -Oorspronkelijk bericht-
> Van: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] Namens
> adeg...@gmail.com
> Verzonden: donderdag 18 augustus 2016 15:56
> Aan: squid-users@lists.squid-cache.org
> Onderwerp: [squid-users] HTTPS - THE PROXY SERVER IS REFUSING CONNECTIONS
> Urgentie: Hoog
> 
> Hello,
> 
> My request concerns SQUID v.3.4.8
> I'm using :
>  - DEBIAN Jessie
>  - Firefox 48.0
>  - simple home network
> 
> Actually, I whitelist some http(s) domains with SQUID.
> 
> My problem is :
> when I want to go with firefox to any httpS domain which is not
> whitelisted,
> I obtain this error message : "THE PROXY SERVER IS REFUSING CONNECTIONS"
> (example :
> "https://www.pntbrother.com/wp-
> content/uploads/2014/11/proxy_server_refusing
> _connection.jpg ")
> And I have to find a solution for showing the usual HTML error page from
> SQUID (the page I can custom, example : "
> http://cdn.krizna.com/wp-
> content/uploads/2012/08/squid_proxy_server_block.jp
> g ")
> 
> 
> Here is my "squid.conf" :
> acl whitelist_prim dstdomain "/etc/squid3/whitelist_primaire"
> 
> acl SSL_ports port 443
> acl Safe_ports port 80  # http
> acl Safe_ports port 21  # ftp
> acl Safe_ports port 443 # https
> acl Safe_ports port 70  # gopher
> acl Safe_ports port 210 # wais
> acl Safe_ports port 1025-65535  # unregistered ports
> acl Safe_ports port 280 # http-mgmt
> acl Safe_ports port 488 # gss-http
> acl Safe_ports port 591 # filemaker
> acl Safe_ports port 777 # multiling http
> acl CONNECT method CONNECT
> 
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow localhost manager
> http_access deny manager
> 
> http_access allow whitelist_prim
> 
> http_access allow localhost

> http_access deny all
> http_port 3128
> coredump_dir /var/spool/squid3
> refresh_pattern ^ftp:   144020% 10080
> refresh_pattern ^gopher:14400%  1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0%  0
> refresh_pattern .   0   20% 4320
> 
> 
> 
> Here is my " whitelist_primaire" file :
> .google.com
> .google.fr
> .bing.com
> .ubuntuforums.org
> .squid-cache.org
> .facebook.com
> 
> Here is the result of " sudo tail -f /var/log/squid3/access.log " for this
> url https://www.waze.com :
> 1471512108.462  1 192.168.0.14 TCP_DENIED/403 3628 CONNECT
> www.waze.com:443 - HIER_NONE/- text/html
> 
> 
> I already try "deny_info" ( there
> :http://digitizor.com/how-to-change-the-default-error-document-pages-in-
> squi
> d/ ), but without success.
> 
> Is it possible to have a solution (with simple solution : ACLs...) for
> httpS
> domains ?
> 
> Any advice will be appreciated.
> 
> 
> ___
> 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] Rock store status

[Steve Hill]

On 17/08/16 11:50, FredB wrote:


I tried rock store and smp long time ago (squid 3.2 I guess), Unfortunately I 
definitely drop smp because there are some limitations (In my case), and I 
fall-back to diskd because there were many bugs with rock store. FI I also 
switched to aufs without big differences.

But now with the latest 3.5.20 ? Sadly SMP still not for me but rock store ?

There is someone who are using rock store with a high load, more than 800 r/s, 
without any problem ? There is a real difference in this situation, cpu, speed, 
memory ?


We use SMP and Rock under the 3.5 series without problems.  But I don't 
think any of our sites have as high req/sec load as you.


--
 - Steve Hill
   Technical Director
   OpendiumOnline Safety / Web Filteringhttp://www.opendium.com

   Enquiries Support
   - ---
   sa...@opendium.comsupp...@opendium.com
   +44-1792-824568   +44-1792-825748
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Checking SSL bump status in http_access

[Steve Hill]

On 17/08/16 00:12, Amos Jeffries wrote:


Is there a way of figuring out if the current request is a bumped
request when the http_access ACL is being checked?  i.e. can we tell the
difference between a GET request that is inside a bumped tunnel, and an
unencrypted GET request?


In Squid-3 a combo of the myportname and proto ACLs should do that.


I think when using a nontransparent proxy you can't tell the difference 
between:


1. HTTPS requests inside a bumped CONNECT tunnel, and
2. unencrypted "GET https://example.com/ HTTP/1.1" requests made 
directly to the proxy.



--
 - Steve Hill
   Technical Director
   OpendiumOnline Safety / Web Filteringhttp://www.opendium.com

   Enquiries Support
   - ---
   sa...@opendium.comsupp...@opendium.com
   +44-1792-824568   +44-1792-825748
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Yet another store_id question HIT MISS

[Omid Kosari]

I was correct .

If one of following conditions happens then the mentioned urls will not
cache .

1-in squid.conf have this line
acl storeiddomainregex dstdom_regex
^igcdn(\-photos|\-videos)[a-z0-9\-]{0,9}\.akamaihd\.net$ 

2-in storeid_db have this line
^http:\/\/igcdn-.*\.akamaihd\.net/hphotos-ak-.*/(t5.*?)(?:\?|$)
http://instagramcdn.squid.internal/$1

IF 1 OR 2 THEN 
http://igcdn-photos-h-a.akamaihd.net/hphotos-ak-xap1/t51.2885-15/s640x640/sh0.08/e35/13702999_1008425479275495_76276919_n.jpg
will not cache at all even if we open that url for many times .

But if i remove 1 and 2 then the url will be cached .

My first email was incorrect because i realized that first url is hit but
second miss . The hit was from before store_id rules added .

Now the problem is with my mentioned squid.conf and store_id rules , the
mentioned urls will not cache at all.Even if same url reopens many times .

Thanks



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Yet-another-store-id-question-HIT-MISS-tp4678972p4679025.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] FTP access with proxy_auth

[Claudio Ninin]

Hi,

I need a help.
I'm trying configure to allow ftp acces across squid with the proxy_auth,
but when try access some ftp the squid doesn't get authentication.
This is my ACL:
#
### ACLs de liberacao do ftp
#
#acl usu-ftp src "/etc/squid/ips-ftp.cfg"
acl usu-ftp proxy_auth -i "/etc/squid/usu_ftp.cfg"
ftp_passive on
http_access allow ftp usu-ftp all
http_access allow CONNECT ftp_port usu-ftp all
http_access deny ftp

[image: Imagem inline 1]

[image: Imagem inline 2]

Can you help me?

Best regards,

Cláudio Benelli Ninin
Analista de TI
Telefone: +55 16 3942-2106
Celular: +55 16 98824-2706
E-mail: cbni...@gmail.com
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Yet another store_id question HIT MISS

[Omid Kosari]

Simply open following url in firefox
http://igcdn-photos-h-a.akamaihd.net/hphotos-ak-xap1/t51.2885-15/s640x640/sh0.08/e35/13702999_1008425479275495_76276919_n.jpg

then rename h to a,b,c,d,e,f for example

http://igcdn-photos-a-a.akamaihd.net/hphotos-ak-xap1/t51.2885-15/s640x640/sh0.08/e35/13702999_1008425479275495_76276919_n.jpg

According to my store_id rules it should be hit but it is not .

Even i am uncertain about if we open same exact url 2 times , is it hit in
second time ?



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Yet-another-store-id-question-HIT-MISS-tp4678972p4679021.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Malformed HTTP on tproxy squid

[Omid Kosari]

Amos Jeffries wrote
> About the only thing you could do to speed it up is locate the error
> page templates (file paths: en/ERR_INVALID_REQ and
> templates/ERR_INVALID_REQ) and remove their contents. Then restart Squid.
> That should remove at least a few of the vprintf() syscalls that your
> earlier trace showed as being a significant source of CPU load.

Fine. This resolved the problem .
Thanks


samples  %image name   symbol name
190728   34.3901  squid/usr/sbin/squid
26003 4.6886  r8169/r8169
22958 4.1396  libc-2.23.so _int_malloc
13812 2.4904  nf_conntrack /nf_conntrack
11146 2.0097  libc-2.23.so re_search_internal
11044 1.9913  libc-2.23.so _int_free
8748  1.5774  libstdc++.so.6.0.21 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7240  1.3054  reiserfs /reiserfs
6087  1.0975  libc-2.23.so malloc_consolidate
5850  1.0548  libc-2.23.so malloc
4840  0.8727  libc-2.23.so vfprintf
4468  0.8056  ip_tables/ip_tables
4423  0.7975  libm-2.23.so __ieee754_log_avx
4364  0.7869  libc-2.23.so __memcpy_sse2_unaligned
3935  0.7095  kallsyms sys_epoll_ctl
3929  0.7084  libc-2.23.so free
3829  0.6904  libc-2.23.so build_upper_buffer
3562  0.6423  kallsyms __fget
3413  0.6154  kallsyms copy_user_generic_string
3169  0.5714  libc-2.23.so calloc
2815  0.5076  kallsyms delay_tsc
2767  0.4989  kallsyms csum_partial_copy_generic
2739  0.4939  kallsyms tcp_sendmsg
2454  0.4425  kallsyms memcpy
2192  0.3952  libc-2.23.so _wordcopy_fwd_dest_aligned
2139  0.3857  kallsyms _raw_spin_lock_irqsave
2108  0.3801  kallsyms _raw_spin_lock
2075  0.3741  kallsyms nf_iterate
1916  0.3455  libc-2.23.so __memset_sse2
1900  0.3426  [vdso] (tgid:12101 range:0x7fff9fbca000-0x7fff9fbcbfff)
[vdso] (tgid:12101 range:0x7fff9fbca000-0x7fff9fbcbfff
)
1842  0.3321  libc-2.23.so __strcmp_sse2_unaligned
1794  0.3235  kallsyms sock_poll
1753  0.3161  libc-2.23.so strlen
1702  0.3069  kallsyms entry_SYSCALL_64_after_swapgs
1618  0.2917  kallsyms tcp_poll
1611  0.2905  kallsyms irq_entries_start
1593  0.2872  kallsyms ep_send_events_proc
1567  0.2825  kallsyms ___slab_alloc
1539  0.2775  kallsyms __local_bh_enable_ip
1523  0.2746  nf_conntrack_ipv4/nf_conntrack_ipv4
1467  0.2645  libc-2.23.so re_string_reconstruct
1455  0.2624  kallsyms tcp_transmit_skb
1425  0.2569  nf_nat_ipv4  /nf_nat_ipv4
1366  0.2463  kallsyms _raw_spin_lock_bh
1333  0.2404  kallsyms __alloc_skb
1319  0.2378  kallsyms mutex_spin_on_owner.isra.3
1313  0.2367  kallsyms tcp_recvmsg
1307  0.2357  kallsyms tcp_write_xmit
1279  0.2306  kallsyms __fget_light
1266  0.2283  libc-2.23.so __memmove_sse2
1234  0.2225  libnettle.so.6.2
/usr/lib/x86_64-linux-gnu/libnettle.so.6.2
1202  0.2167  kallsyms __inet_lookup_established
1177  0.2122  kallsyms __lock_text_start
1116  0.2012  kallsyms common_file_perm
1080  0.1947  kallsyms tcp_ack
1075  0.1938  kallsyms tcp_clean_rtx_queue
1046  0.1886  kallsyms tcp_v4_rcv





--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Malformed-HTTP-on-tproxy-squid-tp4678951p4679009.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Checking SSL bump status in http_access

[Steve Hill]

On 17/08/16 17:18, Alex Rousskov wrote:


This configuration problem should be at least partially addressed by the
upcoming annotate_transaction ACLs inserted into ssl_bump rules:
http://lists.squid-cache.org/pipermail/squid-dev/2016-July/006146.html


That looks good.  When implementing this, beware the note in comment 3 
of bug 4340: http://bugs.squid-cache.org/show_bug.cgi?id=4340#c3
"for transparent connections, the NotePairs instance used during the 
step-1 ssl_bump ACL is not the same as the instance used during the 
http_access ACL, but for non-transparent connections they are the same 
instance.  The upshot is that any notes set by an external ACL when 
processing the ssl_bump ACL during step 1 are discarded when handling 
transparent connections."  - It would greatly reduce the functionality 
of your proposed ACLs if the annotations were sometimes discarded part 
way through a connection or request.


Something I've been wanting to do for a while is attach a unique 
"connection ID" and "request ID" to requests so that:
1. An ICAP server can make decisions about the connection (e.g. how to 
authenticate, whether to bump, etc.) and then refer back to the data it 
knows/generated about the connection when it processes the requests 
contained within that connection.
2. When multiple ICAP requests will be generated, they can be linked 
together by the ICAP server - e.g. where a single request will generate 
a REQMOD followed by a RESPMOD it would be good for the ICAP server to 
know which REQMOD and RESPMOD relate to the same request.


It sounds like your annotations plan may address this to some extent. 
(We can probably already do some of this by having the ICAP server 
generate unique IDs and store them in ICAP headers to be passed along 
with the request, but I think the bug mentioned above would cause those 
headers to be discarded mid-request in some cases)


--
 - Steve Hill
   Technical Director
   OpendiumOnline Safety / Web Filteringhttp://www.opendium.com

   Enquiries Support
   - ---
   sa...@opendium.comsupp...@opendium.com
   +44-1792-824568   +44-1792-825748
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users