Re: [squid-users] after changed from 3.4.13 to 3.5.8 sslbump doesn't work for the site https://banking.postbank.de/

[Dieter Bloms]

Hello Amos,

thank you for your hints.

On Thu, Sep 17, Amos Jeffries wrote:

> > the relevant part ist:
> > 
> > --snip--
> > acl nodecryptdomains dstdomain "/etc/squid/nodecrypt.domains"
> > http_port MYIP:8080 ssl-bump cert=/etc/squid/ca.pem key=/etc/squid/ca.key 
> > generate-host-certificates=on dhparams=/etc/squid/dhparams.pem
> 
> 
> Replace these...
> 
> > ssl_bump none nodecryptdomains
> > ssl_bump server-first all
> 
> ... with:
> 
>  acl nodecrypt ssl::server_name "/etc/squid/nodecrypt.domains"
>  acl step1 at_step SslBump1
>  ssl_bump peek step1
>  ssl_bump splice nodecrypt
>  ssl_bump bump all
> 
> Maybe also remove the nodecryptdomains ACL. Depends on whether you use
> it anywhere else.

I've changed my config, but same results.
SSLBump works so far, only the site banking.postbank.de makes trouble.
My chrome browser says "ERR_CONNECTION_CLOSED" and in the squid log
looks like:

--snip--
1442473894.771 49 10.252.16.100 TAG_NONE/200 0 CONNECT 
banking.postbank.de:443 - HIER_DIRECT/62.153.105.15 -
1442473894.832 49 10.252.16.100 TAG_NONE/200 0 CONNECT 
banking.postbank.de:443 - HIER_DIRECT/62.153.105.15 -
1442473895.074 48 10.252.16.100 TAG_NONE/200 0 CONNECT 
banking.postbank.de:443 - HIER_DIRECT/62.153.105.15 -
1442473895.134 47 10.252.16.100 TAG_NONE/200 0 CONNECT 
banking.postbank.de:443 - HIER_DIRECT/62.153.105.15 -
1442473895.193 45 10.252.16.100 TAG_NONE/200 0 CONNECT 
banking.postbank.de:443 - HIER_DIRECT/62.153.105.15 -
--snip--


here the ssl relevant part of my squid.conf
--snip--
http_port MYIP:8080 ssl-bump cert=/etc/squid/ca.pem key=/etc/squid/ca.key 
generate-host-certificates=on dhparams=/etc/squid/dhparams.pem
ssl_bump peek step1
ssl_bump bump all
sslproxy_capath /etc/ssl/certs
sslproxy_options NO_SSLv2:NO_SSLv3:ALL
sslproxy_cipher 
ALL:!SSLv2:!ADH:!DSS:!MD5:!EXP:!DES:!PSK:!SRP:!RC4:!IDEA:!SEED:!aNULL:!eNULL
--snip--

so it would be nice, if anybody with enabled sslbump on squid3.5.8 can
do a GET Request to https://banking.postbank.de/ to see if that works.


-- 
Regards

  Dieter

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

Re: [squid-users] build error with kernel headers 4.2

[Eray Aslan]

On Thu, Sep 17, 2015 at 05:24:10AM +, Eray Aslan wrote:
> I am getting a bunch of build errors with kernel headers 4.2:

Nevermind, found bug #4323.  Sorry for the noise.

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

Re: [squid-users] help with acl order and deny_info pages

[Marko Cupać]

On Thu, 17 Sep 2015 03:00:56 +1200
Amos Jeffries  wrote:

> On 17/09/2015 12:37 a.m., Marko Cupać wrote:
> > Hi,
> > 
> > I'm trying to setup squid in a way that it authenticates users via
> > kerberos and grants different levels of web access according to ldap
> > query of MS AD groups.After some trials and errors I have found acl
> > order which apparently does not trigger reauthentication (auth
> > dialogues in browsers although I don't even provide basic auth).
> 
> What makes you think browser dialog box has anything to do with Basic
> auth? All it means is that the browser does not know what credentials
> will work. The ones tried (if any) have been rejected with a challenge
> response (401/407) for valid ones. It may be the browser password
> manager.
> 
> If you are using only Kerberos auth then users enter their Kerberos
> username and password into the dialog to allow the browser to fetch
> the Kerberos token (or keytab entry) it needs to send to Squid.
> 
> 
> > Here's relevant part:
> > 
> > http_access deny !Safe_ports
> > http_access deny CONNECT !SSL_ports
> > http_access allow localhost manager
> > http_access deny manager
> > http_access deny to_localhost
> > # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
> > http_access deny !auth all
> > http_access allow !basic_domains !basic_extensions basic_users
> > http_reply_access allow !basic_mimetypes basic_users
> > http_access allow !advanced_domains !advanced_extensions
> > advanced_users http_access allow expert_users all
> > # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
> > http_access allow localhost
> > http_access deny all
> > 
> > I'd like to know which acl triggered the ban, so I've created custom
> > error page:
> > 
> > error_directory /usr/local/etc/squid/myerrors
> > deny_info ERR_BASIC_EXTENSION basic_extensions
> > 
> > The problem is that my custom error page does not trigger when I
> > expect it to (member of basic_users accessing URL with extension
> > listed in basic_extensions) - ERR_ACCESS_DENIED is triggered
> > instead. I guess this is because of last matching rule which is
> > http_access deny all.
> 
> Perhapse.
> 
> But, basic_extensions is never the last listed ACL in a denial rule.
> There is never a deny action associated with the ACL. That is why the
> deny_info response template is not being used.
> 
> > 
> > Is there another way how I can order acls so that I don't trigger
> > reauthentication while triggering deny_info?
> 
> Not without the ACL definition details.
> 
> Amos

Hi Amos,

thank you for looking into this. Here's complete squid.conf (I changed
just private details such as domain, DN, password etc. in
external_acl_type).

auth_param negotiate program /usr/local/libexec/squid/negotiate_kerberos_auth \
-r -s GSS_C_NO_NAME
auth_param negotiate children 10 startup=2 idle=1
auth_param negotiate keep_alive on

acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7   # RFC 4193 local private network range
acl localnet src fe80::/10  # RFC 4291 link-local (directly plugged) 
machines

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

# ldap query for group membership
external_acl_type adgroups ttl=60 children-startup=2 children-max=10 %LOGIN \
/usr/local/libexec/squid/ext_ldap_group_acl -R \
-b "DC=example,DC=org" \
-D "CN=AD Query,OU=Users,OU=BG,OU=RS,DC=example,DC=org" \
-w "mylongpassword" \
-f "(&(objectclass=person)(sAMAccountName=%v)\
(memberof=CN=%a,OU=Web 
Services,OU=Groups,OU=BG,OU=RS,DC=example,DC=org))" \
-h dc.example.org
# map ldap groups to squid acls
acl basic_users external adgroups squid_basic
acl advanced_users external adgroups squid_advanced
acl expert_users external adgroups squid_expert
# filter by dstdomain
acl basic_domains dstdomain "/usr/local/etc/squid/basic_domains"
acl advanced_domains dstdomain "/usr/local/etc/squid/advanced_domains"
# filter by extension
acl basic_extensions urlpath_regex -i "/usr/local/etc/squid/basic_extensions"
acl advanced_extensions urlpath_regex -i 
"/usr/local/etc/squid/advanced_extensions"
# require proxy authentication
acl auth proxy_auth REQUIRED

# custom error pages
deny_info ERR_BASIC_DOMAIN basic_domains
deny_info ERR_ADVANCED_DOMAIN advanced_domains
deny_info ERR_BASIC_EXTENSION basic_extensions
deny_info 

Re: [squid-users] Is it possible to send the connection, starting with the CONNECT, to cache-peer?

[Yuri Voinov]

17.09.15 10:50, Amos Jeffries пишет:

On 17/09/2015 4:36 a.m., Yuri Voinov wrote:

Hm.

If I understand correctly, the right configuration must be:

# Privoxy+Tor access rules
never_direct allow CONNECT
never_direct allow tor_url

# Local Privoxy is cache parent
cache_peer 127.0.0.1 parent 8118 0 no-query no-digest default

cache_peer_access 127.0.0.1 allow tor_url
cache_peer_access 127.0.0.1 deny all

Right?

But:

http://i.imgur.com/UMxt2vh.png

Is CONNECT always requires DIRECT?

In the above yes. If you don't want that remove the never_direct for
CONNECT as well.


I can't see FIRSTUP_PARENT for CONNECT in access log:

1442419630.962 168084 127.0.0.1 TAG_NONE/200 0 CONNECT
torproject.org:443 - HIER_DIRECT/154.35.132.70 -
1442420935.127 168180 127.0.0.1 TAG_NONE/200 0 CONNECT
torproject.org:443 - HIER_DIRECT/38.229.72.16 -


