Re: Call for Adoption: Encrypted Content Encoding

On 1/12/2015 8:53 a.m., Walter H. wrote:
> On 30.11.2015 13:33, Amos Jeffries wrote:
>>
>> Also how is this different from malware infected machines uploading
>> encrypted payloads today?
> in case this malware is encrypted in an archive container, there is no
> problem, because
> no key, no harm;

In the case that the server has a key to send in Encryption-Key it is
perfectly capable of decrypting the object itself and AV scanning it.

In the case that the server does not have a key, then the messages it
outputs do not have a key either. Ergo as you said "no key, no harm;".

So, no difference at all you mean.

Also noteworthy is that potentially an AV scanner along the way does
have the key and can scan the content. Even when the server does not.
This also goes for both todays existing situation and the draft method.


> 
> in case this malware is not encrypted in an archive container like .zip
> or .rar,
> the server has the change to clean it ...
> 

The case where the upload is not encrypted is irrelevant to my question.
I asked about how this draft was worse than the _current existing_ case
where uploaded content is encrypted using a container format other than
what is described in this draft.


>> IMHO those opaque encrypted .rar/.zip files are a more fertile and
>> safe-from-inspection vector for malware to be using than this proposal
>> where the raw Content-Type etc are exposed for vetting.

> this is a wrong view to the fact, that .rar/.zip can be inspected as
> long they are not encrypted;

The attack vector is that they *are* encrypted. Telling me its a "wrong
view" does not counter the fact that there is active working malware
code out there doing it yesterday.

The question was how is encrypting using file-based methods safer than
encryption with this draft method. My conclusion: it is not.


> just the same as raw content;
> if they are encrypted they won't be any dangerous, because no key, means
> no access;
> but for this proposal, the server has no change doing anything against,
> and at client side,
> the malware may get start automatically, because of raw Content-Type ...
> 

There is the attack vector that needs addressing. BUT exactly that, it
needs addressing; not throw-the-whole-draft-away nor throw-privacy-away.

The first step in mitigation is that the crypto needs to be stripped
away for the auto-execute to actually work. Which as Cory mentioned
already requires the victim to have a key. See above for the two key
cases from server perspective.


To be honest the malware I'm aware of was encrypted .chm and .exe (not
.rar/.zip - thats just the types mentioned as examples earlier). So yes,
the file-based encrypted content can still auto-execute based on
Content-Type if the attacker is smart. Or they just use a wrapper
payload that both decrypts and translates into a weaponized form (ie
decrypt+extract archive). Auto-execute is the easy part for the attacker.

Amos

Received on Tuesday, 1 December 2015 15:14:45 UTC