Best way to prevent squid from bumping CONNECTs

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

Best way to prevent squid from bumping CONNECTs

Scott
Hi,

my experience with ssl_bump is that it tries to bump SSL connections whether
presented to Squid explicitly or implicitly.

I have a device with two pieces of software, one configured with Squid
explicitly, one that requires intercept (via WCCP).

So both explicit CONNECT messages arrive at squid (on 3128/TCP) and SSL (on
443/TCP).

When simply configuring `ssl_bump bump host_acl' the Squid logs show Squid
trying, and failing, to bump CONNECT requests.  They may be failing due to
certificate issue most likely, I'm not sure.  I can't add to the certificate
store of the software that has the proxy configured (i.e. it will not permit
bumping).

Is it expected that Squid will bump/splice CONNECT requests?
Because not all CONNECT sessions are SSL, if the CONNECT destination does not
begin a TLS handshake will Squid revert to simply creating a TCP tunnel
instead of bumping?

My workaround has been to simply add `!CONNECT' to the `ssl_bump host_acl'
statements.  Squid will happily bump the SSL sessions and proxy the CONNECT
sessions.

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

Re: Best way to prevent squid from bumping CONNECTs

Alex Rousskov
On 4/27/20 12:21 PM, Scott wrote:

> my experience with ssl_bump is that it tries to bump SSL connections whether
> presented to Squid explicitly or implicitly.

* For http_port configured with an ssl-bump flag, HTTP CONNECT tunnels
are sent to the SslBump code.

* For https_port configured with an ssl-bump flag, all traffic is sent
to the SslBump code (by faking a corresponding HTTP CONNECT request).

* All other traffic is not sent to the SslBump code.

SslBump code honors ssl_bump rules when inspecting and
splicing/bumping/terminating/etc. traffic.


> When simply configuring `ssl_bump bump host_acl' the Squid logs show Squid
> trying, and failing, to bump CONNECT requests.  They may be failing due to
> certificate issue most likely, I'm not sure.  I can't add to the certificate
> store of the software that has the proxy configured (i.e. it will not permit
> bumping).

* If you do not want Squid to use SslBump features on traffic arriving
on port X, then do not add the ssl-bump flag to that port X.

* If you want to use the same port for traffic that should be bumped and
traffic that should not be inspected beyond step1, adjust your ssl_bump
step1 rules to distinguish the two kinds of messages.

Needless to say, you decide which traffic goes to which listening port
and whether a single port serves multiple traffic categories.


> Is it expected that Squid will bump/splice CONNECT requests?

It depends -- some CONNECT tunnels are expected to be inspected and
bumped, spliced, terminated, etc., according to the configuration.
Please see above for the details. Squid does not know what it will find
inside the CONNECT tunnel until it starts inspecting that tunnel.


> Because not all CONNECT sessions are SSL, if the CONNECT destination does not
> begin a TLS handshake will Squid revert to simply creating a TCP tunnel
> instead of bumping?

SslBump expects SSL/TLS traffic inside CONNECT tunnels that it is
configured to inspect. If an inspecting Squid decides that it got some
other traffic, Squid follows the on_unsupported_protocol configuration.


> My workaround has been to simply add `!CONNECT' to the `ssl_bump host_acl'
> statements.  Squid will happily bump the SSL sessions and proxy the CONNECT
> sessions.

AFAICT, that workaround cannot work on modern Squids because all traffic
subject to ssl_bump rules will start as a (real or fake) CONNECT request.


HTH,

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

Re: Best way to prevent squid from bumping CONNECTs

Scott
In reply to this post by Scott
> Date: Mon, 27 Apr 2020 15:09:03 -0400
> From: Alex Rousskov <[hidden email]>
> To: [hidden email]
> Subject: Re: [squid-users] Best way to prevent squid from bumping CONNECTs
>
> On 4/27/20 12:21 PM, Scott wrote:
>
> > my experience with ssl_bump is that it tries to bump SSL connections whether
> > presented to Squid explicitly or implicitly.
>
> * For http_port configured with an ssl-bump flag, HTTP CONNECT tunnels
> are sent to the SslBump code.
>
> * For https_port configured with an ssl-bump flag, all traffic is sent
> to the SslBump code (by faking a corresponding HTTP CONNECT request).
>
Indeed.  I have ssl-bump on both my http_port and https_port (intercept).

