SSL Bump with HTTP Cache Peer Parent

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

SSL Bump with HTTP Cache Peer Parent

sam.handley
I am not 100% confident what I am asking is possible but I'd love it to be
confirmed.

Here is what our setup would look like, I’ve explained a bit below:

DEVICE ---> PRX3 (HTTPS CACHE) ---> PRX2 ---> PRX1 ---> INTERNET

Our current environment is a bit behind the times and inflexible. We have a
local squid proxy/cache (PRX2) that we do not fully control that only caches
HTTP content. This proxy is downstream from another proxy which is also HTTP
(PRX1). Both just TUNNEL HTTPS. PRX1 is the only way out of our WAN to the
internet.

We would like to start caching HTTPS (PRX3) because these other proxies are
not and it is costing us bandwidth. With the config below and a direct
internet connection I can successfully connect and cache HTTP/S content.
However, this won’t work in our environment. We must go through a cache peer
either PRX1 or PRX2, adding either upstream proxy as a cache peer parent
results in either SSL errors or the request not being forwarded to the peer.

I think what I need to do is TUNNEL the bumped request to PRX2 over HTTP. I
thought squid 4 could do this but can’t find any docs for it so it may have
been wishful thinking.

*--- SSL Error ---*
(71) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)
Handshake with SSL server failed: error:1408F10B:SSL
routines:ssl3_get_record:wrong version number
*--- SSL Error ---*

*--- squid.conf ---*
## Proxy

# Only allow addresss in our subnet
acl LAN src 10.141.28.0/22
http_access allow LAN
http_access deny all

cache_mem 500 MB
maximum_object_size 5000 MB
range_offset_limit 5000 MB

# Set proxy port enable ssl bump, set root cert
http_port 3128 ssl-bump tls-cert=/etc/squid/CA.pem
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
options=NO_SSLv3,NO_TLSv1,NO_TLSv1_1,SINGLE_DH_USE,SINGLE_ECDH_USE
ssl_bump bump all

# Set cache directory and settings [type] [dir] [MB] [L1 = number of first
level subdirs] [L2 = number of second level subdirs] [[options]]
cache_dir diskd /srv/cache 10000 64 72

never_direct allow all
cache_peer 10.141.28.19 parent 800 0 no-query no-digest

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
*--- squid.conf ---*

*--- squid version info --- *
Squid Cache: Version 4.4
Service Name: squid

This binary uses OpenSSL 1.1.1a  20 Nov 2018. For legal restrictions on
distribution see https://www.openssl.org/source/license.html

configure options:  '--prefix=/usr' '--sbindir=/usr/bin'
'--datadir=/usr/share/squid' '--sysconfdir=/etc/squid'
'--libexecdir=/usr/lib/squid' '--localstatedir=/var'
'--with-logdir=/var/log/squid' '--with-pidfile=/run/squid.pid'
'--enable-auth' '--enable-auth-basic' '--enable-auth-ntlm'
'--enable-auth-digest' '--enable-auth-negotiate'
'--enable-removal-policies=lru,heap' '--enable-storeio=aufs,ufs,diskd,rock'
'--enable-delay-pools' '--with-openssl' '--enable-snmp'
'--enable-linux-netfilter' '--enable-ident-lookups' '--enable-useragent-log'
'--enable-cache-digests' '--enable-referer-log' '--enable-htcp'
'--enable-carp' '--enable-epoll' '--with-large-files' '--enable-arp-acl'
'--with-default-user=proxy' '--enable-async-io' '--enable-truncate'
'--enable-icap-client' '--enable-ssl-crtd' '--disable-arch-native'
'--disable-strict-error-checking' '--enable-wccpv2' 'CFLAGS=-march=x86-64
-mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt'
'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-march=x86-64 -mtune=generic -O2
-pipe -fstack-protector-strong -fno-plt'
*--- squid version info --- *
         



--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: SSL Bump with HTTP Cache Peer Parent

Amos Jeffries
Administrator
On 13/12/18 12:15 pm, sam.handley wrote:

> I am not 100% confident what I am asking is possible but I'd love it to be
> confirmed.
>
> Here is what our setup would look like, I’ve explained a bit below:
>
> DEVICE ---> PRX3 (HTTPS CACHE) ---> PRX2 ---> PRX1 ---> INTERNET
>
> Our current environment is a bit behind the times and inflexible. We have a
> local squid proxy/cache (PRX2) that we do not fully control that only caches
> HTTP content. This proxy is downstream from another proxy which is also HTTP
> (PRX1). Both just TUNNEL HTTPS. PRX1 is the only way out of our WAN to the
> internet.
>
> We would like to start caching HTTPS (PRX3) because these other proxies are
> not and it is costing us bandwidth. With the config below and a direct
> internet connection I can successfully connect and cache HTTP/S content.
> However, this won’t work in our environment. We must go through a cache peer
> either PRX1 or PRX2, adding either upstream proxy as a cache peer parent
> results in either SSL errors or the request not being forwarded to the peer.
>
> I think what I need to do is TUNNEL the bumped request to PRX2 over HTTP. I
> thought squid 4 could do this but can’t find any docs for it so it may have
> been wishful thinking.


No official version of Squid can do that directly for decrypted
requests. Only for HTTPS which is being spliced or non-HTTP protocols
that happen to get intercepted on port 443.

There are several possibilities though:

First is unofficial Factory code that implements this feature. Available
for testing at
<https://github.com/measurement-factory/squid/tree/SQUID-360-peering-for-SslBump>.


Second is that if PRX1 or PRX2 can be configured as a regular TLS proxy
- receiving proxy traffic to a https_port (or any non-Squid software'
equivalent). Then it can be used as a cache_peer with 'ssl' option(s).
This option restricts you to the dangerous client-first style bumping,
but you are already using that.


Third is that the DEVICE is set to pass https:// URLs to PRX2 using
regular TCP connections and HTTP rather than TLS. That leaves the PRX3
able to relay the non-encrypted requests to a peer as-is. Whichever
upstream PRX1 or PRX2 is used will need to do the encryption part before
the traffic hits the Internet.
 Despite the use of TCP connections this is slightly better than the
client-first bumping. At least each agent in the chain is clear and
truthful about the security properties of its connections.


Fourth is a workaround using NAT interception of port 443 and two
proxies. If you setup a PRX-A doing the bump but acting as if it had a
direct network connection. The PRX-B using a https_port with "intercept
ssl-bump" options and doing splice on all traffic and passing the
resulting CONNECT tunnels through to the PRX1 or PRX2.


All these have actually been used by some installations at one point or
another. So there is precedent, though YMMV which works for you.
 I expect #4 can also be done as a variant with SMP workers in PRX3
instead of separate proxies - that I am not aware of anyone doing though.


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

Re: SSL Bump with HTTP Cache Peer Parent

Amos Jeffries
Administrator
[ please keep the traffic on-list. If you want private assistance I do
consult for a small fee. ]


On 13/12/18 2:51 pm, Sam Handley wrote:
> On 13/12/18 12:00 pm, Amos Jeffries wrote:
>
> Thank you for your reply, it seems adding in an extra step could solve it, even if not ideal.
> Just a few questions about your suggestions./Second is that if PRX1 or PRX2 can be configured as a regular TLS proxy
> - receiving proxy traffic to a https_port (or any non-Squid software'
> equivalent). Then it can be used as a cache_peer with 'ssl' option(s). /Would both PRX1 and PRX2 require https_port to be configured?


It would yes. That config setting on the receiving proxy is what makes
it a "TLS proxy" instead of just a proxy.


> We have a limited ability to edit PRX2 and it does not have https_port enabled. /This option restricts you to the dangerous client-first style bumping,
> but you are already using that. /My experience so far is that performing any kind of bump action after step1 results in the connection being TUNNELLED and not cached by PRX1.

The only thing which would result in https:// traffic being cached in
PRX1 is for PRX1 to be doing the decrypt SSL-Bump itself, or acting at a
TLS proxy.

Traffic which has https:// URL scheme should only ever leave Squid over
an encrypted connection. Especially when "bump" is happening.


> For example,
> 1.
> ssl_bump bump step2 all #results in the connection TUNNELLING and no caching.
>

Your description earlier was the SSL-Bump and cache happening in PRX3.

PRX1 and PRX2 being regular proxies will see tunnels ... or nothing at all.


> 2.
> ssl_bump peek step2 all
> ssl_bump bump step3 all #results in the connection TUNNELLING and no caching.

IIRC, your lack of a Step-1 action implies tunneling.

The "peek" at Step-2 prohibits "bump" being used at Step-3. So even if
my recollection was incorrect above you get a tunnel from this step-3.


