On 07/21/2015 04:25 AM, Amos Jeffries wrote: > On 21/07/2015 9:42 a.m., Alex Rousskov wrote: >>>> adaptation_access icapS aclIcap >>>> adaptation_access icapN !aclIcap >>>> >>>> >>>> aclIcap can be a received_encrypted ACL. What ACL expression would you >>>> suggest for aclIcap if received_encrypted is not available?
>>> # top 5 criteria - TLS transactions >>> acl aclIcap allof HTTPS >> What is "HTTPS" ACL? If it is based on the URI scheme, then AFAIK, it is >> not going to work because it will not match bumped http:// requests (at >> least). > Good you have seen those. That is what the HTTPbis WG call > "opportunistic encryption" traffic. I bet many (most?) of them are actually regular HTTP requests sent over TLS/SSL connections. There is nothing opportunistic about them. > This is where the security requirements and your ACL use-case differ. > Security requirements for those requests is that they be handled as per > any other http:// - any encrytpion or security applied is *optional*. No requirement can _force_ something to be optional! If the use case demands that requests received over TLS are sent to icapS service, then they should be sent to the icapS service, even if some of the corresponding request owners would not mind to see their requests going to the icapN service. > recieved_encrypted ACL seems to assume they are broken HTTPS and matches > for them. recieved_encrypted ACL does not assume anything in this case. It simply says that they were received over a TLS or SSL connection. > What I'm getting at here is that these are more good candidates for the > performance-oriented admin to skip ICAPS processing if they want. Even > though they were bumped. I agree that in some deployments there may be more good candidates to skip the icapS service. > The new ACL fails to let that happen Nope. The new ACL is just an ACL. It does not force any requests to be sent anywhere. If the admin finds the new ACL more useful than other ACLs, they will use it. Some may petition for other ACLs to be added. We are not removing the "port" ACL even though it does not know that port 80 traffic is not always HTTP. Similarly, it is perfectly fine to add an ACL that does not know that HTTP WG calls some encryption "opportunistic". In the future, received_encrypted parameters or new ACLs will identify opportunistic encryption if there is demand for that. This is a normal process of Squid and HTTP evolution. >>> False-negative: >>> >>> Imagine that icapN was REQMOD and icapS a RESPMOD service. With >>> URL-rewrite, eCAP or such modification of the reply making it https:// >>> (tainted). >> >> I assume you meant "making it http:// (tainted)". >> > > No, this example eCAP taints it but leaves it as https://. So both the > inbound and outbound connections are fully using TLS. But the ACL > matches as if it were non-TLS connections. This is not a false negative. The ACL covers more than inbound and outbound connections. It also covers connections to adaptation services (network connections for ICAP and loadable module calls for eCAP). In the current implementation, adaptation connections other than those to the Secure ICAP adaptation services taint the transaction. This tainting is intentional -- there is no "false" in this "negative". If you think we should change the default for eCAP and plain ICAP from "taint" to "do not taint", we can discuss that. It is just a default. I believe the current "conservative" settings are the best starting point, but am happy to discuss the advantages of a different default. > This will conflict with later cached handling, and logging info. Which > properly treats is as fully TLS received. I do not see any conflict. The ACL just does not match if the transaction was sent to an eCAP service. This is intentional as discussed above. Why is that a conflict? What things are conflicting? >>> Using received_encrypted the transactions; >>> during request will match, so icapN does not get used. >>> during reply will not match, so icapS does not get used. >> >> Kinkie has not asked for false-negatives so you are moving the goal >> posts. More importantly, I do not see a false negative in your example. >> Yes, an eCAP adaptation will "taint" the transaction, but it does not >> lead to a "false negative", just a "true negative" (i.e., the negative >> decision matches what the admin should expect in this case). > They expect that two fetches of the same URL from the same client one > MISS gets marked non-TLS-received the other HIT as TLS-received ? No. They just do not use eCAP and/or caching. > I see complaints in that future. The new ACL caching support is limited to cases where cached responses can be correctly classified by their URIs. We should document this better, but the implementation covers a lot of use cases we know about. Users that want better caching support can enhance Squid to provide that support. The changes to do so are not trivial, there is currently no demand for them, exact feature requirements and use cases are not yet clear, so it is wrong to force us to implement them now. >> If those true negatives are not desirable, we will make that hard-coded >> decision configurable by the admin (who knows whether the adaptation >> service should "taint" -- Squid does not know that). >> >> >>> False-positive: >>> >>> Imagine that icapS was REQMOD and icapN a RESPMOD service. Same >>> modifications by url-rewriter. This time re-writing to http:// URL >>> matching cached content. >>> >>> Using received_encrypted the transactions; >>> during request will match, so icapS gets used. >> >> Do you see this as a false positive? I assume you do not. If you do, >> please explain why. >> >> >>> during reply will *still match*, so icapN does not get used >> >> Cache hits do not go through RESPMOD services so this example does not work. > > The original request that got cached never attached the ACL so whatever > processing was desired for applying to secure responses was never applied. > The ACL is matching this insecure and tainted response as if it were > TLS received. So the non-secure processing that was suppsed to have been > omitted for it whas been done. Sorry, but you need to formulate this example from scratch. Your false-positive example above does not work -- icapN does not get used not because something is wrong with the new ACL but because Squid does not support RESPMOD services for cache hits. I cannot combine your original broken example with the conditions you have added above without the risk of fighting another straw man. If you decide to construct another example, please keep my above comments about caching support in mind. There is no need to construct an example outside the current ACL scope. >> When/if somebody adds post-cache RESPMOD support, AFAICT, the icapN >> _will_ get used because the current ACL implementation assumes that >> cached content source corresponds to the cached URI scheme. Christos has >> disclosed that simplification or shortcoming. Again, this is something >> we can improve in the future if needed. We already have a blueprint for >> better caching support actually. > No. Christos wrote this: > " > NOTE: Currently there is not any mechanism to indicate if a cached > object came from secure source or not, so we assume that all hits for > secure requests are secure too. > " This disclosure matches what I said. > The cache hits rely on the request markings to determine the HIT > matching. In your example, you said that there is a HIT. Thus, the requests matched. Thus, the [rewritten] request URI is http:// (not https://). Thus, bugs notwithstanding, the new ACL will not match the HIT response in your example. > In this case we have a https:// (secure, TLS-received) marked > request being re-written with non-TLS URL and delivered a HIT originated > from a non-TLS server. Yes, such rewriting and hits are possible, with or without the new ACL. I do not see a false positive here. Bugs notwithstanding, the new ACL should not match the HIT response because it has an http:// URI. We do need to move the information from Christos' NOTE to squid.conf.documented and expand it so that admins needing better caching support know that it is not available (yet). Alex. _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
