Filering HTTPS URLs - A complete configuration

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Filering HTTPS URLs - A complete configuration

Paul Doignon
Hi,

I'm struggling a lot to configure Squid. To improve the security of my app in my AWS private subnet, I would like to build a HTTPS proxy to whitelist *only* some URLs.
My wish is to *not* rely on SNI filtering but bump HTTPS traffic in order to filter the URLs (path) of HTTPS requests. I know that means to install a custom CA.
The thing is... I have a hard compiling a working configuration file for Squid 3.5, most examples are outdated or incomplete.

My current config is :

# ---
# General
cache_effective_user squid
cache_effective_group squid
shutdown_lifetime 1 seconds
visible_hostname squid

# Hide some reavealing or useless headers
forwarded_for delete
httpd_suppress_version_string off
reply_header_access X-Cache deny all
reply_header_access X-Cache-Lookup deny all
via off

# Tuning
max_filedesc 10000

# Disable access to manager
http_access deny manager

# Handling HTTPS requests
https_port 8080 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl/squid.pem options=NO_SSLv3,NO_TLSv1,NO_TLSv1_1,SINGLE_DH_USE,SINGLE_ECDH_USE intercept
sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/lib/squid/ssl_db -M 4MB
sslcrtd_children 8 startup=1 idle=1
acl SSL_port port 443
http_access allow SSL_port

# Whitelist
acl whitelist-regex url_regex -i thirdparty.com/upload/stuff/
acl whitelist-regex url_regex -i otherthirdparty.com/specific-path/
http_access allow whitelist-regex

# SSL bump
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump bump whitelist-regex
ssl_bump terminate step2 !whitelist-regex

# Deny the rest
http_access deny all
# ---

What I am missing ? Should I use squid 4 for this ?
Thanks a lot in advance !


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Filering HTTPS URLs - A complete configuration

Amos Jeffries
Administrator
On 6/02/19 3:33 am, Paul Doignon wrote:
> Hi,
>
> I'm struggling a lot to configure Squid. To improve the security of my app in my AWS private subnet,

If it is indeed *your* app; then please alter it not to require the
interception we see below. Ability to connect to a TLS explicit proxy or
just sending regular proxy CONNECT tunnel is a leap up in security.


> I would like to build a HTTPS proxy to whitelist *only* some URLs.
> My wish is to *not* rely on SNI filtering but bump HTTPS traffic in order to filter the URLs (path) of HTTPS requests. I know that means to install a custom CA.
> The thing is... I have a hard compiling a working configuration file for Squid 3.5, most examples are outdated or incomplete.

It looks below like you are of the mistaken belief that "HTTPS requests"
are actually a distinct thing that can be manipulated and tested.

"HTTPS" is just a moniker used to describe a multi-layer system for
delivering HTTP messages securely. This has a major impact on what can
be done at any particular time, especially regarding the URLs from those
HTTP messages.


>
> My current config is :
>
> # ---
> # General
> cache_effective_user squid
> cache_effective_group squid
> shutdown_lifetime 1 seconds
> visible_hostname squid
>

Note 1) 'squid' is not a unique hostname. Ideally it should be a FQDN.
At the very least an internally resolvable name so the URLs Squid
generates with this string as the domain name will be valid for clients
needing to download objects with those URLs from Squid. Either way it
has to be unique across all proxies the traffic *might* travel -
otherwise the messages will be dropped in transit. So definitely do not
use something this simple and often-repeated as "squid" or "proxy".


> # Hide some reavealing or useless headers
> forwarded_for delete
> httpd_suppress_version_string off
> reply_header_access X-Cache deny all
> reply_header_access X-Cache-Lookup deny all
> via off
>
> # Tuning
> max_filedesc 10000
>
> # Disable access to manager
> http_access deny manager
>

2) you are missing the security protections from the default squid.conf...


> # Handling HTTPS requests
> https_port 8080 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl/squid.pem options=NO_SSLv3,NO_TLSv1,NO_TLSv1_1,SINGLE_DH_USE,SINGLE_ECDH_USE intercept
> sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/lib/squid/ssl_db -M 4MB
> sslcrtd_children 8 startup=1 idle=1
> acl SSL_port port 443
> http_access allow SSL_port
>

3) Not a good idea. I see a lot of admin get this far and stop looking
for the proper solution when "things work".

