W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > November 2012

Re: Webcrypto - project example (and issues)

From: Aymeric Vitte <vitteaymeric@gmail.com>
Date: Fri, 23 Nov 2012 13:43:26 +0100
Message-ID: <50AF6F6E.1060106@gmail.com>
To: Ryan Sleevi <sleevi@google.com>
CC: public-webcrypto-comments@w3.org, Anders Rundgren <anders.rundgren@telia.com>
See answers below, I am trying to give some examples that might be a 
small subset of what will be needed or what people will invent in the 
future, browsers will be used to do networking, I am not asking to redo 
the web security model but to add  the possibility to retrieve something 
that is public (certificates) and that can help people if they deem 
necessary to do some additional security checks or other things.

Le 23/11/2012 11:41, Ryan Sleevi a écrit :
>
>
> > - abcdefg.com <http://abcdefg.com> takes care of my security and 
> wants to check that there is no man in the middle for example, then 
> abcdefg.com <http://abcdefg.com> has a script in the page to retrieve 
> the certificates that were used for the connection and by some 
> "method" (ie not defeated by potential mim) compare it with its own 
> (server certificates).
>
> The man in the middle will just remove that script that checks. If you 
> have a MIM, game over for web security. Period. End of story. No web 
> security model recovers here.
>
I wrote "not defeated by potential mim", there are ways to detect if mim 
does remove the script for example
>
> > - abcdefg.com <http://abcdefg.com> wants to check that certificates 
> did not change while loading things on abcdefg.com <http://abcdefg.com>
>
> Again, loading any active content directly (as opposed to via XHR, 
> which you presumably would not be loading active content via due to 
> CSP) = game over. Its too late at that point. The attacker has won.
>
> And we are not redefining the web security model. Absolutely out of scope.
>
I am talking about loading normal resources css, js, img, etc on the 
same domain, that's an example, it might be too late if the certificates 
change but maybe not, or at least still interesting to know
>
> > - abcdefg.com <http://abcdefg.com> wants to check things too for 
> others outside TLS connections made by him 
> (https://www.analytics_ads_tracker.com), for example that the browser 
> is not trusting someone untrusted verifying again by itself the 
> certificates
>
> This sentence does not parse.
>
Checking certificates for outside domains if for any reason I don't 
trust the browser's checks.
>
> > - abcdefg.com <http://abcdefg.com> is hosting some "advanced" 
> services (like www.ianonym.com <http://www.ianonym.com>) which might 
> need to check certificates too (see trivial Evil1 attack)
> >
>
> Defeating SOP? No thanks.
>
This project has nothing to do with defeating sop, that's the contrary, 
it is using the normal browser's mechanisms, the OP can not have valid 
certificates, that's it, so we have to ask it to check the certificates 
with the page inside the browser.
>
> > I don't think it's really new, again some existing add-ons are doing 
> the same (ie implementing some policy on certificates to secure the 
> connections), now probably with websockets, webrtc, cors or others, it 
> is needed to have it built-in inside the browser accessible via js.
>
> Doubtful, at least as far as what existing apps are doing.
>
Maybe today (except my case), but tomorrow ?
>
> Just because others practice dubious security snake oil does not mean 
> it needs to be supported. If there was an actual proposal for a 
> concrete security policy that is not met in today's browser system, it 
> may be worth contemplating (but again, *out of scope* for this spec, 
> though within the realm of secondary features), but there has yet to 
> be such a proposal that didn't rely on misunderstandings of the 
> existing web security model.
>
There are some implementations and papers showing I believe that this is 
not so dubious and not a misunderstanding of the whole security model 
(example : http://files.cloudprivacy.net/ssl-mitm.pdf)

-- 
jCore
Email :  avitte@jcore.fr
Web :    www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
Received on Friday, 23 November 2012 12:41:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 23 November 2012 12:41:13 GMT