These `fake' CONNECT requests I assume only contain the IP address of the
upstream server, not the hostname, as intercepted SSL connections are TCP
OPENs.

Am I right then in saying that using ssl::server_name is useless for bumped
intercepted connections?  (Even if Squid did reverse proxy the IP it would be
fairly unreliable).

> > Because not all CONNECT sessions are SSL, if the CONNECT destination does
> > not begin a TLS handshake will Squid revert to simply creating a TCP
> > tunnel instead of bumping?
>
> SslBump expects SSL/TLS traffic inside CONNECT tunnels that it is
> configured to inspect. If an inspecting Squid decides that it got some
> other traffic, Squid follows the on_unsupported_protocol configuration.

Thanks, I was unaware of that option.

> > My workaround has been to simply add `!CONNECT' to the `ssl_bump
> > host_acl' statements.  Squid will happily bump the SSL sessions and proxy
> > the CONNECT sessions.
>
> AFAICT, that workaround cannot work on modern Squids because all traffic
> subject to ssl_bump rules will start as a (real or fake) CONNECT request.

I'm running `Squid Cache: Version 5.0.1-20200312-r8a511d5e0'
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Best way to prevent squid from bumping CONNECTs

Alex Rousskov
On 4/30/20 12:10 PM, Scott wrote:

>> * For http_port configured with an ssl-bump flag, HTTP CONNECT tunnels
>> are sent to the SslBump code.
>>
>> * For https_port configured with an ssl-bump flag, all traffic is sent
>> to the SslBump code (by faking a corresponding HTTP CONNECT request).


> These `fake' CONNECT requests I assume only contain the IP address of the
> upstream server, not the hostname, as intercepted SSL connections are TCP
> OPENs.

Modern Squid replaces TCP-derived destination IP address with TLS
SNI-derived domain name when generating the second fake CONNECT request.
The second CONNECT is generated during SslBump step2, after parsing TLS
client handshake.


> Am I right then in saying that using ssl::server_name is useless for bumped
> intercepted connections?

It may be useful for ACLs checked during SslBump step2 (because it will
check the TLS client SNI-derived domain name) and during step3 (when it
will check TLS server certificate-derived CN and SubjectAltName).


HTH,

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

Re: Best way to prevent squid from bumping CONNECTs

Scott
On Thu, Apr 30, 2020 at 04:05:43PM -0400, Alex Rousskov wrote:

> On 4/30/20 12:10 PM, Scott wrote:
>
> >> * For http_port configured with an ssl-bump flag, HTTP CONNECT tunnels
> >> are sent to the SslBump code.
> >>
> >> * For https_port configured with an ssl-bump flag, all traffic is sent
> >> to the SslBump code (by faking a corresponding HTTP CONNECT request).
>
>
> > These `fake' CONNECT requests I assume only contain the IP address of the
> > upstream server, not the hostname, as intercepted SSL connections are TCP
> > OPENs.
>
> Modern Squid replaces TCP-derived destination IP address with TLS
> SNI-derived domain name when generating the second fake CONNECT request.
> The second CONNECT is generated during SslBump step2, after parsing TLS
> client handshake.
>
>
> > Am I right then in saying that using ssl::server_name is useless for bumped
> > intercepted connections?
>
> It may be useful for ACLs checked during SslBump step2 (because it will
> check the TLS client SNI-derived domain name) and during step3 (when it
> will check TLS server certificate-derived CN and SubjectAltName).

acl tcp_open_connect_sslbump at_step SslBump1
acl ssl_splice_sni ssl::server_name "/usr/local/etc/squid/acls/splice_sni"
acl guest_net_src src x.y.z.0/24

