Re: [squid-users] ssl_bump newbie troubles

[Alex Rousskov]

On 04/20/2016 04:18 PM, Odhiambo Washington wrote:
> On 21 April 2016 at 00:11, Alex Rousskov wrote:
> 
> On 04/20/2016 02:22 PM, Odhiambo Washington wrote:
> 
> > All I want is the ability to intercept SSL sites and control access to
> > them using TIME ACLs. That's all.

You also want to serve custom errors over encrypted connections. That is
a huge addition to the above "all".


> If you are OK with terminating the prohibited connection (no
> error messages explaining company policy sent by Squid to your users!),
> then yes:
> 
>   ssl_bump terminate restricted_sites
>   ssl_bump peek all
>   ssl_bump splice all
> 
> 
> 
> What I would like is:
> 
> 1. that squid is able to 'see' that *userX* is trying to visit
> https://www.facebook.com
> 2. but at that particular time (time ACL) *userX* is not allowed to go
> to facebook.com , so squid denies access, throws a
> default error on their browser

Serving a Squid-generated error over [what the browser believes is] a
secure connection to the _origin server_ requires bumping that
connection. Bumping (as opposed to splicing) implies installing company
root certificates and many other headaches.

In other words, your desire to immediately inform the user about the
denied access opens a Pandora box and adds a whole new order of
complexity (or two) to the project.

Instant gratification is very important these days, but there are
probably alternatives to serving error pages over bumped connections.
The simplest to implement might be something like sending a "you have
been blocked" email to the offending user (from the blocking ACL
script), but one can think of a lot fancier notification vectors than that.


> The time logic is already built in squid.conf. All that remains is just
> intercept https traffic and let the time acls decide whether or not a
> user can get there.

... and bump the supposedly secure connection to serve the error page if
the user cannot get there.


> So allow me to ask: in *ssl_bump terminate restricted_sites, * I am lost
> as to what restricted_sites represent.

It is an ACL that represents your "access control" logic. It is too
boring/standard to discuss while we are talking about SslBump. I am sure
you can define it (yourself or with help from this mailing list).

If you allow me an analogy, discussing that ACL is like discussing the
color of the paint on the atomic bomb. I am sure you will find a nice
color scheme eventually, but I am more concerned about your users
staying alive after you drop it on them.


Alex.

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

Re: [squid-users] ssl_bump newbie troubles

[Odhiambo Washington]

On 21 April 2016 at 00:11, Alex Rousskov 
wrote:

> On 04/20/2016 02:22 PM, Odhiambo Washington wrote:
>
> > All I want is the ability to intercept SSL sites and control access to
> > them using TIME ACLs. That's all.
>
> I will assume that your definition of a "site" is "domain name".
>

Yes.


>
> > So in simple:
> > 1. UserX tries to access facebook.com/youtube.com
> > 2. I intercept transparently https traffic
> > 3. I tell squid "don't allow this user to access facebook.com
> >  at this time, but let them access at some-other-time
> > 4. If time is right, let userX access the site.
>
> > So looks like all I need is a setup of passive monitoring, given my
> > explanation above, right?
>
> The answer depends on what you want Squid to do when access is not
> allowed. If you are OK with terminating the prohibited connection (no
> error messages explaining company policy sent by Squid to your users!),
> then yes:
>
>   ssl_bump terminate restricted_sites
>   ssl_bump peek all
>   ssl_bump splice all
>


What I would like is:

1. that squid is able to 'see' that *userX* is trying to visit
https://www.facebook.com
2. but at that particular time (time ACL) *userX* is not allowed to go to
facebook.com, so squid denies access, throws a default error on their
browser
3. However, *userY* has unrestricted access to anywhere at all times so
squid allows the user to proceed.
The time logic is already built in squid.conf. All that remains is just
intercept https traffic and let the time acls decide whether or not a user
can get there..


So allow me to ask: in *ssl_bump terminate restricted_sites, * I am lost as
to what restricted_sites represent.

If my squid.conf matters, I have it here: http://goo.gl/vA6nrB. All I want
is to restrict/control (using time) access to TIMEWASTAGESITES :-)
I do not need to bump at all.

(My English could be my undoing here :-))