Since you are intercepting traffic to reach this point it should be
somewhat reasonable to limit the allowed traffic to some IP range. eg.
the subnet of IPs you are intercepting and sending into the proxy.


> # Whitelist
> acl whitelist-regex url_regex -i thirdparty.com/upload/stuff/
> acl whitelist-regex url_regex -i otherthirdparty.com/specific-path/
> http_access allow whitelist-regex

Okay.

>
> # SSL bump
> acl step1 at_step SslBump1
> ssl_bump peek step1

 ... if the client is allowed to connect to the proxy, fetch its
clientHello details...


> ssl_bump bump whitelist-regex

... then try to do the impossible. We only have TLS details at this
point. There is no HTTP message - therefore no URL to match against.
 -> result: skip this line, never do this "bump" action.


> ssl_bump terminate step2 !whitelist-regex

... regex still cannot match.
... but a non-match (aka false) with '!' means true.

So at step2 always terminate the connection.


Notice how there has still not been anything even remotely HTTP from the
client/app and they are now disconnected.

>
> # Deny the rest
> http_access deny all
> # ---
>
> What I am missing ?

It seems understanding of what ssl_bump is doing is lacking.

Please see <https://wiki.squid-cache.org/Features/SslPeekAndSplice> for
details on the TLS handshake process and what SSL-Bump does during that.


> Should I use squid 4 for this ?

TL;DR : Yes.


Long version:

TLS is a volatile environment these days and each Squid release has
large improvements to cope with that change. You will find that v4 works
okay in a lot of TLS situations where v3 would the throwing up errors
and needing extra config workarounds.

Also, v3.x are all officially deprecated / no longer supported. v4 is
the current stable release.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Filering HTTPS URLs - A complete configuration

Paul Doignon
Thanks, I appreciate your detailed answer.

 > > I'm struggling a lot to configure Squid. To improve the security of my app in my AWS private subnet,
 >
 > If it is indeed *your* app; then please alter it not to require the
 > interception we see below. Ability to connect to a TLS explicit proxy or
 > just sending regular proxy CONNECT tunnel is a leap up in security.

I wish I could too ! Unfortunately, we use some third party libraries that do not support proxies (or not well). What a shame : (
 
 > > # Hide some reavealing or useless headers
 > > forwarded_for delete
 > > httpd_suppress_version_string off
 > > reply_header_access X-Cache deny all
 > > reply_header_access X-Cache-Lookup deny all
 > > via off
 > >
 > > # Tuning
 > > max_filedesc 10000
 > >
 > > # Disable access to manager
 > > http_access deny manager
 >
 > 2) you are missing the security protections from the default squid.conf...
 
I have not hardened Squid yet, but you mean default `acl localnet src [...]` rules ? I'm not sure about this.

 > Please see <https://wiki.squid-cache.org/Features/SslPeekAndSplice> for
 > details on the TLS handshake process and what SSL-Bump does during that.

Another read was indeed interesting, I think I corrected ssl_bump directives. However I still can't make it work.
Just for the record, I would like to block everything but some HTTPS websites for particular URLs. The ssl::server_name acl is not enough for me, I would like to use url_regex or similar.
Ant that's where it gets wrong, I can't make Squid make the link between `ssl_bump bump` and url_regex.

# --
# General
shutdown_lifetime 1 seconds

# Hide some reavealing or useless headers
forwarded_for delete
httpd_suppress_version_string off
reply_header_access X-Cache deny all
reply_header_access X-Cache-Lookup deny all
via off

# Tuning
max_filedesc 10000

# Disable access to manager
http_access deny manager

# Misc, TODO
http_port 3128
host_verify_strict off

# Handling HTTPS requests
https_port 8080 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl/squid.pem options=NO_SSLv3,NO_TLSv1,NO_TLSv1_1,SINGLE_DH_USE,SINGLE_ECDH_USE intercept
sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/cache/squid/ssl_db -M 4MB
sslcrtd_children 8 startup=1 idle=1
acl SSL_port port 443
http_access allow SSL_port

# Whitelist
acl whitelist-regex url_regex -i thirdparty.com/upload/stuff/
acl whitelist-regex url_regex -i otherthirdparty.com/specific-path/
http_access allow whitelist-regex

