[squid-users] squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

[David Touzeau]

Hi we want to use squid as * * * Secure Proxy * * * using https_port
We have tested major browsers and it seems working good.

To make it work, we need to deploy the proxy certificate on all browsers 
to make the secure connection running.


In this case, squid forward requests without decrypting them.because 
ssl-bump is not added.


But Adding the ssl-bump in https_port is not permitted :

"sl-bump on https_port requires tproxy/intercept which is missing"

why bumping is not allowed ?

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

[squid-users] Squid with connmark

[Turnbull, John]

What is the best way to intercept marked packets with squid and squid to be 
aware of mark and create an ACL on the mark?

I have tried setting the mark and then DNAT and redirect  to the intercept port 
and when printing the nmark I am getting 0

Is it required to use tproxy with tproxy-mark?

Thanks,

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

[squid-users] Dumping sslbump'd decrytped http using icap protocol

[Scott]

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

Re: [squid-users] Squid 4.x acl server_cert_fingerprint for bump no matches

[David Touzeau]

Thanks alex, made this one on squid 4.10


acl TestFinger server_cert_fingerprint 
77:F6:8D:C1:0A:DF:94:8B:43:1F:8E:0E:91:5E:0C:32:42:8B:99:C9

acl ssl_step1 at_step SslBump1
acl ssl_step2 at_step SslBump2
acl ssl_step3 at_step SslBump3
ssl_bump peek ssl_step2
ssl_bump splice ssl_step3 TestFinger
ssl_bump stare ssl_step2 all
ssl_bump bump all

But no luck, website still decrypted.




Le 13/05/2020 à 21:33, Alex Rousskov a écrit :

On 5/12/20 7:42 AM, David Touzeau wrote:

ssl_bump peek ssl_step1
ssl_bump splice TestFinger
ssl_bump stare ssl_step2 all
ssl_bump bump all
Seems TestFinger Acls did not matches in any case

You are trying to use step3 information (i.e., the server certificate)
during SslBump step2: The "splice TestFinger" line is tested during
step2 and mismatches because the server certificate is still unknown
during that step. That mismatch results in Squid staring during step2.
The "splice TestFinger" line is not tested during step3 because splicing
is not possible after staring. Thus, Squid reaches "bump all" and bumps.

For a detailed description of what happens (and what information is
available) during each SslBump step, please see
https://wiki.squid-cache.org/Features/SslPeekAndSplice

Also, if you are running v4.9 or earlier, please upgrade. We fixed one
server_cert_fingerprint bug, and that fix became a part of the v4.10
release (commit e0eca4c).


HTH,

Alex.


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

Re: [squid-users] Client IP PTR lookup on connect

[Amos Jeffries]

On 14/05/20 1:44 am, Michal Bruncko wrote:
> Hello guys
> 
> following the original thread "[squid-users] Squid 4.9 Client IP PTR
> lookup on connect"
> 
> I am observing exactly same bahavour on
> squid-4.4-8.module_el8.1.0+197+0c39cdc8.x86_64 on CentOS 8.

Certainly 4.4 is older than 4.9.


> At first I was suspecting some squid module (auth helper
> (gssapi/ntlm/basic), URL rewriter) or syslog (which we use for sending
> access logs to remote server) but those DNS queries are coming directly
> from squid process (same as the one doing standard forward DNS lookups).

The URL-rewriter input includes the rDNS name of the client IP. I expect
your Squid is trying to fetch that information to send the re-writer.