Thanks for your patience in baby-sitting me.


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft."
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] ssl_bump newbie troubles

[Alex Rousskov]

On 04/20/2016 02:22 PM, Odhiambo Washington wrote:

> All I want is the ability to intercept SSL sites and control access to
> them using TIME ACLs. That's all.

I will assume that your definition of a "site" is "domain name".


> So in simple:
> 1. UserX tries to access facebook.com/youtube.com
> 2. I intercept transparently https traffic 
> 3. I tell squid "don't allow this user to access facebook.com
>  at this time, but let them access at some-other-time
> 4. If time is right, let userX access the site.

> So looks like all I need is a setup of passive monitoring, given my
> explanation above, right? 

The answer depends on what you want Squid to do when access is not
allowed. If you are OK with terminating the prohibited connection (no
error messages explaining company policy sent by Squid to your users!),
then yes:

  ssl_bump terminate restricted_sites
  ssl_bump peek all
  ssl_bump splice all

As typical for SslBump, Squid has bugs and missing features in some
corner cases touched by the above simple configuration, so some
babysitting and additional configuration is likely, but it should work
in principle. Known bugs can be fixed and missing features added.


HTH,

Alex.

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

Re: [squid-users] ssl_bump newbie troubles

[Odhiambo Washington]

On 20 April 2016 at 18:38, Alex Rousskov 
wrote:

> On 04/20/2016 08:16 AM, Odhiambo Washington wrote:
>
> > I even wonder if this config is correct:
> >
> > acl ssl_bump_broken_sites  dstdomain ...
> > ssl_bump none ssl_bump_broken_sites
> > ssl_bump peek step1
> > ssl_bump stare step2
> > ssl_bump bump all
>
> You did not say what you want Squid to do, so it is difficult to say
> whether the config is correct. However, the following combinations look
> strange to me:
>
> * old "none" and new "peek" actions; use "splice" instead of "none"
> * sometimes contradictory "peek" and "stare" actions; pick one kind
> * sometimes contradictory "peek" and "bump" actions; if you intend to
> bump, use "stare"
>
Also, you may want to use ssl::server_name ACL instead of dstdomain.
> Remember that Squid may have no domain information until it is too late
> to splice. Here is a polished config that may or may not do what you want:
>
>   # Bump aggressively, including discovered-too-late broken_sites:
>   acl ssl_bump_broken_sites ssl::server_name ...
>   ssl_bump splice ssl_bump_broken_sites
>   ssl_bump stare all
>   ssl_bump bump all
>

Hi Alex,

Thank you for looking into and advising about this. I really do not want to
get intrusive on the setup.
All I want is the ability to intercept SSL sites and control access to them
using TIME ACLs. That's all.
Sites should be accessed without any interference apart from determining at
what time they can be
accessed by certain restricted users. Think about restricting facebook.com,
youtube.com, etc which
otherwise I would not have control over in a normal intercept. That's the
only reaon I need this ssl_bump stuff.

So in simple:
1. UserX tries to access facebook.com/youtube.com
2. I intercept transparently https traffic
3. I tell squid "don't allow this user to access facebook.com at this time,
but let them access at some-other-time
4. If time is right, let userX access the site.

I still need to wrap my hear around thise 'stare' and 'peek' and what
happens with them.


> > I had to import my CA to all devices (as a trusted CA) on
> > the network so that they don't get the MITM notification. [...] People
> > don't like intrusive changes.
>
> "ssl_bump bump" implies intrusiveness. You need to decide whether
> bumping connections is important enough to be intrusive. The alternative
> is passive monitoring/splicing that does not require intrusive changes
> but gives you less control. Pick your poison.
>
> Alex.
>


So looks like all I need is a setup of passive monitoring, given my
explanation above, right?
Don't bump, just monitor and restrict access to some users based on time.
Generally I want to
control access to those sites users usually waste time on during work
hours:-)




-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft."
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] ssl_bump newbie troubles

[Amos Jeffries]