# SSL bump
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump stare step1 all
ssl_bump stare step2 all
ssl_bump bump whitelist-regex
ssl_bump terminate all

# Deny the rest
http_access deny all
# --

 > > Should I use squid 4 for this ?
 >
 > TL;DR : Yes.
 
I did that, thanks !
Easy to install and migrate on arch but I think I will need to compile it for Amazon Linux.


 ---- On Tue, 05 Feb 2019 16:35:52 +0100 Amos Jeffries <[hidden email]> wrote ----
 > On 6/02/19 3:33 am, Paul Doignon wrote:
 > > Hi,
 > >
 > > I'm struggling a lot to configure Squid. To improve the security of my app in my AWS private subnet,
 >
 > If it is indeed *your* app; then please alter it not to require the
 > interception we see below. Ability to connect to a TLS explicit proxy or
 > just sending regular proxy CONNECT tunnel is a leap up in security.
 >
 >
 > > I would like to build a HTTPS proxy to whitelist *only* some URLs.
 > > My wish is to *not* rely on SNI filtering but bump HTTPS traffic in order to filter the URLs (path) of HTTPS requests. I know that means to install a custom CA.
 > > The thing is... I have a hard compiling a working configuration file for Squid 3.5, most examples are outdated or incomplete.
 >
 > It looks below like you are of the mistaken belief that "HTTPS requests"
 > are actually a distinct thing that can be manipulated and tested.
 >
 > "HTTPS" is just a moniker used to describe a multi-layer system for
 > delivering HTTP messages securely. This has a major impact on what can
 > be done at any particular time, especially regarding the URLs from those
 > HTTP messages.
 >
 >
 > >
 > > My current config is :
 > >
 > > # ---
 > > # General
 > > cache_effective_user squid
 > > cache_effective_group squid
 > > shutdown_lifetime 1 seconds
 > > visible_hostname squid
 > >
 >
 > Note 1) 'squid' is not a unique hostname. Ideally it should be a FQDN.
 > At the very least an internally resolvable name so the URLs Squid
 > generates with this string as the domain name will be valid for clients
 > needing to download objects with those URLs from Squid. Either way it
 > has to be unique across all proxies the traffic *might* travel -
 > otherwise the messages will be dropped in transit. So definitely do not
 > use something this simple and often-repeated as "squid" or "proxy".
 >
 >
 > > # Hide some reavealing or useless headers
 > > forwarded_for delete
 > > httpd_suppress_version_string off
 > > reply_header_access X-Cache deny all
 > > reply_header_access X-Cache-Lookup deny all
 > > via off
 > >
 > > # Tuning
 > > max_filedesc 10000
 > >
 > > # Disable access to manager
 > > http_access deny manager
 > >
 >
 > 2) you are missing the security protections from the default squid.conf...
 >
 >
 > > # Handling HTTPS requests
 > > https_port 8080 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl/squid.pem options=NO_SSLv3,NO_TLSv1,NO_TLSv1_1,SINGLE_DH_USE,SINGLE_ECDH_USE intercept
 > > sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/lib/squid/ssl_db -M 4MB
 > > sslcrtd_children 8 startup=1 idle=1
 > > acl SSL_port port 443
 > > http_access allow SSL_port
 > >
 >
 > 3) Not a good idea. I see a lot of admin get this far and stop looking
 > for the proper solution when "things work".
 >
 > Since you are intercepting traffic to reach this point it should be
 > somewhat reasonable to limit the allowed traffic to some IP range. eg.
 > the subnet of IPs you are intercepting and sending into the proxy.
 >
 >
 > > # Whitelist
 > > acl whitelist-regex url_regex -i thirdparty.com/upload/stuff/
 > > acl whitelist-regex url_regex -i otherthirdparty.com/specific-path/
 > > http_access allow whitelist-regex
 >
 > Okay.
 >
 > >
 > > # SSL bump
 > > acl step1 at_step SslBump1
 > > ssl_bump peek step1
 >
 >  ... if the client is allowed to connect to the proxy, fetch its
 > clientHello details...
 >
 >
 > > ssl_bump bump whitelist-regex
 >
 > ... then try to do the impossible. We only have TLS details at this
 > point. There is no HTTP message - therefore no URL to match against.
 >  -> result: skip this line, never do this "bump" action.
 >
 >
 > > ssl_bump terminate step2 !whitelist-regex
 >
 > ... regex still cannot match.
 > ... but a non-match (aka false) with '!' means true.
 >
 > So at step2 always terminate the connection.
 >
 >
 > Notice how there has still not been anything even remotely HTTP from the
 > client/app and they are now disconnected.
 >
 > >
 > > # Deny the rest
 > > http_access deny all
 > > # ---
 > >
 > > What I am missing ?
 >
 > It seems understanding of what ssl_bump is doing is lacking.
 >
 > Please see <https://wiki.squid-cache.org/Features/SslPeekAndSplice> for
 > details on the TLS handshake process and what SSL-Bump does during that.
 >
 >
 > > Should I use squid 4 for this ?
 >
 > TL;DR : Yes.
 >
 >
 > Long version:
 >
 > TLS is a volatile environment these days and each Squid release has
 > large improvements to cope with that change. You will find that v4 works
 > okay in a lot of TLS situations where v3 would the throwing up errors
 > and needing extra config workarounds.
 >
 > Also, v3.x are all officially deprecated / no longer supported. v4 is
 > the current stable release.
 >
 >
 > Amos
 > _______________________________________________
 > squid-users mailing list
 > [hidden email]
 > http://lists.squid-cache.org/listinfo/squid-users
 >


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Filering HTTPS URLs - A complete configuration