> write(16,
> "http://i5.c.eset.com/v1/auth/851A4855CEEAB5292C10/updlist/0/eid/7033368/lid/7033484
> 2001:4118:804:f000::103/2001:4118:804:f000::"..., 179) = 179

If that information is not actually needed by your re-writer, then
configure the url_rewrite_extras directive to alter what gets sent.


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

Re: [squid-users] Squid 4.x acl server_cert_fingerprint for bump no matches

[Amos Jeffries]

On 15/05/20 7:28 pm, David Touzeau wrote:
> 
> Thanks alex, made this one on squid 4.10
> 
> 
> acl TestFinger server_cert_fingerprint
> 77:F6:8D:C1:0A:DF:94:8B:43:1F:8E:0E:91:5E:0C:32:42:8B:99:C9

Is that a SHA1 fingerprint or a newer algorithm?

AFAIK only SHA1 is supported by Squid currently.

Also, it is matched against what the server SSL certificate contains. So
that has to be a SHA1 fingerprint as well.

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

Re: [squid-users] squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

[Amos Jeffries]

On 18/05/20 10:15 am, David Touzeau wrote:
>   
> 
> Hi we want to use squid as * * * Secure Proxy * * * using https_port
> We have tested major browsers and it seems working good.
> 
> To make it work, we need to deploy the proxy certificate on all browsers
> to make the secure connection running.
> 
> In this case, squid forward requests without decrypting them.because
> ssl-bump is not added.
> 
> But Adding the ssl-bump in https_port is not permitted :
> 
> "sl-bump on https_port requires tproxy/intercept which is missing"
> 
> why bumping is not allowed ?
> 

Because origin server and explicit proxy traffic are mutually exclusive
syntax at the HTTP level, and use different types of SSL certificate at
the TLS level.

A "Secure proxy" receives explicit-proxy HTTP traffic over TLS. That
traffic gets decrypted normally on receipt by the https_port, using a
proxy server certificate.

SSL-Bump auto-generates a server certificate to decrypt with, and
expects origin form HTTP syntax once decrypted.


HTTPS traffic as we know it (CONNECT tunnels to port 443) might still be
sent to a secure proxy. In which case there are two layers of encryption
nested inside each other. Decrypting the interior layer of at is not yet
supported by Squid.


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

Re: [squid-users] "intercepted port does not match 443"

[Amos Jeffries]

On 12/05/20 1:01 am, Matus UHLAR - fantomas wrote:
> Hello,
> 
> we have intercepting squid on one router and these messages started appear
> sometimes:
> 
> 2020/05/11 13:41:23 kid1| SECURITY ALERT: Host header forgery detected
> on local=[XXX]:80 remote=192.168.1.224:1040 FD 69 flags=33 (intercepted
> port does not match 443)
> 2020/05/11 13:41:23 kid1| SECURITY ALERT: By user agent: Microsoft BITS/6.7
> 2020/05/11 13:41:23 kid1| SECURITY ALERT: on URL: armmf.adobe.com:443
> 2020/05/11 13:41:23 kid1| kick abandoning local=[XXX]:80
> remote=192.168.1.224:1040 FD 69 flags=33
> 
> I am aware of possible interception issues but what exactly does this
> message mean?  The original destination port is 80, why does squid complain
> about it not being port 443?

The HTTP Host header says the client was connecting to a server on port
443. Yet the TCP packets came, as you say from port 80.


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

Re: [squid-users] Client IP PTR lookup on connect

[Michal Bruncko]

Hi Amos

thank you for very valuable response. I can confirm that amending 
default url_rewrite_extras value did the trick!


thanks
michal

On 5/17/2020 12:36 PM, Amos Jeffries wrote:

On 14/05/20 1:44 am, Michal Bruncko wrote:

Hello guys

following the original thread "[squid-users] Squid 4.9 Client IP PTR
lookup on connect"

I am observing exactly same bahavour on
squid-4.4-8.module_el8.1.0+197+0c39cdc8.x86_64 on CentOS 8.

Certainly 4.4 is older than 4.9.



At first I was suspecting some squid module (auth helper
(gssapi/ntlm/basic), URL rewriter) or syslog (which we use for sending
access logs to remote server) but those DNS queries are coming directly
from squid process (same as the one doing standard forward DNS lookups).

The URL-rewriter input includes the rDNS name of the client IP. I expect
your Squid is trying to fetch that information to send the re-writer.



write(16,
"http://i5.c.eset.com/v1/auth/851A4855CEEAB5292C10/updlist/0/eid/7033368/lid/7033484
2001:4118:804:f000::103/2001:4118:804:f000::"..., 179) = 179

If that information is not actually needed by your re-writer, then
configure the url_rewrite_extras directive to alter what gets sent.


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

Re: [squid-users] squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

[Matus UHLAR - fantomas]

On 18/05/20 10:15 am, David Touzeau wrote:

Hi we want to use squid as * * * Secure Proxy * * * using https_port
We have tested major browsers and it seems working good.

To make it work, we need to deploy the proxy certificate on all browsers
to make the secure connection running.

In this case, squid forward requests without decrypting them.because
ssl-bump is not added.

But Adding the ssl-bump in https_port is not permitted :

"sl-bump on https_port requires tproxy/intercept which is missing"

why bumping is not allowed ?


On 19.05.20 23:15, Amos Jeffries wrote:

Because origin server and explicit proxy traffic are mutually exclusive
syntax at the HTTP level, and use different types of SSL certificate at
the TLS level.

A "Secure proxy" receives explicit-proxy HTTP traffic over TLS. That
traffic gets decrypted normally on receipt by the https_port, using a
proxy server certificate.

SSL-Bump auto-generates a server certificate to decrypt with, and
expects origin form HTTP syntax once decrypted.


David, note that requiring browsers to connect to your proxy over encrypted
(https) connection, and then decrypting tunnels to real server will lower
the clients' security:
Clients will talk HTTPS to proxy, but proxy to server connection might be as
well unencrypted (or, decrypted by proxy).
This makes thinge like SSL authentication impossible.
I understand that you might scan connections for viruses or disabled
content, but the security will be harmed.


HTTPS traffic as we know it (CONNECT tunnels to port 443) might still be
sent to a secure proxy. In which case there are two layers of encryption
nested inside each other. Decrypting the interior layer of at is not yet
supported by Squid.


so, this is the real problem :-)


--
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.
42.7 percent of all statistics are made up on the spot.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

[Alex Rousskov]

>> On 18/05/20 10:15 am, David Touzeau wrote:
>>> Hi we want to use squid as * * * Secure Proxy * * * using https_port
>>> We have tested major browsers and it seems working good.
>>>
>>> To make it work, we need to deploy the proxy certificate on all browsers
>>> to make the secure connection running.

I hope that deployment is not necessary -- an HTTPS proxy should be
using a certificate issued for its domain name and signed by a
well-known CA already trusted by browsers. An HTTPS proxy is not faking
anything. If browsers do require CA certificate import in this
environment, it is their limitation.


On 5/19/20 9:24 AM, Matus UHLAR - fantomas wrote:
> David, note that requiring browsers to connect to your proxy over encrypted
> (https) connection, and then decrypting tunnels to real server will lower
> the clients' security

A proper SslBump implementation for HTTPS proxy will not be "decrypting
tunnels to real server". The security of such an implementation will be
the same as of SslBump supported today (plus the additional protections
offered by securing the browser-proxy communication).

Cheers,

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

Re: [squid-users] Squid 4.x acl server_cert_fingerprint for bump no matches

[Alex Rousskov]

On 5/15/20 3:28 AM, David Touzeau wrote:

> acl TestFinger server_cert_fingerprint 
> 77:F6:8D:C1:0A:DF:94:8B:43:1F:8E:0E:91:5E:0C:32:42:8B:99:C9
> ssl_bump peek ssl_step2
> ssl_bump splice ssl_step3 TestFinger
> ssl_bump stare ssl_step2 all
> ssl_bump bump all

> But no luck, website still decrypted.

That should be expected: During step1, the only ssl_bump rule that
matches now is ... "bump all".

Also, you have two ssl_step2 rules but only the first one can match.
Perhaps the first one has a typo, and you meant to put ssl_step1 there?


Amos is correct that Squid uses SHA1. So does my openssl x509 (by
default). However, FWIW, I get a different SHA1 fingerprint when I run
your command:

> openssl s_client -host www.clubic.com -port 443 2> /dev/null | openssl x509 
> -fingerprint -noout
> SHA1 Fingerprint=2A:F4:A6:8E:31:15:AD:A5:52:A9:5F:03:80:42:BE:CA:01:12:2C:E7

Perhaps www.clubic.com uses different certificates for different clients.


HTH,

Alex.


> Le 13/05/2020 à 21:33, Alex Rousskov a écrit :
>> On 5/12/20 7:42 AM, David Touzeau wrote:
>>> ssl_bump peek ssl_step1
>>> ssl_bump splice TestFinger
>>> ssl_bump stare ssl_step2 all
>>> ssl_bump bump all
>>> Seems TestFinger Acls did not matches in any case
>> You are trying to use step3 information (i.e., the server certificate)
>> during SslBump step2: The "splice TestFinger" line is tested during
>> step2 and mismatches because the server certificate is still unknown
>> during that step. That mismatch results in Squid staring during step2.
>> The "splice TestFinger" line is not tested during step3 because splicing
>> is not possible after staring. Thus, Squid reaches "bump all" and bumps.
>>
>> For a detailed description of what happens (and what information is
>> available) during each SslBump step, please see
>> https://wiki.squid-cache.org/Features/SslPeekAndSplice
>>
>> Also, if you are running v4.9 or earlier, please upgrade. We fixed one
>> server_cert_fingerprint bug, and that fix became a part of the v4.10
>> release (commit e0eca4c).
>>
>>
>> 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] squid 4.10: ssl-bump on https_port requires tproxy/intercept which is missing in secure proxy method