Those appear to be CONNECT requests which got ssl_bump'ed, not passed on
upstream. The access controls about how to pass things upstream are
irrelevant for them.


Because of IP's banned by ISP, direct CONNECT got timeout.

Also, all rot_url ACL can't connect.

Where I'm wrong?

Where is the server IP coming from?

Server IP comes from local DNS cache, which is got right IP via dnscrypt.

I was in this case confused by the fact that CONNECT and does not go 
into the tunnel.


I've correct configuration a bit, but still no effect:

# SSL bump rules
sslproxy_cert_error allow all
ssl_bump none localhost
ssl_bump none url_nobump
ssl_bump none dst_nobump
ssl_bump server-first net_bump

# Privoxy+Tor access rules
never_direct allow tor_url

# And finally deny all other access to this proxy
http_access deny all

# -
# HTTP parameters
# -
# Local Privoxy is cache parent
cache_peer 127.0.0.1 parent 8118 0 no-query no-digest default

cache_peer_access 127.0.0.1 allow tor_url
cache_peer_access 127.0.0.1 deny all



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

[squid-users] kinda confused about Peek and Splice

[Marek Serafin]

Hello, I'm kinda confused about the "Peek and Splice" technique 
introduced in Squid 3.5.x.

--
My goal is to allow CONNECT-method ONLY to certain web-pages (mainly 
banks, payment systems). The rest of https-sites should be allways bumped.

-
And this can be easily achieved even in squid 3.3 (I'm talking about 
situation where browser is totally aware of using proxy server -- not 
transparent mode).


But when Squid allows CONNECT method - it allows any kind of TCP tunnel 
(e.g. OpenVPN over TCP or ssh tunnel).


So, my real question is - if it's possible - using the new technique 
(Peek and Splice) to allow Splice method - but ONLY to real HTTPS Sites 
 - not a ssh or VPN service?

(I'm still talking about the situation where browsers are aware of proxying)


I was thinking that it can be done by peeking in step 2 (peeing the 
server certificate) BUT there is a limitation: peeking at the server 
certificate usually precludes future bumping. So when we're peeking at 
step 2 we can only splice later (or terminate) - which is not what I 
wanted to achieve.




If above is not possible, what is the main advantage of "Peek and 
Splice" comparing to old method (remember: browsers are aware of proxying).
I can see advantage in transparent mode  - obtaining domain name by SNI. 
But in "normal mode" squid knows the domain-name because of the connect 
request? And knowing the domain-name we can decide what to do.


thx for any hints or explanation!

HELION SA, 44-100 Gliwice, ul. Kościuszki 1C
Numer KRS 121256 Sąd Rejonowy w Gliwicach,
X Wydział Gospodarczy Krajowego Rejestru Sądowego.
NIP 631-020-02-68, REGON: 271070648
Kapitał zakładowy: 500100 zł w całości wpłacony
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Is it possible to send the connection, starting with the CONNECT, to cache-peer?

[Yuri Voinov]

If I disable SSL bump for tunneled sites, I've got an error SSL:

ssl_error_rx_record_too_long

17.09.15 10:50, Amos Jeffries пишет:

On 17/09/2015 4:36 a.m., Yuri Voinov wrote:

Hm.

If I understand correctly, the right configuration must be:

# Privoxy+Tor access rules
never_direct allow CONNECT
never_direct allow tor_url

# Local Privoxy is cache parent
cache_peer 127.0.0.1 parent 8118 0 no-query no-digest default

cache_peer_access 127.0.0.1 allow tor_url
cache_peer_access 127.0.0.1 deny all

Right?

But:

http://i.imgur.com/UMxt2vh.png

Is CONNECT always requires DIRECT?

In the above yes. If you don't want that remove the never_direct for
CONNECT as well.


I can't see FIRSTUP_PARENT for CONNECT in access log:

1442419630.962 168084 127.0.0.1 TAG_NONE/200 0 CONNECT
torproject.org:443 - HIER_DIRECT/154.35.132.70 -
1442420935.127 168180 127.0.0.1 TAG_NONE/200 0 CONNECT
torproject.org:443 - HIER_DIRECT/38.229.72.16 -


Those appear to be CONNECT requests which got ssl_bump'ed, not passed on
upstream. The access controls about how to pass things upstream are
irrelevant for them.


Because of IP's banned by ISP, direct CONNECT got timeout.

Also, all rot_url ACL can't connect.

Where I'm wrong?

Where is the server IP coming from?

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] Is it possible to send the connection, starting with the CONNECT, to cache-peer?