Eliezer Croitoru
No need to compile and build it for AWS:
I already built it for both AWS 1 and 2:
http://ngtech.co.il/repo/amzn/

Can be downloaded and is tested to work very well on both OS.

Eliezer

* let me know if the package is good enough.

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: [hidden email]


-----Original Message-----
From: squid-users <[hidden email]> On Behalf Of Paul Doignon
Sent: Wednesday, February 6, 2019 16:52
To: squid-users <[hidden email]>
Subject: Re: [squid-users] Filering HTTPS URLs - A complete configuration

Thanks, I appreciate your detailed answer.

 > > I'm struggling a lot to configure Squid. To improve the security of my app in my AWS private subnet,
 >
 > If it is indeed *your* app; then please alter it not to require the
 > interception we see below. Ability to connect to a TLS explicit proxy or
 > just sending regular proxy CONNECT tunnel is a leap up in security.

I wish I could too ! Unfortunately, we use some third party libraries that do not support proxies (or not well). What a shame : (
 
 > > # Hide some reavealing or useless headers
 > > forwarded_for delete
 > > httpd_suppress_version_string off
 > > reply_header_access X-Cache deny all
 > > reply_header_access X-Cache-Lookup deny all
 > > via off
 > >
 > > # Tuning
 > > max_filedesc 10000
 > >
 > > # Disable access to manager
 > > http_access deny manager
 >
 > 2) you are missing the security protections from the default squid.conf...
 
I have not hardened Squid yet, but you mean default `acl localnet src [...]` rules ? I'm not sure about this.

 > Please see <https://wiki.squid-cache.org/Features/SslPeekAndSplice> for
 > details on the TLS handshake process and what SSL-Bump does during that.

Another read was indeed interesting, I think I corrected ssl_bump directives. However I still can't make it work.
Just for the record, I would like to block everything but some HTTPS websites for particular URLs. The ssl::server_name acl is not enough for me, I would like to use url_regex or similar.
Ant that's where it gets wrong, I can't make Squid make the link between `ssl_bump bump` and url_regex.

# --
# General
shutdown_lifetime 1 seconds

# Hide some reavealing or useless headers
forwarded_for delete
httpd_suppress_version_string off
reply_header_access X-Cache deny all
reply_header_access X-Cache-Lookup deny all
via off

# Tuning
max_filedesc 10000

# Disable access to manager
http_access deny manager

# Misc, TODO
http_port 3128
host_verify_strict off

# Handling HTTPS requests
https_port 8080 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl/squid.pem options=NO_SSLv3,NO_TLSv1,NO_TLSv1_1,SINGLE_DH_USE,SINGLE_ECDH_USE intercept
sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/cache/squid/ssl_db -M 4MB
sslcrtd_children 8 startup=1 idle=1
acl SSL_port port 443
http_access allow SSL_port

# Whitelist
acl whitelist-regex url_regex -i thirdparty.com/upload/stuff/
acl whitelist-regex url_regex -i otherthirdparty.com/specific-path/
http_access allow whitelist-regex

