[squid-users] Checking SSL bump status in http_access

[Alex Rousskov]

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.