Re: Use case - John and Jane

On Fri, Mar 22, 2013 at 4:52 PM, Aymeric Vitte <vitteaymeric@gmail.com>wrote:

>
> Le 23/03/2013 00:15, Ryan Sleevi a écrit :
>
> Aymeric,
>
>  I'm sorry, your responses do not make any sense.
>
>
> Would be cool that you avoid this kind of "gratuit" statement.
>
>
>
>  Your original attack stated "John leaves 5mn to see the postman" and
> "jane inserts from his webconsole an iframe"
>
>  I described to you why physical attacks are out of scope.
>
>  You've now suggested twice you're not describing physical attacks, even
> though you explicitly did. If you're going to keep moving the goal posts
> and changing the attack, I'm afraid we cannot have a productive discussion
> of the risk model.
>
>
> I am not changing the attack, what do you mean by "physical attack" ? I am
> taking back a WebCrypto Use Case example ("But at some point in time, a
> malicious user -- Jane Doe -- with access to the JavaScript console of John
> Doe's browser does something of the sort:") with a different attack, and by
> "she intercepts" I mean : she really intercepts the connection even if it
> is SSL/TLS, or she uses a more simple means like silent protocol analyzer,
> or other, a way that she can get John's messages.
>

Intercepting SSL/TLS MUST be out of scope.


>
>
>
>  If a site is not using SSL/TLS, but instead rolling its own crypto, then
> I'm sorry, but that cannot be dealt with in any reasonable way, because it
> entirely breaks the same-origin-policy that is essential to modern web
> security. While I'm sure novel, clever, amusing, and any number of
> platitudes, the one that is missing is "secure", and so we should not
> pretend it's a security risk to do something knowingly insecure.
>
>
> Sorry, no (see node-Tor OP again inside the browser, no need of SSL/TLS).
> I don't see why you associate SSL/TLS to SOP (while you insisted in other
> emails that there is no SSL/TLS associated to an origin), but that's
> another discussion.
>

Please point out those e-mails.

A web origin is Scheme/Host/Port.

Scheme is either HTTP or HTTPS. An origin accessed over HTTP is *not* the
same as an origin accessed via HTTPS - because they are different schemes.

No user agent can distinguish between "HTTP that is totally insecure" and
"HTTP that is running using your custom protocol that you promise is
secure".

Attempting to deliver, use, or design a cryptographic protocol over HTTP is
fundamentally and inherently flawed - it goes back to the secure script
distribution problem that we are NOT trying to solve.

While there's certainly the possibility of delivering scripts *entirely*
out of band (eg: via models such as extensions or web apps), it MUST NOT be
conflated with pseudo-secure delivery of script over HTTP.


>
>
>
>
>
> On Fri, Mar 22, 2013 at 4:12 PM, Aymeric Vitte <vitteaymeric@gmail.com>wrote:
>
>>  I thought that by "physical access" you meant that Jane can access
>> John's computer.
>>
>> But probably you mean that she intercepts John's connection. She does not
>> need to do so, she could get John's messages from his computer (wireshark
>> or other if no SSL/TLS for the site).
>>
>> Again, unlikely but possible, because if the site relies on its own
>> secure system, it might not use SSL/TLS.
>>
>> Regards,
>> Le 22/03/2013 23:45, Ryan Sleevi a écrit :
>>
>> I'm not sure what you mean - Jane's "use of web console" is a physical
>> access attack.
>>
>>
>> On Fri, Mar 22, 2013 at 3:42 PM, Aymeric Vitte <vitteaymeric@gmail.com>wrote:
>>
>>>  That's a different version of Jane's attack (from web console, then
>>> physical access) against John described in WebCrypto Use Cases.
>>>
>>> More difficult and more unlikely, but maybe not if we go outside of
>>> John/Jane's simple context.
>>>
>>> Then maybe it should be referenced somewhere.
>>>
>>> Regards,
>>>
>>> Le 22/03/2013 19:48, Ryan Sleevi a écrit :
>>>
>>> Physical access attacks MUST remain out of scope of this work.
>>>
>>>
>>> On Fri, Mar 22, 2013 at 11:12 AM, Aymeric Vitte <vitteaymeric@gmail.com>wrote:
>>>
>>>> Tricky, difficult or completely unlikely but maybe possible : Use Case,
>>>> John and Jane, Jane does not leave John but wants to spy him, sometimes she
>>>> uses his computer then knows how to access it, while John is visiting the
>>>> social site he leaves 5mn to see the postman, she inserts from his web
>>>> console an iframe in the page (jane.com) and sends a postMessage with
>>>> John's keys to the iframe which "stores" (ie references the underlying
>>>> data) the keys in jane.com's indexedDB. She intercepts John's
>>>> connexion and decrypt messages with John's computer when he is out
>>>> reinjecting messages using jane.com.
>>>>
>>>> Usually this will not work because outside origin iframes can not
>>>> access indexedDB, but indexedDB spec just says : User agents MAY restrict
>>>> access...
>>>>
>>>> Regards,
>>>>
>>>> --
>>>> jCore
>>>> Email :  avitte@jcore.fr
>>>> iAnonym : http://www.ianonym.com
>>>> node-Tor : https://www.github.com/Ayms/node-Tor
>>>> GitHub : https://www.github.com/Ayms
>>>> Web :    www.jcore.fr
>>>> Webble : www.webble.it
>>>> Extract Widget Mobile : www.extractwidget.com
>>>> BlimpMe! : www.blimpme.com
>>>>
>>>>
>>>>
>>>
>>> --
>>> jCore
>>> Email :  avitte@jcore.fr
>>> iAnonym : http://www.ianonym.com
>>> node-Tor : https://www.github.com/Ayms/node-Tor
>>> GitHub : https://www.github.com/Ayms
>>> Web :    www.jcore.fr
>>> Webble : www.webble.it
>>> Extract Widget Mobile : www.extractwidget.com
>>> BlimpMe! : www.blimpme.com
>>>
>>>
>>
>> --
>> jCore
>> Email :  avitte@jcore.fr
>> iAnonym : http://www.ianonym.com
>> node-Tor : https://www.github.com/Ayms/node-Tor
>> GitHub : https://www.github.com/Ayms
>> Web :    www.jcore.fr
>> Webble : www.webble.it
>> Extract Widget Mobile : www.extractwidget.com
>> BlimpMe! : www.blimpme.com
>>
>>
>
> --
> jCore
> Email :  avitte@jcore.fr
> iAnonym : http://www.ianonym.com
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
> Web :    www.jcore.fr
> Webble : www.webble.it
> Extract Widget Mobile : www.extractwidget.com
> BlimpMe! : www.blimpme.com
>
>

Received on Friday, 22 March 2013 23:58:04 UTC