# SSL bump
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump stare step1 all
ssl_bump stare step2 all
ssl_bump bump whitelist-regex
ssl_bump terminate all

# Deny the rest
http_access deny all
# --

 > > Should I use squid 4 for this ?
 >
 > TL;DR : Yes.
 
I did that, thanks !
Easy to install and migrate on arch but I think I will need to compile it for Amazon Linux.


 ---- On Tue, 05 Feb 2019 16:35:52 +0100 Amos Jeffries <[hidden email]> wrote ----
 > On 6/02/19 3:33 am, Paul Doignon wrote:
 > > Hi,
 > >
 > > I'm struggling a lot to configure Squid. To improve the security of my app in my AWS private subnet,
 >
 > If it is indeed *your* app; then please alter it not to require the
 > interception we see below. Ability to connect to a TLS explicit proxy or
 > just sending regular proxy CONNECT tunnel is a leap up in security.
 >
 >
 > > I would like to build a HTTPS proxy to whitelist *only* some URLs.
 > > My wish is to *not* rely on SNI filtering but bump HTTPS traffic in order to filter the URLs (path) of HTTPS requests. I know that means to install a custom CA.
 > > The thing is... I have a hard compiling a working configuration file for Squid 3.5, most examples are outdated or incomplete.
 >
 > It looks below like you are of the mistaken belief that "HTTPS requests"
 > are actually a distinct thing that can be manipulated and tested.
 >
 > "HTTPS" is just a moniker used to describe a multi-layer system for
 > delivering HTTP messages securely. This has a major impact on what can
 > be done at any particular time, especially regarding the URLs from those
 > HTTP messages.
 >
 >
 > >
 > > My current config is :
 > >
 > > # ---
 > > # General
 > > cache_effective_user squid
 > > cache_effective_group squid
 > > shutdown_lifetime 1 seconds
 > > visible_hostname squid
 > >
 >
 > Note 1) 'squid' is not a unique hostname. Ideally it should be a FQDN.
 > At the very least an internally resolvable name so the URLs Squid
 > generates with this string as the domain name will be valid for clients
 > needing to download objects with those URLs from Squid. Either way it
 > has to be unique across all proxies the traffic *might* travel -
 > otherwise the messages will be dropped in transit. So definitely do not
 > use something this simple and often-repeated as "squid" or "proxy".
 >
 >
 > > # Hide some reavealing or useless headers
 > > forwarded_for delete
 > > httpd_suppress_version_string off
 > > reply_header_access X-Cache deny all
 > > reply_header_access X-Cache-Lookup deny all
 > > via off
 > >
 > > # Tuning
 > > max_filedesc 10000
 > >
 > > # Disable access to manager
 > > http_access deny manager
 > >
 >
 > 2) you are missing the security protections from the default squid.conf...
 >
 >
 > > # Handling HTTPS requests
 > > https_port 8080 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl/squid.pem options=NO_SSLv3,NO_TLSv1,NO_TLSv1_1,SINGLE_DH_USE,SINGLE_ECDH_USE intercept
 > > sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/lib/squid/ssl_db -M 4MB
 > > sslcrtd_children 8 startup=1 idle=1
 > > acl SSL_port port 443
 > > http_access allow SSL_port
 > >
 >
 > 3) Not a good idea. I see a lot of admin get this far and stop looking
 > for the proper solution when "things work".
 >
 > Since you are intercepting traffic to reach this point it should be
 > somewhat reasonable to limit the allowed traffic to some IP range. eg.
 > the subnet of IPs you are intercepting and sending into the proxy.
 >
 >
 > > # Whitelist
 > > acl whitelist-regex url_regex -i thirdparty.com/upload/stuff/
 > > acl whitelist-regex url_regex -i otherthirdparty.com/specific-path/
 > > http_access allow whitelist-regex
 >
 > Okay.
 >
 > >
 > > # SSL bump
 > > acl step1 at_step SslBump1
 > > ssl_bump peek step1
 >
 >  ... if the client is allowed to connect to the proxy, fetch its
 > clientHello details...
 >
 >
 > > ssl_bump bump whitelist-regex
 >
 > ... then try to do the impossible. We only have TLS details at this
 > point. There is no HTTP message - therefore no URL to match against.
 >  -> result: skip this line, never do this "bump" action.
 >
 >
 > > ssl_bump terminate step2 !whitelist-regex
 >
 > ... regex still cannot match.
 > ... but a non-match (aka false) with '!' means true.
 >
 > So at step2 always terminate the connection.
 >
 >
 > Notice how there has still not been anything even remotely HTTP from the
 > client/app and they are now disconnected.
 >
 > >
 > > # Deny the rest
 > > http_access deny all
 > > # ---
 > >
 > > What I am missing ?
 >
 > It seems understanding of what ssl_bump is doing is lacking.
 >
 > Please see <https://wiki.squid-cache.org/Features/SslPeekAndSplice> for
 > details on the TLS handshake process and what SSL-Bump does during that.
 >
 >
 > > Should I use squid 4 for this ?
 >
 > TL;DR : Yes.
 >
 >
 > Long version:
 >
 > TLS is a volatile environment these days and each Squid release has
 > large improvements to cope with that change. You will find that v4 works
 > okay in a lot of TLS situations where v3 would the throwing up errors
 > and needing extra config workarounds.
 >
 > Also, v3.x are all officially deprecated / no longer supported. v4 is
 > the current stable release.
 >
 >
 > Amos
 > _______________________________________________
 > squid-users mailing list
 > [hidden email]
 > http://lists.squid-cache.org/listinfo/squid-users
 >


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Filering HTTPS URLs - A complete configuration