[Alex Rousskov]

On 5/19/20 7:15 AM, Amos Jeffries wrote:
> On 18/05/20 10:15 am, David Touzeau wrote:
>>   
>>
>> Hi we want to use squid as * * * Secure Proxy * * * using https_port
>> We have tested major browsers and it seems working good.
>>
>> To make it work, we need to deploy the proxy certificate on all browsers
>> to make the secure connection running.
>>
>> In this case, squid forward requests without decrypting them.because
>> ssl-bump is not added.
>>
>> But Adding the ssl-bump in https_port is not permitted :
>>
>> "sl-bump on https_port requires tproxy/intercept which is missing"
>>
>> why bumping is not allowed ?
>>
> 
> Because origin server and explicit proxy traffic are mutually exclusive
> syntax at the HTTP level, and use different types of SSL certificate at
> the TLS level.
> 
> A "Secure proxy" receives explicit-proxy HTTP traffic over TLS. That
> traffic gets decrypted normally on receipt by the https_port, using a
> proxy server certificate.
> 
> SSL-Bump auto-generates a server certificate to decrypt with, and
> expects origin form HTTP syntax once decrypted.
> 
> 
> HTTPS traffic as we know it (CONNECT tunnels to port 443) might still be
> sent to a secure proxy. In which case there are two layers of encryption
> nested inside each other. Decrypting the interior layer of at is not yet
> supported by Squid.


