Checking SSL bump status in http_access

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Checking SSL bump status in http_access

Steve Hill

Is there a way of figuring out if the current request is a bumped
request when the http_access ACL is being checked?  i.e. can we tell the
difference between a GET request that is inside a bumped tunnel, and an
unencrypted GET request?

--
  - Steve Hill
    Technical Director
    Opendium Limited     http://www.opendium.com

Sales / enquiries:
    Email:            [hidden email]
    Phone:            +44-1792-824568 / sip:[hidden email]

Support:
    Email:            [hidden email]
    Phone:            +44-1792-825748 / sip:[hidden email]
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Checking SSL bump status in http_access

Amos Jeffries
Administrator
On 17/08/2016 2:22 a.m., Steve Hill wrote:
>
> Is there a way of figuring out if the current request is a bumped
> request when the http_access ACL is being checked?  i.e. can we tell the
> difference between a GET request that is inside a bumped tunnel, and an
> unencrypted GET request?
>

In Squid-3 a combo of the myportname and proto ACLs should do that.

In Squid-4 the above, or the connections_encrypted ACL type.

Amos

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

Re: Checking SSL bump status in http_access

Alex Rousskov
On 08/16/2016 05:12 PM, Amos Jeffries wrote:
> On 17/08/2016 2:22 a.m., Steve Hill wrote:
>> Is there a way of figuring out if the current request is a bumped
>> request when the http_access ACL is being checked?  i.e. can we tell the
>> difference between a GET request that is inside a bumped tunnel, and an
>> unencrypted GET request?


> In Squid-3 a combo of the myportname and proto ACLs should do that.
>
> In Squid-4 the above, or the connections_encrypted ACL type.


In both cases, please be extra careful with CONNECT requests (real or
fake) that precede bumped traffic but also go through http_access rules
and with unencrypted https:// requests that some Squids may receive.

Since bumping is not a instantaneous decision but a long process,
possibly involving several CONNECT requests, and since other traffic,
especially in complicated deployments can have properties similar to
bumped requests, it is often difficult to write correct "this HTTP
request was bumped" ACLs.

This configuration problem should be at least partially addressed by the
upcoming annotate_transaction ACLs inserted into ssl_bump rules:
http://lists.squid-cache.org/pipermail/squid-dev/2016-July/006146.html


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: Checking SSL bump status in http_access

Steve Hill
On 17/08/16 17:18, Alex Rousskov wrote:

> This configuration problem should be at least partially addressed by the
> upcoming annotate_transaction ACLs inserted into ssl_bump rules:
> http://lists.squid-cache.org/pipermail/squid-dev/2016-July/006146.html

That looks good.  When implementing this, beware the note in comment 3
of bug 4340: http://bugs.squid-cache.org/show_bug.cgi?id=4340#c3
"for transparent connections, the NotePairs instance used during the
step-1 ssl_bump ACL is not the same as the instance used during the
http_access ACL, but for non-transparent connections they are the same
instance.  The upshot is that any notes set by an external ACL when
processing the ssl_bump ACL during step 1 are discarded when handling
transparent connections."  - It would greatly reduce the functionality
of your proposed ACLs if the annotations were sometimes discarded part
way through a connection or request.

Something I've been wanting to do for a while is attach a unique
"connection ID" and "request ID" to requests so that:
1. An ICAP server can make decisions about the connection (e.g. how to
authenticate, whether to bump, etc.) and then refer back to the data it
knows/generated about the connection when it processes the requests
contained within that connection.
2. When multiple ICAP requests will be generated, they can be linked
together by the ICAP server - e.g. where a single request will generate
a REQMOD followed by a RESPMOD it would be good for the ICAP server to
know which REQMOD and RESPMOD relate to the same request.

It sounds like your annotations plan may address this to some extent.
(We can probably already do some of this by having the ICAP server
generate unique IDs and store them in ICAP headers to be passed along
with the request, but I think the bug mentioned above would cause those
headers to be discarded mid-request in some cases)