Amos Jeffries
Administrator
In reply to this post by Paul Doignon
On 7/02/19 3:52 am, Paul Doignon wrote:

> Thanks, I appreciate your detailed answer.
>
>  > > I'm struggling a lot to configure Squid. To improve the security of my app in my AWS private subnet,
>  >
>  > If it is indeed *your* app; then please alter it not to require the
>  > interception we see below. Ability to connect to a TLS explicit proxy or
>  > just sending regular proxy CONNECT tunnel is a leap up in security.
>
> I wish I could too ! Unfortunately, we use some third party libraries that do not support proxies (or not well). What a shame : (
>  
>  > > # Hide some reavealing or useless headers
>  > > forwarded_for delete
>  > > httpd_suppress_version_string off
>  > > reply_header_access X-Cache deny all
>  > > reply_header_access X-Cache-Lookup deny all
>  > > via off
>  > >
>  > > # Tuning
>  > > max_filedesc 10000
>  > >
>  > > # Disable access to manager
>  > > http_access deny manager
>  >
>  > 2) you are missing the security protections from the default squid.conf...
>  
> I have not hardened Squid yet, but you mean default `acl localnet src [...]` rules ? I'm not sure about this.
>

The defaults that come with a new build or installation:

"
  http_access deny !Safe_ports
  http_access deny CONNECT !SSL_ports
  http_access allow localhost manager
  http_access deny manager

  ... your rules go here ...

  http_access deny all
"


>  > Please see <https://wiki.squid-cache.org/Features/SslPeekAndSplice> for
>  > details on the TLS handshake process and what SSL-Bump does during that.
>
> Another read was indeed interesting, I think I corrected ssl_bump directives. However I still can't make it work.
> Just for the record, I would like to block everything but some HTTPS websites for particular URLs. The ssl::server_name acl is not enough for me, I would like to use url_regex or similar.
> Ant that's where it gets wrong, I can't make Squid make the link between `ssl_bump bump` and url_regex.


That is because ssl_bump is the access control governing the TLS
handshake process. TLS message/frames do not contain URLs. Even when a
client CONNECT request is being processed it only has an authority-URI
(not a full URL).

The http_access rules are the first point you get access to URL. The
https:// URLs start *after* the ssl_bump finishes with a successful
'bump' action.


The closest you are going to get to the above is with:
 * bump everything[1], and
 * use http_access to check the https:// URLs for your policy
 * use "deny_info TCP_RESET" [2] on the blocked requests.

[1] some things literally cannot be bumped. So a decision needs to be
made about what to do then.

[2] a regular deny error page will work fine. This TCP_RESET is just
closest to the "ssl_bump terminate" behaviour.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Filering HTTPS URLs - A complete configuration

