[whatwg] whatwg Digest, Vol 82, Issue 10

On 2011-01-05 06:10, Boris Zbarsky wrote:
> On 1/4/11 10:51 PM, Glenn Maynard wrote:
>> On Tue, Jan 4, 2011 at 10:53 PM, Boris Zbarsky<bzbarsky at mit.edu>  wrote:
>>> Note that you keep comparing websites to desktop software, but desktop
>>> software typically doesn't change out from under the user (possibly 
>>> in ways
>>> the original software developer didn't intend).  The desktop apps 
>>> that do
>>> update themselves have a lot of checks on the process precisely to 
>>> avoid
>>> issues like MITM injection of trojaned updates and whatnot.  So in 
>>> practice,
>>> they have a setup where you make a trust decision once, and then the 
>>> code
>>> that you already trusted verifies signatures on every change to itself.
>>
>> HTTPS already prevents MITM attacks and most others
>
> I've yet to see someone suggest restricting the asking UI to https 
> sites (though I think it's something that obviously needs to happen).  
> As far as I can tell, things like browser geolocation prompts are not 
> thus restricted at the moment.
>
>> the major attack vector they don't prevent is a compromised server.
>
> Or various kinds of cross-site script injection (which you may or may 
> not consider as a compromised server).
>
>> I thnik the main difference is that the private keys needed to sign
>> with HTTPS are normally located on the server delivering the scripts,
>> whereas signed updates can keep their private keys offline.
>
> Or fetch them over https from a server they trust sufficiently (e.g. 
> because it's very locked down in terms of what it allows in the way of 
> access and what it serves up), actually; I believe at least some 
> update mechanisms do just that.
>
>> That's not a model web apps can mimic: all ways to execute scripts, 
>> in both
>> Javascript files and inline in HTML, would need to be signed, which is
>> impossible with templated HTML.
>
> Agreed, but that seems like a problem for actual security here.
>
>> You don't really know that an installer you download from a server is
>> valid, either.  Most of the time--for most users and most
>> software--you have to take it on faith that the file on the server
>> hasn't been compromised.
>

Considering the fact that StartCOM ( https://www.startssl.com/ ) offers 
free domain based certificates that all major browsers support now 
(IE/Microsoft was a bit slow on this initially),
there is no longer any excuse not to make use of https for downloading 
"securely" or logging in/registering (forums etc), or using "secure" web 
apps.
So leveraging https in some way would be the best solution here, and all 
the https code is allready in the browser code bases anyway.


-- 
Roger "Rescator" H?gensen.
Freelancer - http://www.EmSai.net/

Received on Wednesday, 5 January 2011 08:07:09 UTC