[Yuri Voinov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
On Squid 3.5.7 the same result:

1442420915.874 207879 127.0.0.1 TAG_NONE/200 0 CONNECT
torproject.org:443 - HIER_DIRECT/2001:41b8:202:deb:213:21ff:fe20:1426 -
1442493956.863 168528 127.0.0.1 TAG_NONE/200 0 CONNECT
torproject.org:443 - HIER_DIRECT/38.229.72.16 -
1442493957.934 168289 127.0.0.1 TAG_NONE/200 0 CONNECT
torproject.org:443 - HIER_DIRECT/38.229.72.16 -

Config snippet is:


# SSL bump rules
sslproxy_cert_error allow all
acl DiscoverSNIHost at_step SslBump1
ssl_bump peek DiscoverSNIHost
acl NoSSLIntercept ssl::server_name_regex -i localhost \.icq\.* kaspi\.kz
ssl_bump splice NoSSLIntercept
ssl_bump bump all

# Privoxy+Tor access rules
never_direct allow tor_url

# And finally deny all other access to this proxy
http_access deny all

# -
# HTTP parameters
# -

# Local Privoxy is cache parent
cache_peer 127.0.0.1 parent 8118 0 no-query no-digest default

cache_peer_access 127.0.0.1 allow tor_url
cache_peer_access 127.0.0.1 deny all

Squid configuration options:

http://i.imgur.com/1234E8q.png

17.09.15 16:18, Amos Jeffries пишет:
> On 17/09/2015 7:57 p.m., Yuri Voinov wrote:
>>
>>
>> 17.09.15 10:50, Amos Jeffries пишет:
>>> On 17/09/2015 4:36 a.m., Yuri Voinov wrote:
 Hm.

 If I understand correctly, the right configuration must be:

 # Privoxy+Tor access rules
 never_direct allow CONNECT
 never_direct allow tor_url

 # Local Privoxy is cache parent
 cache_peer 127.0.0.1 parent 8118 0 no-query no-digest default

 cache_peer_access 127.0.0.1 allow tor_url
 cache_peer_access 127.0.0.1 deny all

 Right?

 But:

 http://i.imgur.com/UMxt2vh.png

 Is CONNECT always requires DIRECT?
>>> In the above yes. If you don't want that remove the never_direct for
>>> CONNECT as well.
>>>
 I can't see FIRSTUP_PARENT for CONNECT in access log:

 1442419630.962 168084 127.0.0.1 TAG_NONE/200 0 CONNECT
 torproject.org:443 - HIER_DIRECT/154.35.132.70 -
 1442420935.127 168180 127.0.0.1 TAG_NONE/200 0 CONNECT
 torproject.org:443 - HIER_DIRECT/38.229.72.16 -

>>> Those appear to be CONNECT requests which got ssl_bump'ed, not passed on
>>> upstream. The access controls about how to pass things upstream are
>>> irrelevant for them.
>>>
 Because of IP's banned by ISP, direct CONNECT got timeout.

 Also, all rot_url ACL can't connect.

 Where I'm wrong?
>>> Where is the server IP coming from?
>> Server IP comes from local DNS cache, which is got right IP via dnscrypt.
>>
>> I was in this case confused by the fact that CONNECT and does not go
>> into the tunnel.
>>
>> I've correct configuration a bit, but still no effect:
>>
>> # SSL bump rules
>> sslproxy_cert_error allow all
>> ssl_bump none localhost
>> ssl_bump none url_nobump
>> ssl_bump none dst_nobump
>> ssl_bump server-first net_bump
>>
>
> Ah. Right I forget this is 3.4 you are talking about.
>
> server-first bumping requires a SSL/TLS server to get the cert details
> from. Your cache_peer is not one of those servers, and ssl-bump through
> a peer is a 3.5 feature. What happens in 3.4 is a mandatory DIRECT
> connection.
>
> Amos
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQEcBAEBCAAGBQJV+rZ1AAoJENNXIZxhPexGQiAH/RLc8a0mWAV6Xi75QFM+TBnD
0FgRqYqeZCbYEgGl+pTJFMQyEo1e1eXSudRTAQGNcO3gTqhlz9n/2tee6U60a/tC
jmxVtFxpqThcZjcvLP1/ODz1dclDkSJ4QBKlKlr2Z4Qya3Sd/jF8g1hm+tr7jZ31
fLp6MVxcO3fGNg1dfb7AQjRaMiOz+/nVsQD6dt3ciqLxjjTqyCMd/YceSsg9//l/
N/sfoR/Jj6lQrQBb59ssUHOGE04y1Igksx24kqF+NhQllHn2Tgc48G1R+13Zyj9s
f21kzakaSqHcrATHg7VK9iNkOguqrkJx9bTRZrTr9GM0mD/1VTAmV22qjAcqxp0=
=Luej
-END PGP SIGNATURE-

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

Re: [squid-users] kinda confused about Peek and Splice

[Alex Rousskov]

On 09/17/2015 04:00 AM, Marek Serafin wrote:
> Hello, I'm kinda confused about the "Peek and Splice" technique
> introduced in Squid 3.5.x.
> --
> My goal is to allow CONNECT-method ONLY to certain web-pages (mainly
> banks, payment systems). The rest of https-sites should be allways bumped.
> -
> And this can be easily achieved even in squid 3.3 (I'm talking about
> situation where browser is totally aware of using proxy server -- not
> transparent mode).
> 
> But when Squid allows CONNECT method - it allows any kind of TCP tunnel
> (e.g. OpenVPN over TCP or ssh tunnel).
> 
> So, my real question is - if it's possible - using the new technique
> (Peek and Splice) to allow Splice method - but ONLY to real HTTPS Sites
>  - not a ssh or VPN service?

The short answer to your question is "when splicing, it is only possible
to check whether the service is using SSL". Here are the details:

* Peeking or staring at step1 results in Squid parsing the client SSL
Hello. This does not guarantee that the client is an HTTPS client, but
it virtually guarantees that it is an SSL client.

* Peeking or staring at step2 results in Squid validating the server
certificate. This does not guarantee that the server is an HTTPS server,
but it virtually guarantees that it is an SSL server.

* Beyond step2, you have to bump to check that the SSL client and the
SSL server are going to talk HTTP after CONNECT and SSL handshake. There
is and will be no way around that. Staring allows you to bump if that is
what you want.

... where "X at stepN" means "action X matched at SslBump step #N".


However, your question seems to contradict your goal of splicing
connections to "certain" known servers and only to those servers: If you
know that example.com is a trusted bank, do you really need to check
that nobody is creating an ssh connection to that bank? If not, then
validating "bank" traffic beyond SSL handshake becomes irrelevant. You
simply trust the "bank" not to provide any "bad" services.


> (I'm still talking about the situation where browsers are aware of
> proxying)

Browser awareness does not really matter as far as non-HTTP detection is
concerned.


> I was thinking that it can be done by peeking in step 2 (peeing the
> server certificate) BUT there is a limitation: peeking at the server
> certificate usually precludes future bumping. So when we're peeking at
> step 2 we can only splice later (or terminate) - which is not what I
> wanted to achieve.

You do not need to bump to validate the server certificate (and, hence,
confirm that it is a known-to-you "bank"). If you want to bump, you can
stare instead of peeking.


> what is the main advantage of "Peek and
> Splice" comparing to old method (remember: browsers are aware of proxying).
> I can see advantage in transparent mode  - obtaining domain name by SNI.
> But in "normal mode" squid knows the domain-name because of the connect
> request?

In some cases, the CONNECT request contains an IP address instead of a
domain name.


HTH,

Alex.

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

Re: [squid-users] Custom external acl helpers in PHP

[Walter (NIF)]

Hi, Amos!

I followed your suggestion and rewrote the code using only one helper 
and a note ACL.

It's working perfectly. Thank you!

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

[squid-users] squid 3.5.7 for Windows (from Diladele) and kerberos auth

[MORRIS Paul [Tuart College]]

Hi,

I am trying without success to use the "negotiate_kerberos_auth.exe" helper and 
"basic_smb_auth.exe" on a Windows 2008R2 server on a 2008R2 domain.
Previously I have used mswin_negotiate_auth.exe and mswin_auth.exe from the 
last stable 2.7 build with no issues.
Most of the instructions for setting up Kerberos authentication are for Linux, 
I am unsure which parts are applicable to Windows.

Can anyone help with the requirements for both of these new helpers in 3.5.7 
under Windows?
Can I just use the helper from 2.7 in 3.5.7?

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