Paul Doignon
> No need to compile and build it for AWS:
> I already built it for both AWS 1 and 2:
> http://ngtech.co.il/repo/amzn/
>
> Can be downloaded and is tested to work very well on both OS.
>
> Eliezer

Thanks, looks really good !
I guess those Amazon Linux 1 packages come from there : http://gogs.ngtech.co.il/NgTech-LTD/squid-amzn1-squid4-rpms ?


> The closest you are going to get to the above is with:
> * bump everything[1], and
> * use http_access to check the https:// URLs for your policy
> * use "deny_info TCP_RESET" [2] on the blocked requests.
>
> [1] some things literally cannot be bumped. So a decision needs to be
> made about what to do then.

All right, good point. I guess adding this second line will terminate those un-bumpable requests ?

# --
ssl_bump bump all
ssl_bump terminate all
# --

> [2] a regular deny error page will work fine. This TCP_RESET is just
> closest to the "ssl_bump terminate" behaviour.
>
> Amos

This is perfect, thanks a lot.

I leave my complete config for other users :

# --
# General
cache_effective_user squid
cache_effective_group squid
shutdown_lifetime 1 seconds
visible_hostname squid-something.unique

# Hide some reavealing stuffs
forwarded_for delete
httpd_suppress_version_string off
reply_header_access X-Cache deny all
reply_header_access X-Cache-Lookup deny all
via off
global_internal_static off
cache deny all

# Tuning
max_filedesc 10000

# Security
http_access deny manager
host_verify_strict on
ignore_unknown_nameservers on
snmp_port 0
snmp_access deny all
icp_port 0
icp_access deny all
htcp_port 0
htcp_access deny all

http_port localhost:3128 # Squid default port

# Handling HTTPS requests
# Ciphers from https://wiki.mozilla.org/Security/Server_Side_TLS
https_port 8080 act-as-origin ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl/squid.pem cipher=ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 options=NO_SSLv3,NO_TLSv1,NO_TLSv1_1,SINGLE_DH_USE,SINGLE_ECDH_USE intercept
sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/cache/squid/ssl_db -M 4MB
sslcrtd_children 8 startup=1 idle=1
#
tls_outgoing_options cipher=ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 min-version=1.2 options=NO_SSLv3,SINGLE_DH_USE

acl TO_SSL port 443
acl LAN src 172.16.0.0/24
acl whitelist-regex url_regex -i ^https://thirdparty\.com/upload/stuff/$
acl CONNECT method CONNECT
deny_info TCP_RESET all
http_access allow LAN TO_SSL CONNECT
http_access allow LAN TO_SSL whitelist-regex
http_access deny all

# SSL bump
ssl_bump bump all
ssl_bump terminate all
# --


 ---- On Thu, 07 Feb 2019 01:46:23 +0100 Amos Jeffries <[hidden email]> wrote ----
 > On 7/02/19 3:52 am, Paul Doignon wrote:
 > > Thanks, I appreciate your detailed answer.
 > >
 > >  > > I'm struggling a lot to configure Squid. To improve the security of my app in my AWS private subnet,
 > >  >
 > >  > If it is indeed *your* app; then please alter it not to require the
 > >  > interception we see below. Ability to connect to a TLS explicit proxy or
 > >  > just sending regular proxy CONNECT tunnel is a leap up in security.
 > >
 > > I wish I could too ! Unfortunately, we use some third party libraries that do not support proxies (or not well). What a shame : (
 > >  
 > >  > > # Hide some reavealing or useless headers
 > >  > > forwarded_for delete
 > >  > > httpd_suppress_version_string off
 > >  > > reply_header_access X-Cache deny all
 > >  > > reply_header_access X-Cache-Lookup deny all
 > >  > > via off
 > >  > >
 > >  > > # Tuning
 > >  > > max_filedesc 10000
 > >  > >
 > >  > > # Disable access to manager
 > >  > > http_access deny manager
 > >  >
 > >  > 2) you are missing the security protections from the default squid.conf...
 > >  
 > > I have not hardened Squid yet, but you mean default `acl localnet src [...]` rules ? I'm not sure about this.
 > >
 >
 > The defaults that come with a new build or installation:
 >
 > "
 >   http_access deny !Safe_ports
 >   http_access deny CONNECT !SSL_ports
 >   http_access allow localhost manager
 >   http_access deny manager
 >
 >   ... your rules go here ...
 >
 >   http_access deny all
 > "
 >
 >
 > >  > Please see <https://wiki.squid-cache.org/Features/SslPeekAndSplice> for
 > >  > details on the TLS handshake process and what SSL-Bump does during that.
 > >
 > > Another read was indeed interesting, I think I corrected ssl_bump directives. However I still can't make it work.
 > > Just for the record, I would like to block everything but some HTTPS websites for particular URLs. The ssl::server_name acl is not enough for me, I would like to use url_regex or similar.
 > > Ant that's where it gets wrong, I can't make Squid make the link between `ssl_bump bump` and url_regex.
 >
 >
 > That is because ssl_bump is the access control governing the TLS
 > handshake process. TLS message/frames do not contain URLs. Even when a
 > client CONNECT request is being processed it only has an authority-URI
 > (not a full URL).
 >
 > The http_access rules are the first point you get access to URL. The
 > https:// URLs start *after* the ssl_bump finishes with a successful
 > 'bump' action.
 >
 >
 > The closest you are going to get to the above is with:
 >  * bump everything[1], and
 >  * use http_access to check the https:// URLs for your policy
 >  * use "deny_info TCP_RESET" [2] on the blocked requests.
 >
 > [1] some things literally cannot be bumped. So a decision needs to be
 > made about what to do then.
 >
 > [2] a regular deny error page will work fine. This TCP_RESET is just
 > closest to the "ssl_bump terminate" behaviour.
 >
 >
 > Amos
 > _______________________________________________
 > squid-users mailing list
 > [hidden email]
 > http://lists.squid-cache.org/listinfo/squid-users
 >


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Filering HTTPS URLs - A complete configuration

