[squid-dev] Digest related question.

Eliezer Croitoru eliezer at ngtech.co.il
Sat Mar 21 19:06:39 UTC 2015


Hey Jack,

I was trying to understand the picture\drawing you sent me but I was 
unable to understand the logic behind it.

 From the what so ever service that will sit in-front of the client to 
protect it from the outer world issues\crimes to replace the digest is 
quite uncommon if at all being used for paranoid people.

To make sure others will understand I will illustrate it in text:
Assuming a robber gets into a store, what will it do to save itself from 
the identification of the crime?
The movies states that he will wear a mask or will disable the alarm 
system before or through the crime.
The reality proves that cyber crimes are done by these who think that 
they are smart and think that the user is stupid.
I will not tell that all users are stupid but there are some that would 
see for example an "exe" file and will assume that it's less safe then a 
RPM.
The reality proves that there is always the possibility for a crime and 
even if a crime investigator(In the movies) will prove that someone 
fingerprint matches the one stored in the DB there is always the doubt 
that someone switched the fingerprint in the DB in a way that only a 
cyber crime in a International level would be able to do that and in 
this case he will be a con artist(in the CPU+DISK+OTHERS worlds).

How much of these are able to meet in person like that on the street 
every day?
They will be afraid to show their face on earth or even to talk to a 
police man.(From the movies..)

And back to the Digest way of work.
I am unable to understand if the ATS plugin do digest the files and then 
run a whole logic after the operation was done.

If a trust is an issue then the operation must be handled after a digest 
test for the file(what so ever digest that anyone will apply that seems 
reasonable to him) and only then.
When the trust is not an issue then we can run a HEAD request before any 
GET request or to abort the download after a simple fetch of some of the 
information.
 From my point of view on the world of computer science, no-one learns 
how to be a cyber crime con-artist as a profession in a university.
So first, we trust the Internet and then we find the culprit to any issue.
(IRC channels can be trust worthy enough in some cases..)

The main difference between what I propose, would be a non 302 response.
As Henrik mentioned the headers are "required" by some programmers or 
clients as a part of an API or traffic issues investigation.
The current CODE is outside of squid and there for cannot do anything 
related to headers directly.
StoreID enbables for squid to do a very unique thing which was not there 
before.
It allows the admin to "rewrite" the url to an internal one and in case 
that this do exist in the cache DB it would always return the user a 
*forged* response while the user will only notice that after inspecting 
the response headers.
It is a strict violation of the RFC of HTTP in any way possible and even 
one of the worst that might be possible.
It is available on the Internet to anyone out-there and it reflects 
directly to the service Admin.
It also means that the service Admin will be held responsible for many 
legal aspects of the service operation.
For some time users used to reflect issues into the squid-users or 
squid-dev list while these might had legal aspects rather then technical 
level questions.

I do not talk about something different at all.
If indeed the plugin allows the user\admin to redirect into a new url 
using a 302 response, most users will feel much better with it while 
they might understand or not if they trust their ISP or admin.

I do not know if header splicing is necessary or not and it depends on 
the only thing from a user point of view, Do I as a user trust my ISP or 
do not?

To this question I will answer gladly that I do trust them!
Compared to them I have a friend that told me that some admin told 
him(on the phone) that he would allow him strictly to abuse his network 
for cyber crimes and since then he switched his ISP to another which he 
trusts more.
I have also been asked couple times about what to do in a case which We 
do not trust the ISP.
In this case the next question would be about, do we even trust the 
content provider.
Anyone out-there on the Internet can now read about StoreID and 
understand that I wrote it to help and to not harm.

Once upon a time I met this nice guy in a shoe store. He wanted to buy 
some shoe and the seller told him "I want to sell you this and that and 
this and that".
The client started with, show me this one.
Then he told him "it doesn't fit me".
The shoe store sales guy went with him for an hour and He didn't found 
anything that will fit his feet and feeling.
The seller called the other guy(switching a shift), the other sales guy 
comes in with no degree and past and throws to the air "What would feels 
you right compared to all what you have tested until now?"
The client eventually finds someone that asks him a thing or two and 
tells him "let's try what you have again".
The sales man looks at the feet of the client and tells him "I think you 
should try this one for more then couple seconds and later you will see 
how you will find the right shoe for you."(even if it's not in my store)
This client came back to this shoe store more then couple times to just 
ask this specific seller a very specific question which was not related 
to shoes at all.

All The Bests,
Eliezer Croitoru

* Squid 3.5.2 is ready and will be published this week with your and 
others help.
* Still learning more about HTCP.
* The stories are from reality and are non-fiction at all and is here to 
give this list hope, happiness and much more.

On 19/03/2015 18:59, Jack Bates wrote:
>
> Here is what the Traffic Server plugin currently does:
> http://nottheoilrig.com/trafficserver/untitled.pdf
>
> I understand you are talking about something different,
> can you point out the differences from what the plugin does,
> to help me understand why header splicing is necessary?



More information about the squid-dev mailing list