David,

Just to avoid misunderstanding: The answer to your question is in
the last sentence of the last paragraph by Amos -- Squid lacks the code
that is necessary to do what you want. There are no fundamental reasons
it cannot be done. There have been a few requests for TLS-inside-TLS
support, but I am not aware of any actual sponsors or features on the
road map. It is a complicated project, even though each of its two
components already works today.


Cheers,

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

[squid-users] Sending CONNECT method requests over HTTPS

[Ronan Lucio]

Hi all,

I read a similar thread a couple of weeks ago, but my scenario has
some differences.
Anyway, my need is sending CONNECT method requests over HTTPS as well.

If read the docs and just would like to confirm with you if I got it right:

1)
To send CONNECT method requests over HTTPS I'm supposed to use https_port.
May I use it on the same way as http_port (without intercept, proxy,
or accelerate)?

2)
If I need to apply ACL rules to restrict some destinations, I'm
supposed to use bump_ssl.

Is it right?

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

Re: [squid-users] Squid with QOS marking

[Ahmad Alzaeem]

Following :

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


Based on it we need kernel patch for TOS , but I dont need TOS ,  I just need 
Layer 3 DSP , Linux mark rule based .


Thanks 


> On May 20, 2020, at 1:19 AM, Ahmad Alzaeem <0xf...@gmail.com> wrote:
> 
> Hello Folks ,
> 
> Im trying to mark outgoing squid request based on Mark linux matching .
> 
> I added to squid conf :
> 
> qos_flows mark local-hit=0xd7
> qos_flows mark local-miss=0xd7
> 
> -A OUTPUT -m mark --mark 0xd7 -j ACCEPT
> 
> But on iptables there is no match with the mark d7 
> 
> 
> Im testing  marking with squid and matching with iptables  but its not 
> matching , always statistics = 0 on linux iptables  That mean  its not 
> matched .
> 
> Squid version is 4.8
> Also squid was complied with '--enable-zph-qos’ flag 
> 
> So not sure if I need specific config for squid .
> 
> Thanks 
> ___
> 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

[squid-users] Squid with QOS marking

[Ahmad Alzaeem]

Hello Folks ,

Im trying to mark outgoing squid request based on Mark linux matching .

I added to squid conf :

qos_flows mark local-hit=0xd7
qos_flows mark local-miss=0xd7

-A OUTPUT -m mark --mark 0xd7 -j ACCEPT

But on iptables there is no match with the mark d7 


Im testing  marking with squid and matching with iptables  but its not matching 
, always statistics = 0 on linux iptables  That mean  its not matched .

Squid version is 4.8
Also squid was complied with '--enable-zph-qos’ flag 

So not sure if I need specific config for squid .

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