Eliezer Croitoru
-----Original Message-----
From: squid-users <[hidden email]> On Behalf Of Paul Doignon
Sent: Monday, February 11, 2019 12:55
To: squid-users <[hidden email]>
Subject: Re: [squid-users] Filering HTTPS URLs - A complete configuration

> No need to compile and build it for AWS:
> I already built it for both AWS 1 and 2:
> http://ngtech.co.il/repo/amzn/
>
> Can be downloaded and is tested to work very well on both OS.
>
> Eliezer

Thanks, looks really good !
I guess those Amazon Linux 1 packages come from there : http://gogs.ngtech.co.il/NgTech-LTD/squid-amzn1-squid4-rpms ?

Right ^^

> The closest you are going to get to the above is with:
> * bump everything[1], and
> * use http_access to check the https:// URLs for your policy
> * use "deny_info TCP_RESET" [2] on the blocked requests.
>
> [1] some things literally cannot be bumped. So a decision needs to be
> made about what to do then.
<SNIP>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Filering HTTPS URLs - A complete configuration

Alex Rousskov
In reply to this post by Paul Doignon
On 2/11/19 3:55 AM, Paul Doignon wrote:

>> The closest you are going to get to the above is with:
>> * bump everything[1], and
>> * use http_access to check the https:// URLs for your policy
>> * use "deny_info TCP_RESET" [2] on the blocked requests.
>>
>> [1] some things literally cannot be bumped. So a decision needs to be
>> made about what to do then.

> I guess adding this second line will terminate those un-bumpable requests?

No, that second ssl_bump line has no effect -- it will never be reached.

You are probably misinterpreting what was meant by "literally cannot be
bumped". What was meant by that phrase was that bumping certain
connections always results in client and/or server errors, regardless of
how you configure Squid. In those cases, Squid will still perform the
bump action if you tell it to bump, but that action will not lead to a
functioning tunnel through Squid.

In general, Squid itself cannot predict which connections can be
successfully bumped. You have to tell it (using ACLs, like the
whitelisted ACL in the example below).


> ssl_bump bump all
> ssl_bump terminate all

The first line emulates client-first bumping. That is not what you want.

To bump all connections, you could use something like this:

  ssl_bump stare all
  ssl_bump bump all

To bump all connections except whitelisted ones, you probably want
something like this:

  ssl_bump splice whitelisted
  ssl_bump stare all
  ssl_bump bump all

... where whitelisted is your ACL implementing your white listing policy
(i.e. matching TLS connections that should be spliced). It may use
ssl::server_name and probably other ACLs.

More details at https://wiki.squid-cache.org/Features/SslPeekAndSplice

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users