- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Tue, 1 Dec 2015 01:33:27 +1300
- To: ietf-http-wg@w3.org
On 1/12/2015 12:50 a.m., Roland Zink wrote: > Am 30.11.2015 um 12:06 schrieb Eliot Lear: >> Hi, >> >> On 11/29/15 11:20 AM, Walter H. wrote: >>> I'd say this is the wrong answer, this can be done alternativly as >>> used to do >>> (pushing an encrypted .rar or .zip is exactly this use case with >>> advantage, >>> there is no implicit malware impact ...) >>> >>> for security reason exactly this way you mentioned must be forbidden; >>> there mustn't be a way pushing malware to a server, >>> which the server itself has no possibility to clean it ... >> I have to agree that this is a big issue. Here's the problem: we like >> to say that we would devolve the responsibility to the end user who is >> pushing the file. The problem occurs when the end user who is pushing >> the file has been broken into and her credentials have been stolen. >> That's the classic BOTnet model. And so this poses a new vector that >> wasn't there before. > How is this different from the current web model allowing ads to be > served from everywhere? There is no guarantee that the content can't be > hijacked. Also how is this different from malware infected machines uploading encrypted payloads today? 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. >> But I would suggest that there are mitigations to this attack, one such >> being that the content is attested to by a malware protection system >> (McAfee, Kaspersky, etc) such that server might trust it, and might >> otherwise reject such content. > Do you want to allow third parties access to the content? >> In as much as we can have the discussion as to how to mitigate the >> attack, I'm +1 for adopting. Otherwise -1. Mitigate in the same ways that transferring encrypted files over HTTP/FTP/gopher/etc right now are handled. I.e. this is not a new vector. Amos
Received on Monday, 30 November 2015 12:34:30 UTC