ssl_bump peek tcp_open_connect_sslbump
ssl_bump splice ssl_splice_sni
ssl_bump bump guest_net_src
ssl_bump splice

where I splice instead of bump for destinations that are often used with
certificate pinning software (.apple.com with iOS for example).

https://wiki.squid-cache.org/Features/SslPeekAndSplice says "At no point
during ssl_bump processing will dstdomain ACL work".

Does that also imply that `ssl::server_name' won't work (or is not required)
for `http_access' statements?

I have config like this:

acl no_proxy_dstdomain dstdomain "/usr/local/etc/squid/acls/no_proxy_dstdomain"
http_access deny no_proxy_dstdomain
acl no_proxy_sni ssl::server_name "/usr/local/etc/squid/acls/no_proxy_dstdomain"
http_access deny no_proxy_sni

Are the last two lines redundant?
Or are they required for spliced connections?
Or should I just convert those lines into ssl_bump terminate no_proxy_sni ?

And finally, I want to use a different outgoing tcp address for intercepted
connections.  What's the best ACL to match those?  Or should I just match
explicit proxy connections by port? (ie !myport 3128)

Thanks for your help,
Scott

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

Re: Best way to prevent squid from bumping CONNECTs

Alex Rousskov
On 5/3/20 10:41 PM, Scott wrote:

> acl tcp_open_connect_sslbump at_step SslBump1
> acl ssl_splice_sni ssl::server_name "/usr/local/etc/squid/acls/splice_sni"
> acl guest_net_src src x.y.z.0/24
>
> ssl_bump peek tcp_open_connect_sslbump
> ssl_bump splice ssl_splice_sni
> ssl_bump bump guest_net_src
> ssl_bump splice


> where I splice instead of bump for destinations that are often used with
> certificate pinning software (.apple.com with iOS for example).


> https://wiki.squid-cache.org/Features/SslPeekAndSplice says "At no point
> during ssl_bump processing will dstdomain ACL work".

I have not tested this, but I would expect the dstdomain ACL to work
during SslBump steps using the destination address from the (real or
fake) CONNECT request URI. It is possible that, for the author of that
wiki statement, that kind of functionality is equivalent to "not work",
but I personally would not phrase it that way.


> Does that also imply that `ssl::server_name' won't work
> for `http_access' statements?

No, it does not. Both ACLs should "work". Naturally, both ACLs have
their own limitations and intended purposes. If you find problems with
their documentation in squid.conf.documented (or want to improve it),
please consider filing a bug report (or submitting a pull request). You
can also improve the wiki page, of course, but I recommend coordinating
with the paragraph author before changing that paragraph:

https://wiki.squid-cache.org/action/diff/Features/SslPeekAndSplice?action=diff&rev1=19&rev2=20



> I have config like this:

> acl no_proxy_dstdomain dstdomain "/usr/local/etc/squid/acls/no_proxy_dstdomain"
> http_access deny no_proxy_dstdomain
> acl no_proxy_sni ssl::server_name "/usr/local/etc/squid/acls/no_proxy_dstdomain"
> http_access deny no_proxy_sni

> Are the last two lines redundant?

I bet there are transactions (or transaction processing steps) that
either one of the two ACLs will match while the other will not, but I
have not studied this in detail.


> Or are they required for spliced connections?

"Required" may be too strong of a word because, as you said below, you
can probably accomplish similar outcome using terminate rules. However,
the details of that outcome would differ, so I can imagine that
http_access is the right or the best approach in _some_ cases.


> Or should I just convert those lines into ssl_bump terminate no_proxy_sni ?

A matching "http_access deny" forces Squid to generate an HTTP error
response. If that happens during SslBump processing, the connection with
the client will be bumped (in hope) to deliver that response. If such
bumping is no longer possible, I am not sure what happens, but I would
expect Squid to close the underlying TLS/TCP connection.

A matching "ssl_bump terminate" rule closes the client TLS/TCP
connection without generating an HTTP error response. It can only match
during SslBump processing.

Use appropriate rule(s) to accomplish what you actually want to
accomplish. And test that your expectations match what Squid is doing.