--
  - Steve Hill
    Technical Director
    Opendium    Online Safety / Web Filtering    http://www.opendium.com

    Enquiries                 Support
    ---------                 -------
    [hidden email]        [hidden email]
    +44-1792-824568           +44-1792-825748
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Checking SSL bump status in http_access

Steve Hill
In reply to this post by Amos Jeffries
On 17/08/16 00:12, Amos Jeffries wrote:

>> Is there a way of figuring out if the current request is a bumped
>> request when the http_access ACL is being checked?  i.e. can we tell the
>> difference between a GET request that is inside a bumped tunnel, and an
>> unencrypted GET request?
>
> In Squid-3 a combo of the myportname and proto ACLs should do that.

I think when using a nontransparent proxy you can't tell the difference
between:

1. HTTPS requests inside a bumped CONNECT tunnel, and
2. unencrypted "GET https://example.com/ HTTP/1.1" requests made
directly to the proxy.


--
  - Steve Hill
    Technical Director
    Opendium    Online Safety / Web Filtering    http://www.opendium.com

    Enquiries                 Support
    ---------                 -------
    [hidden email]        [hidden email]
    +44-1792-824568           +44-1792-825748
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Checking SSL bump status in http_access

Alex Rousskov
In reply to this post by Steve Hill
On 08/18/2016 03:18 AM, Steve Hill wrote:
> On 17/08/16 17:18, Alex Rousskov wrote:
>> This configuration problem should be at least partially addressed by the
>> upcoming annotate_transaction ACLs inserted into ssl_bump rules:
>> http://lists.squid-cache.org/pipermail/squid-dev/2016-July/006146.html

> http://bugs.squid-cache.org/show_bug.cgi?id=4340#c3
> any notes set by an external ACL when
> processing the ssl_bump ACL during step 1 are discarded when handling
> transparent connections.

Annotations lifetime is a different problem IMO. If somebody needs
[more] connection annotations, they should extend existing clt_conn_tag
support to arbitrary key=value pairs, probably by adding a configuration
option that names connection-scope keys.

If somebody needs a third annotation lifetime scope, they should propose
to add support for it. For example:

1. Supported: HTTP request (including fake CONNECTs);
2. Supported: Client connection;
3. Proposed:  Compound transaction (e.g., all authenticatING requests
plus the first authenticatED request that follows them; all fake
CONNECTs plus the first bumped HTTP request that follows them).

Needless to say, compelling use cases must be presented to justify this
addition/complication along with a firm definition of which individual
transactions belong to the new scope, keeping the "HTTP is stateless"
mantra in mind.


> It would greatly reduce the functionality
> of your proposed ACLs if the annotations were sometimes discarded part
> way through a connection or request.

This is a separate issue, but annotations set by annotate_client ACL
will persist for the client connection lifetime and annotations set by
annotate_transaction ACL will persist for the transaction lifetime
(e.g., a single fake CONNECT request). See above if you need a
different/new lifetime scope. I recommend avoiding the term "request"
for labeling that new scope even if it is convenient for you to think of
all fake CONNECT requests as a single request.


> Something I've been wanting to do for a while is attach a unique
> "connection ID" and "request ID" to requests

Yes, we already do that (in clients and servers) for testing purposes.
And some adaptation services do that to match responses with requests,
as you have mentioned. Adding that support to Squid would be a useful
feature. Official support must account for SMP needs and restarts, but
it is certainly doable.


Cheers,

Alex.

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

Re: Checking SSL bump status in http_access

Alex Rousskov
On 08/18/2016 08:54 AM, Alex Rousskov wrote:
> 1. Supported: HTTP request (including fake CONNECTs);

To clarify, s/fake CONNECTs/a single fake CONNECT/

> 2. Supported: Client connection;

> 3. Proposed:  Compound transaction (e.g., all authenticatING requests
> plus the first authenticatED request that follows them; all fake
> CONNECTs plus the first bumped HTTP request that follows them).

Alex.

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