[liberationtech] Snakeoil and suspicious encryption services

Tue Jul 22 03:30:58 PDT 2014

You should stop using statements like "you don't know what your are 
doing", etc or I will reply the same way.

I am participating to different W3C lists like CSP, Webapps & co and to 
WebCrypto as a (not very active) member, so I know very well what's the 
state of the art, surprisingly I don't see you on these lists, please 
come on and express your opinions and see if you can afford to claim the 
same things.

Whether you know something about the state of the art or nothing, and 
you would then be dangerous since you are developping webapps, I would 
vote for the later for now.

If you look at the CSP archives [1] I have attempted to use it, 
unfortunately I ended up with something completely insecure, then I have 
commented on other ideas of the group to secure the code loading [2], 
then I stopped because there is no way to secure the code loading and 
CSP is more about securing the sites than the users.

Back to Peersm, it uses a kind-of nonce/script hash mechanism to load 
the code, better than nothing but useless against a mitm attack on the 
main page, so this will disappear.

Peersm can't use https for now because of [3], I have raised this issue 
on almost all the lists (webappsec, TC39, webcrypto [4]) without getting 
a clear answer why Google and Mozilla are applying this policy, I 
clearly explain again in [4] why the code loading for Peersm is 
currently not secure, as all code loading in the world.

In its final phase, Peersm will only use Tor/Peersm bridges for web 
fetching, all the rest will go through the Peersm network (browsers 
using WebRTC) for P2P exchanges, the bridges will support secure 
websockets and then https can be used to load the main page.

People like myself could still consider it's not enough to secure you, 
so back to my initial comment: you don't need to load the code, you can 
get it, check it's the valid one using different third parties and 
inject it inside your browser.

The app is of course not communicating with the web (except for web 
fetching through the bridges using the Tor protocol directly from the 
browser), it's not browsing, talking to web servers, therefore the usual 
web threats like code injection & co can not apply.

As I wrote the only danger would be a physical attack on your device 
(you go take a coffee, someone around start hacking the app and 
indexedDB with the web console, which is anyway difficult in the case of 
Peersm)

The app is a standalone one, does not interact with what could hurt it, 
communicates always using the Tor protocol, in the light of all this I 
hope you understand it's absurd to say it's insecure.

And unlike usual app, extensions, plug-in, etc it's quite easy to see 
what it is doing.

If you really pretend to be a crypto/web expert writing stuff to secure 
people, that's really frightening for your users to read your opinions 
and your understanding of the web standards, unless you start moderating 
your conclusions and really look what the project is about.

[1] http://lists.w3.org/Archives/Public/public-webappsec/2013Sep/0058.html
[2] http://lists.w3.org/Archives/Public/public-webappsec/2013Sep/0067.html
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=917829
[4] http://lists.w3.org/Archives/Public/public-webcrypto/2014Mar/0204.html

Le 22/07/2014 03:16, Tony Arcieri a écrit :
> On Mon, Jul 21, 2014 at 5:52 PM, Aymeric Vitte <vitteaymeric at gmail.com 
> <mailto:vitteaymeric at gmail.com>> wrote:
>
>     You obviously don't know what you are talking about or just did
>     not get what I explained or just do not understand http versus
>     https or the contrary, or just do not understand the web, what's
>     on client side (browser) or on server side, or don't get that your
>     extension can be mitmed too including its signature.
>
>
> Hey, it's just my job. I also write a whole blog post on the matter:
>
> http://tonyarcieri.com/whats-wrong-with-webcrypto
>
> I develop webapps that are served over HTTPS, HSTS, and use Content 
> Security Policy (CSP). You write webapps that are served over 
> plaintext HTTP and don't use content security policy, and if they did, 
> it wouldn't matter, because an active attacker can write the CSP 
> header unless you're using HTTPS.
>
> tl;dr: I am using state-of-the-art web security. You are selling snake 
> oil. You are vociferously defending your snake oil.
>
>     but first checkout what is writen on Peersm site, everything is
>     explained
>
>
> Your site is broken. It's unsafe. You don't know what you're doing. 
> You're clueless, and worse, you have some kind of Dunning-Kruger 
> complex that makes you think the opposite of what you should be doing 
> from a security perspective is a good idea.
>
> There's no beating around the bush here. You are wrong, wrong, wrong. 
> Peersm is horribly insecure, and nobody should be using it.
>
> Please read about the problem. I already linked you the Matasano article:
>
> http://matasano.com/articles/javascript-cryptography/
>
> But please also consider reading the book the Tangled Web:
>
> http://www.amazon.com/The-Tangled-Web-Securing-Applications/dp/1593273886
>
> Here is a checklist of things you don't have which, at a minimum, you 
> need to implement for your site to be remotely secure (and even then, 
> users of your site are still vulnerable to you changing the code and 
> exfiltrating their secrets):
>
> - HTTPS: https://en.wikipedia.org/wiki/HTTP_Secure
> - HSTS: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
> - CSP: 
> https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Introducing_Content_Security_Policy
>
> -- 
> Tony Arcieri
>
>

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20140722/6d9b58b4/attachment.html>