Re: Call for Adoption: Encrypted Content Encoding

Am 02.12.2015 um 12:32 schrieb Walter H.:
> On 02.12.2015 11:16, Cory Benfield wrote:
>>> On 1 Dec 2015, at 20:12, Walter H.<Walter.H@mathemainzel.info>  wrote:
>>>
>>> On 01.12.2015 16:14, Amos Jeffries wrote:
>>>> The question was how is encrypting using file-based methods safer than
>>>> encryption with this draft method. My conclusion: it is not.
>>> file-based methods won't get decrypted automatically without any 
>>> mechanism on client side;
>>> this draft method does.
>> You’re right: without this draft the file-based methods won’t get 
>> decrypted, no. It’s worse: they get *executed*.
> you are talking about content, this draft has no influence, because it 
> is not encrypted;
>
> lets talk about the following case:
>
> someone places somewhere an IMG-HTML-Tag
>
> and would you really tell me, that in case this IMG-HTML-Tag points to 
> such an encrypted file, this
> will never be shown/executed/what ever?
>
> as I said, in case the UA has no knowledge about this draft, nothing 
> happens;
> but with knowledge of this draft, you can't tell me that the encrypted 
> content won't be shown;
>
Today everybody can place an IMG tag (or iframe tag) pointing to 3rd 
party content. Who cares if malware is delivered this way if setting the 
reference gives some money. If you are instead able to push your content 
encrypted to some CDN servers around the world then you have confidence 
it will not be modified uncontrolled.

> to bring you notice the difference:
>
> without this draft: someone has to explicitly a .js, .vbs, ... in the 
> HTML-Tag or the server MUST send the
> MIME type for the content in case it is .jpeg or other not harmful;
> and this can be filtered easily;
>
> with this draft there doesn't not exist any way of filtering it; 
> because the URL looks as it should, but the content is something 
> different;
>
> in case you use a proxy, then with this draft, the proxy can't filter 
> anything; without, it can;
>
The usage of TLS disables the filtering in a proxy unless the proxy is 
breaking the TLS security.

>> Decryption itself should not be a malware distribution vector. The 
>> only way it could be is if the decryption code itself is vulnerable 
>> to a code injection attack of some form (e.g. buffer overflow). 
>> That’s certainly *possible*, but it’s not standard practice.
>>
>> However, user-agents automatically process plenty of file formats 
>> already.
> yes but without this draft they can't do anything in case the content 
> is encrypted ...
> with this draft, the HTTP request tells the server to hand out all 
> neccessary and the malware is on your client ...
>
This is not true. Today it is no problem to deliver encrypted content 
and some JS to decrypt it. Even worse steganography may be used to hide 
the fact that encryption was used at all.

Received on Wednesday, 2 December 2015 15:00:16 UTC