ietf-openproxy
[Top] [All Lists]

RE: LateClearance content encoding

2002-11-07 02:01:31

It is all arround a possible virus that could be transfered.

We could say that a client that supports this content encoding will delete and 
not execute the data if it does not receive the clearance but the error message 
even if the data itself is not encrypted.

But I am concerned that this is not sufficient and too dangerous. The client 
may write the data to a file and cannot guarantee for other parts of the 
operating system not to access that data before it gets a chance to delete it 
again.

It will it also make easier for an attacker to use vulnerabilities in the 
client's implementation to access the data which should not ne used.
For example the attacker could just be able to add the Accept header to the 
request, and the data is then transfered, the client does its job and is not 
aware of the "do not use the data" flag.

Maybe there are some other scenarios where the flag itself is sufficient so 
that encryption could be optional?

Martin

-----Original Message-----
From: The Purple Streak, Hilarie Orman 
[mailto:ho(_at_)alum(_dot_)mit(_dot_)edu]
Sent: Wednesday, November 06, 2002 8:21 PM
To: Martin Stecher
Cc: ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: LateClearance content encoding


It's a nice solution, but it's important to know what the problem is.

I'm unclear about why the data must be encrypted.  The only 
point is to
keep the enduser from using the data, so it would seem sufficient to
just have the late clearance flag alone - let the client decide how it
wants to handle data while it is in the uncleared state.  Why is this
insufficient?

Hilarie



<Prev in Thread] Current Thread [Next in Thread>