I apologize that I cannot give simpler yes/no answers to your
(implicitly loaded) questions. I hope the above responses give you
enough information to find the answers you are looking for.


> And finally, I want to use a different outgoing tcp address for intercepted
> connections.  What's the best ACL to match those?  Or should I just match
> explicit proxy connections by port? (ie !myport 3128)

I would start by testing the myportname ACL(s).


HTH,

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

Re: Best way to prevent squid from bumping CONNECTs

Amos Jeffries
Administrator
On 5/05/20 4:31 am, Alex Rousskov wrote:

> On 5/3/20 10:41 PM, Scott wrote:
>
>> acl tcp_open_connect_sslbump at_step SslBump1
>> acl ssl_splice_sni ssl::server_name "/usr/local/etc/squid/acls/splice_sni"
>> acl guest_net_src src x.y.z.0/24
>>
>> ssl_bump peek tcp_open_connect_sslbump
>> ssl_bump splice ssl_splice_sni
>> ssl_bump bump guest_net_src
>> ssl_bump splice
>
>
>> where I splice instead of bump for destinations that are often used with
>> certificate pinning software (.apple.com with iOS for example).
>
>
>> https://wiki.squid-cache.org/Features/SslPeekAndSplice says "At no point
>> during ssl_bump processing will dstdomain ACL work".
>
> I have not tested this, but I would expect the dstdomain ACL to work
> during SslBump steps using the destination address from the (real or
> fake) CONNECT request URI. It is possible that, for the author of that
> wiki statement, that kind of functionality is equivalent to "not work",
> but I personally would not phrase it that way.
>

We do not save the CONNECT tunnel message objects in the TLS handshake
state objects. As such the state needed by dstdomain is not available
during ssl_bump ACL processing.

Only state from the TCP connection and the underway TLS handshake are
guaranteed to be available to the ssl_bump ACLs. Anything else is
best-effort.

 At least that was the situation when that documentation was written.
The bugs we have about other CONNECT state not being available are still
open so I doubt the situation has changed even with the more recent
refactoring.

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

Re: Best way to prevent squid from bumping CONNECTs

Alex Rousskov
On 5/5/20 5:38 AM, Amos Jeffries wrote:
> On 5/05/20 4:31 am, Alex Rousskov wrote:
>> On 5/3/20 10:41 PM, Scott wrote:
>>> https://wiki.squid-cache.org/Features/SslPeekAndSplice says "At no point
>>> during ssl_bump processing will dstdomain ACL work".

>> I have not tested this, but I would expect the dstdomain ACL to work
>> during SslBump steps using the destination address from the (real or
>> fake) CONNECT request URI.

> We do not save the CONNECT tunnel message objects in the TLS handshake
> state objects. As such the state needed by dstdomain is not available
> during ssl_bump ACL processing.

I do not know what you mean by "CONNECT tunnel message objects" and "TLS
handshake state objects" exactly but HttpRequest with the (real or fake)
CONNECT request should exist and be available to ssl_bump and
http_access ACLs during SslBump steps. The dstdomain ACL uses
HttpRequest AFAICT.

Most deployed http_access configurations allow those CONNECT requests
while peeking at TLS; and many broken configurations deny them (too
soon), triggering support queries on this mailing list.


> Only state from the TCP connection and the underway TLS handshake are
> guaranteed to be available to the ssl_bump ACLs. Anything else is
> best-effort.

For intercepted connections, the fake CONNECT request carries
information extracted from the TCP connection and the TLS handshake.

For other cases, there is a real CONNECT request to carry that
information (and more). It is adjusted with SNI info if possible.

At least that is the way SslBump should work in modern Squids. I agree
that many SslBump bugs have been fixed since the quoted wiki paragraph
was written, but the presence of the CONNECT HttpRequest is rather
fundamental since the beginning of Peek and Splice approach because
http_access rules are difficult to write without it, especially because
we did not want to make "step" ACLs officially available for the
http_access rules.


HTH,

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