"content filtering" may filter only content while a generic filter may filter anything
including malware that uses PUT, OPTION and/or HEAD to upload credit card data.
So it depends on what you want to filter. If it is downloadable content only, you can stick with filtering GET POST CONNECT.
Marcus
On 09/28/2015 03:34 PM, Eliezer Croitoru wrote:
Thanks for the insight.
You are right, it is not well defined.
I will try to rephrase or clear couple things.
Mainly content filtering is for offensive content.
This by definition is not the goal of a security related product that would not like to reveal the client attempts to reach the site using a HEAD request.
The main issue is about offensive content in the presentation layer.
Actually with squid it's not such a great issue but the main purpose of my question is to verify what would be allowed to be bypassed content filtering.
I will do more to clarify the issue.
A HEAD request will never include a body and will might contain offensive content in the HEADERS but it's not something that the user (unless he is an admin) will probably never see.
So a HEAD cannot ever contain a body response and there for might not require filtering.
A PUT request can contain a response body but it is not used and was not designed to send body content and else then that browsers do not really implement support for it.
Basically the main HTTP methods that are being used by browsers to retrieve content and present it are GET and POST.
I really have not seen a webpage that is built to work with PUT or OPTIONS only methods.
So an OPTIONS method blocking is something that might worth checking in a security environment but if the content filtering is to block abusive content then I probably do not need to invest time on an
OPTIONS request.
So after defining that the main subject as abusive content in the body part of the message, POST and GET are a must to check but OPTIONS might not be required.
I must say as a side note that for small setups it might not really be a big of a difference but for large setups, if there is no real need to inspect the content then I can just reduce the delays for
such requests by a few 100s ms.
The main reason I am asking this is due to the fact(not saying that they are right or wrong) that I have seen it being use in the real world.
I have seen something like this:
icap_enable on
icap_service service_req reqmod_precache icap://127.0.0.1:1344/service
acl inspect_methods method GET POST CONNECT
adaptation_access service_req allow inspect_methods
adaptation_access service_req deny all
Thanks,
Eliezer
On 27/09/2015 20:58, Alex Rousskov wrote:
Your question is impossible to answer correctly until you define
"unwanted content". In other words, you need to define what you want to
block (in general, non-HTTP terms) before it is possible to identify a
subset of HTTP messages that can deliver the corresponding content. What
is "desired" by some is "unwanted" by others, so we cannot guess what
_your_ blocking objectives are.
Alex.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