On 21/04/2016 2:16 a.m., Odhiambo Washington wrote:
> Hi,
> 
> I am trying my hands on ssl_bump and it's almost working, but that's
> ish-ish.. because I have several problems.
> 
> I even wonder if this config is correct:
> 
> *acl step1 at_step SslBump1*
> *acl step2 at_step SslBump2*
> *acl step3 at_step SslBump3*
> 
> *acl ssl_bump_broken_sites  dstdomain
> "/usr/local/etc/squid/ssl_bump_broken_sites.txt"*
> *ssl_bump none ssl_bump_broken_sites*
> 

There is no HTTP message URL in TLS, so dstdomain does not work in
ssl_bump. Use ACL type "ssl::server_name" instead.

Also, the legacy action "none" is not compatible with peek/stare
actions. Use "splice" instead.

> 
> *acl step1 at_step SslBump1*
> *ssl_bump peek step1*
> *ssl_bump stare step2*
> *ssl_bump bump all*
> 
> *sslproxy_capath /etc/ssl/certs*
> *sslproxy_cert_error allow all*
> *#sslproxy_cert_error deny all*
> *sslproxy_flags DONT_VERIFY_PEER*

You should test with verification and errors enabled. That way you get
told by Squid what the problems are. This way things just get ignored
and then maybe TLS "mysteriously" dies.

> *sslproxy_cafile /usr/local/share/certs/ca-root-nss.crt*
> 
> 
> 
> 
> The following error was encountered while trying to retrieve the URL:
> https://org.ke.m-pesa.com/*
> 
> *Failed to establish a secure connection to 196.201.214.212*
> 
> The system returned:
> 
> (92) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)
> 
> Handshake with SSL server failed: error:14094412:SSL
> routines:SSL3_READ_BYTES:sslv3 alert bad certificate
> 
> This proxy and the remote host failed to negotiate a mutually acceptable
> security settings for handling your request. It is possible that the remote
> host does not support secure connections, or the proxy is not satisfied
> with the host security credentials.
> 
> 
> 
> 
> 
> 
> I thought I could mitigate that with the:
> 
> *acl ssl_bump_broken_sites  dstdomain
> "/usr/local/etc/squid/ssl_bump_broken_sites.txt"*
> *ssl_bump none ssl_bump_broken_sites*
> 
> ..but that doesn't do it...

What you seem to have intended (splice) might work.

The message seem pretty clear. Squid was unable to validate the
certificate of that origin server.


> 
> Secondly, I had to import my CA to all devices (as a trusted CA) on the
> network so that they don't get the MITM notification. This is a challenge,
> because I have to do the same for smart phones too, and that is not easy.
> People don't like intrusive changes. For example on Android phone, you have
> to set screen security before you can import such a CA, and after you do,
> you cannot disable the screen security! Now, that is not something people
> want.

That import is mandatory for "bump" action to work without SSL/TLS warnings.

If you only use peek and splice actions then Squid is not touching the
crypto and it is not needed.

Amos

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

Re: [squid-users] ssl_bump newbie troubles

[Alex Rousskov]

On 04/20/2016 08:16 AM, Odhiambo Washington wrote:

> I even wonder if this config is correct:
> 
> acl ssl_bump_broken_sites  dstdomain ...
> ssl_bump none ssl_bump_broken_sites
> ssl_bump peek step1
> ssl_bump stare step2
> ssl_bump bump all

You did not say what you want Squid to do, so it is difficult to say
whether the config is correct. However, the following combinations look
strange to me:

* old "none" and new "peek" actions; use "splice" instead of "none"
* sometimes contradictory "peek" and "stare" actions; pick one kind
* sometimes contradictory "peek" and "bump" actions; if you intend to
bump, use "stare"

Also, you may want to use ssl::server_name ACL instead of dstdomain.
Remember that Squid may have no domain information until it is too late
to splice. Here is a polished config that may or may not do what you want:

  # Bump aggressively, including discovered-too-late broken_sites:
  acl ssl_bump_broken_sites ssl::server_name ...
  ssl_bump splice ssl_bump_broken_sites
  ssl_bump stare all
  ssl_bump bump all


> I had to import my CA to all devices (as a trusted CA) on
> the network so that they don't get the MITM notification. [...] People
> don't like intrusive changes.

"ssl_bump bump" implies intrusiveness. You need to decide whether
bumping connections is important enough to be intrusive. The alternative
is passive monitoring/splicing that does not require intrusive changes
but gives you less control. Pick your poison.

Alex.

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