Re: [squid-users] Checking SSL bump status in http_access
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 squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Checking SSL bump status in http_access
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 squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Checking SSL bump status in http_access
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 OpendiumOnline Safety / Web Filteringhttp://www.opendium.com Enquiries Support - --- sa...@opendium.comsupp...@opendium.com +44-1792-824568 +44-1792-825748 ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Checking SSL bump status in http_access
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 OpendiumOnline Safety / Web Filteringhttp://www.opendium.com Enquiries Support - --- sa...@opendium.comsupp...@opendium.com +44-1792-824568 +44-1792-825748 ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Checking SSL bump status in http_access
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 squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Checking SSL bump status in http_access
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 squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] Checking SSL bump status in http_access
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:sa...@opendium.com Phone:+44-1792-824568 / sip:sa...@opendium.com Support: Email:supp...@opendium.com Phone:+44-1792-825748 / sip:supp...@opendium.com ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