To decrypt and cache the traffic needs to be going through one of these
SSL-Bump sequences:

  bump, terminate, terminate
  peek, bump, terminate
  stare, bump, terminate
  peek, stare, bump
  stare, stare, bump

The terminate are just there as a catch-all for traffic which bump fails
for any reason. You could try splice instead of you want, but that will
also fail sometimes - terminate is the reliable one.


>
> It would be preferred to use server-first if it did indeed cache the content, can you provide a more ideal bump configuration that will still allow us to cache HTTPS.
>

For that set of requirements you are limited to the possibility #1, #3
or #4 from the set I wrote up earlier.

To always bump, and with server-first style you need to start with these
ssl_bump rules in PRX3:

  ssl_bump peek step1
  ssl_bump stare
  ssl_bump bump

... adding terminate or splice actions as needed for non-caching of
traffic which has issues with the bumping or you are prohibited from
decrypting.

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

Re: SSL Bump with HTTP Cache Peer Parent

sam.handley

On 13/12/18 2:12 pm, Amos Jeffries wrote:

> [ please keep the traffic on-list. If you want private assistance I do
> consult for a small fee. ]
>
>
> On 13/12/18 2:51 pm, Sam Handley wrote:
>> On 13/12/18 12:00 pm, Amos Jeffries wrote:
>>
>> Thank you for your reply, it seems adding in an extra step could solve it, even if not ideal.
>> Just a few questions about your suggestions./Second is that if PRX1 or PRX2 can be configured as a regular TLS proxy
>> - receiving proxy traffic to a https_port (or any non-Squid software'
>> equivalent). Then it can be used as a cache_peer with 'ssl' option(s). /Would both PRX1 and PRX2 require https_port to be configured?
>
> It would yes. That config setting on the receiving proxy is what makes
> it a "TLS proxy" instead of just a proxy.
>
>
>> We have a limited ability to edit PRX2 and it does not have https_port enabled. /This option restricts you to the dangerous client-first style bumping,
>> but you are already using that. /My experience so far is that performing any kind of bump action after step1 results in the connection being TUNNELLED and not cached by PRX1.
> The only thing which would result in https:// traffic being cached in
> PRX1 is for PRX1 to be doing the decrypt SSL-Bump itself, or acting at a
> TLS proxy.
>
> Traffic which has https:// URL scheme should only ever leave Squid over
> an encrypted connection. Especially when "bump" is happening.
>
>
>> For example,
>> 1.
>> ssl_bump bump step2 all #results in the connection TUNNELLING and no caching.
>>
> Your description earlier was the SSL-Bump and cache happening in PRX3.
>
> PRX1 and PRX2 being regular proxies will see tunnels ... or nothing at all.
>
>
>> 2.
>> ssl_bump peek step2 all
>> ssl_bump bump step3 all #results in the connection TUNNELLING and no caching.
> IIRC, your lack of a Step-1 action implies tunneling.
>
> The "peek" at Step-2 prohibits "bump" being used at Step-3. So even if
> my recollection was incorrect above you get a tunnel from this step-3.
>
>
> To decrypt and cache the traffic needs to be going through one of these
> SSL-Bump sequences:
>
>    bump, terminate, terminate
>    peek, bump, terminate
>    stare, bump, terminate
>    peek, stare, bump
>    stare, stare, bump
>
> The terminate are just there as a catch-all for traffic which bump fails
> for any reason. You could try splice instead of you want, but that will
> also fail sometimes - terminate is the reliable one.
>
>
>> It would be preferred to use server-first if it did indeed cache the content, can you provide a more ideal bump configuration that will still allow us to cache HTTPS.
>>
> For that set of requirements you are limited to the possibility #1, #3
> or #4 from the set I wrote up earlier.
>
> To always bump, and with server-first style you need to start with these
> ssl_bump rules in PRX3:
>
>    ssl_bump peek step1
>    ssl_bump stare
>    ssl_bump bump
>
> ... adding terminate or splice actions as needed for non-caching of
> traffic which has issues with the bumping or you are prohibited from
> decrypting.
>
> Amos
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users


Sorry, still figuring out how to use the mailing list. I will contact you directly about consultation.

I also may have mixed up the order of my proxies. You are absolutely right.

This seems like it might be the best approach.

   ssl_bump peek step1
   ssl_bump stare step2
   ssl_bump bump step3
   ssl_bump splice spliceACL

Re-reading your options 4 sounds like it may work the best for us. It is certainly the one I understand the most.


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