Re: [liberationtech] Snakeoil and suspicious encryption services
Maybe useful, a growing list of next generation secure email or email-like communication clients here: https://github.com/OpenTechFund/secure-email On Fri, Jul 18, 2014 at 3:59 PM, Lorenzo Franceschi-Bicchierai lorenzo...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey guys, After The New York Times video suggesting a few questionable services to encrypt email (see here: http://www.nytimes.com/video/technology/personaltech/10003002385/easily-encrypt-your-email.html?smid=tw-nytimes ) I was wondering if it's time to make a list of not-so-good snakeoil encryption services that have popped up after the Snowden revelations. As a reporter, I have received pitches for around a dozen different products, but wanted to ask you if you've seen any, and why you think they might not be good. Here's a short list to get you started (I'm not saying all these are terrible, we should look into them and figure out why they might or might not be good): - -Virtru (https://www.virtru.com/) - -Shazzlemail (http://shazzlemail.com/) - -Protonmail (https://www.indiegogo.com/projects/protonmail) - -InfoEncrypt (https://www.infoencrypt.com/) Feel free to also highlight good sevices, Cheers, lfb -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTyTYjAAoJEPHPGY+/UITwULUQAIg4PzGrM2lQW8bp/89NpxQa xUlkCijBu2fJ3hFg/qejN+xGxcNHFwny4zzROfpDGLEPU36JxLjoSugXF5mLTUJg k9LrFyS9//jTfp3h1E09up6L+qaFlk5ThIRbFKuQH/MCk+Vxhxqrf0C5lmAGuY3Z lbYVBXdEw+u3DMeFTAqC9drcuigYbN7ycYTPo+FjSLrtavWY9ddcQAjp94X9zT7W 6c+JsGpskezfqvXwkRNMV8mF/AbvqtGmQ8EfA+8AcOFnsLP/o+Lf3n0ZYPzqxIXs XEVGfcsOxg+NEdpq4KM9j1t5pPRwcJWERDtXVb29VKX4rkKguoasgLpaOEZOdZje dYY7WrOu+i7k8U1A0zE0Ob16gQJrYpOBV+WXEnP60rctlKzkerT5mY6JHUk0sdqR ox24ZEDLJiGMf/c1cXxBmwpnlb52yalo6xMoOFGlLogSbrW0eV9ZWPpcl+sxu/0h UIVj/HxHYbm5KJ9OMPPGFatBufPklaL92Nx71JPOQDlHTte0cH0VF52z6BQAqG/W tQLQwKFNXuRuBPQMcJuWekcnGEaqIHzzLN5Nbm6djvh0o+2fIWKCpPS2s4LkVG6N IutlEkuZa7z5WJChYZk/8Ch2yJ/Uh78mTPGykO9GI0r7dJ9qlpSujDVOsRBQSz5x MoKFdM+zVWpu5NXctAWC =rbQK -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Snakeoil and suspicious encryption services
On 07/19/14 11:13, carlo von lynX wrote: On Fri, Jul 18, 2014 at 7:59 AM, Lorenzo Franceschi-Bicchierai lorenzo...@gmail.com wrote: I was wondering if it's time to make a list of not-so-good snakeoil encryption services that have popped up after the Snowden revelations. Let's look at the long-term solutions. We keep a map of them on http://youbroketheinternet.org - anything that uses public-key routing instead of trying to put a band-aid over the existing Internet is in it. Everything that has a chance of protecting metadata is there. Carlo's categorization in three categories: snake-oil, band-aid, and solution is a good one. Stretching that analogy: right now, internet security is mortally wounded: 1) Almost all protocols leak both content and the social graph; 2) Our operating systems protect themselves against hostile users, they don't protect users against a hostile internet - hence the rampant malware problem; 3) Browsers have a long way to go. While I really applaud the efforts of http://youbroketheinternet.org (I was part in that), *we need the band-aid now and we need a lot of it!* After the patient has been stabilized we can concentrate on the cure. Due to the inertia, it will take 15 to 25 years for an innovation to become mainstream. If it succeeds at all. Internet innovation go at that same glacial speed. Just look at speed of uptake on ipv6. Everything that tries to insist on using insecure technologies such as X.509, DNS, DANE can at best be a band-aid. Everything that tries to put encryption on top of SMTP, XMPP, HTTP instead of underneath, is vulnerable. If it's not vulnerable technically, it is by usability. DNSSEC and DANE have been in the making for 10 to 15 years. With these technologies, I've shown[1] that it can be used to combat phishing, increase confidentiality of private messages and eliminate most problems with passwords over the internet. And it makes it easier to use. No usability problems like PGP. Therefore I propose to focus the effort of investigation how to tell band-aids apart from snake-oil. Many of the criteria have been provided by Carlo. In fact, many people are still in the 'I don't have anything to hide'-fallacy mode. It will be a long journey from the current brokenness to the goals that Carlo envisions. Any step that each of makes along that journey is an improvement. And I applaud anyone who makes the first step. I pray that it is a band aid and not snake-oil. With regards, Guido Witmond. 1: http://eccentric-authentication.org/blog/2014/06/25/talk-for-icann.html -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Snakeoil and suspicious encryption services
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 vitteayme...@gmail.com mailto:vitteayme...@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:
Re: [liberationtech] Snakeoil and suspicious encryption services
Thanks for your comments, please see mine below. Le 22/07/2014 03:40, coderman a écrit : On Mon, Jul 21, 2014 at 5:52 PM, Aymeric Vitte vitteayme...@gmail.com wrote: ... including your focus on elementary mitm issue, your arguments and judgement are so basic that I am wondering why I am answering it, you should do some reading, and if you can trivially defeat Peersm, then just show us how problems with js crypto: - side channels / non constant run time - lack of access to robust entropy sources True, or you have to trust your OS prng, but you can imagine solutions. For example Peersm is establishing multiple circuits inside the Tor network, those that have already tried this know there are a lot of impredictable events that can occur during this process (due to the instability of some nodes, not responding or with random delays, or wrongly, or randomely breaking circuits, etc), so an idea would be to use this for entropy. - unless delivered over pinned HTTPS with CSP vulnerable to mitm attack I am not sure pinned https is really the solution, what I would like to have is to clearly identify the certificate of the person I am talking to (using again third parties and different communication channels), in practice that's impossible today given the number of certificates used by major companies (using Cert Patrol to watch this, it's incredible how day after day this mess is growing up), but possible for an app like Peersm which is using only one certificate. So, I have insisted quite a lot of time in WebCrypto to get a feature so we can expose ssl/tls certificates in js and then check the certificates (notwithstanding the fact that this feature can be hacked by some code injections, but in the context of Peersm for example this would not apply), without success. And as I previously wrote CSP is more protecting the sites than the users, anyway this does not apply again for Peersm, there are no issues of content loading when you have the whole code locally. - unless an extension, vulnerable to code injection or malicious servers Yes in general, no for Peersm. - even as extension, keeps keys in address space of browser with rich attack surface. (this is true for SSL/TLS as well) The extension can be mitmed when you get it or update it, as well as its signature. contrast this with a configuration where key material is kept isolated from the rich browser attack surface through low level protections, e.g. Qubes throwaway browser app vm talking to hidden service. A separate Tor VM would contain keys for your client on the network and accessing hidden sites, while the vulnerability rich browser speaks over this transparent channel managed outside its purview. for advanced threats, isolation and defense in depth are paramount. peersm is inherently limited in this regard, not matter how many other pitfalls it successfully avoids. No, there is no story of stored keys for Peersm, if you look at the final specs [1] the keys are generated for each session, it has a cost but for plenty of reasons including fingerprinting you can not use the same keys. It will not be stored and/or use the isolation concepts of WebCrypto, again since Peersm does not interact with anything else than itself it's impossible to get the keys, unless there is a physical attack on your device. I have not studied right now what it would take to have hidden services from the browsers. unfortunately strong isolation and defense in depth are even more difficult to make easy to use, once again highlighting the complexities of usability and security in privacy enhancing technologies. Still OK and happy that people challenge Peersm concepts if issues and ways of improvements can be found. But not OK for people just to deny it based on the fact that it's javascript inside browsers. [1] https://github.com/Ayms/node-Tor#anonymous-serverless-p2p-inside-browsers---peersm-specs best regards, -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Snakeoil and suspicious encryption services
Interesting thoughts, please see my comments below. Le 22/07/2014 03:48, Seth David Schoen a écrit : Aymeric Vitte writes: 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. So unfortunately I have to stop this discussion right here with you, not to waste the time of serious people on this list, if you want to restart with another tone, then please go, but first checkout what is writen on Peersm site, everything is explained, including your focus on elementary mitm issue, your arguments and judgement are so basic that I am wondering why I am answering it, you should do some reading, and if you can trivially defeat Peersm, then just show us how The Peersm homepage is loaded over HTTP and right at the bottom says /divscript type=text/javascript id=script src=https://peersm.com/node-browser.js; nonce=90f64442274ffb89dd6a1c409f28404e35d514f6/script Well, that nonce is probably different for different users. It was designed with this intention but this mechanism will be removed. An attacker (like the barista) can make that get loaded as /divscript type=text/javascript id=script src=https://peeersm.com/node-browser.js; nonce=90f64442274ffb89dd6a1c409f28404e35d514f6/script The version of the node-browser.js file there can be slightly changed to leak the user's crypto keys by synthesizing an HTTP GET to some other host with the user's private keys as part of the URL. The security of your crypto protocol is not relevant to this attack because substituting a modified client leaks key material _outside of your protocol_, much as redirecting http://www.mozilla.com/ via a captive portal and then giving users a backdoored download of Firefox would allow leaking TLS session keys (without breaking TLS). Yes and no, as I answered previously the nonce does secure a little bit the loading of something that the app needs to work, but as I wrote this does not secure anything at the end against a mitm, so https if people trust it or retrieve the code and inject it locally as I explained, please see my previous answers about this, and if people want to weight on why Mozilla and Google have decided this policy that forces us to do insecure things, then please go ahead. And for the current phase there are no specific crypto keys for the users (it's doing the equivalent of the Onion Proxy inside browsers, no need for keys), for the final phase the crypto keys will be ephemeral. It's true that the user could detect the change if they view source, but the change may be a very small percentage of the real code, so it's a pretty significant practical question how the user will detect the change. (And will the user be willing to check what is currently 456 kB of Javascript every time they use Peersm?) There have also been some tricks to make it hard for the user to view source (or to make the source that appears look wrong). Hopefully future browsers will reliably show authentic source code, but even if they do, we're left with the how does the user know that this 456 kB of Javascript is really right? problem. The fact that it was apparently loaded from the right domain is not very satisfactory by itself, both because of small typos, attempts to make it look like the Javascript was loaded over a CDN for efficiency reasons, and maybe homoglyph attacks, while even if the user is sure that it was genuinely loaded over HTTPS from peersm.com, there is still a risk that you as the software developer could somehow be forced to give particular users a fake version (based on their client IP address), or that the peersm.com server could be hacked and could give some users a fake version without your even realizing it. I am thinking about these issues since quite some time, unfortunately I reached the conclusion that you can not secure the code loading. The only reliable way I think is to get the code from the site or some mirrors and check from different sources that it is the good one. But you envision the fact that you could detect a change, I am not 100% sure but I still think that even if you can not stop a mitm from changing your code there are good chances, if you have foreseen it, that you can indeed detect it and tell it to the user, like for example including functions that checks what is in the code or objects once the code has been executed, this still could be detected and removed by the mitm, but not sure it can succeed each time if your checks are a kind of random code, to study... unfortunately such features would break the possibility to check the code as a whole based on its hash for example... The IP addresses of the users: strangely among all remarks I got so far, nobody raised the issue that we could correlate
Re: [liberationtech] Snakeoil and suspicious encryption services
On Tue, Jul 22, 2014 at 4:47 AM, Aymeric Vitte vitteayme...@gmail.com wrote: Indeed extensions can be mitmed as easily as js code Browser extensions are digitally signed by their authors, so no, they are in no way as vulnerable to a MitM attack as JS served over plaintext HTTP: https://security.stackexchange.com/questions/34412/signing-a-browser-extension the big difference is that it's easy for any skilled js people to check what is doing the js code As pointed out with your 400kB wad of JS, that's not true, but probably beside the point... while it can be difficult for extensions I believe. Extensions provide an alternative way to package HTML/JS which allows for digital signatures of the entire archive, so no, it's really just a more secure way of distributing the same thing. You should be using a browser extension for Peersm, not some web page served over plaintext HTTP. -- Tony Arcieri -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Snakeoil and suspicious encryption services
Le 19/07/2014 11:13, carlo von lynX a écrit : On Fri, Jul 18, 2014 at 7:59 AM, Lorenzo Franceschi-Bicchierai lorenzo...@gmail.com wrote: I was wondering if it's time to make a list of not-so-good snakeoil encryption services that have popped up after the Snowden revelations. Let's look at the long-term solutions. We keep a map of them on http://youbroketheinternet.org - anything that uses public-key routing instead of trying to put a band-aid over the existing Internet is in it. Everything that has a chance of protecting metadata is there. You should add the Peersm project [1] Browser crypto is an oxymoron. As long as the browser has no way to verify that credibility of the code, the entire architecture is snake oil. Some folks are producing add-ons that verify JS crypto code by PGP signatures, but those are special solutions that expect you to trust certain PGP keys. A redo of the certification system. Band-aids. You may do the crypto directly in your add-on, but that won't protect your social graph. If you want a safe web, you should go the way of cjdns, Tor, GNUnet, I2P: The content was delivered with end-to-end encryption underneath, so you don't need to worry about encryption on the upper layers such as the web browser. Any .onion site is more secure than browser crypto (if your aim is to talk to the owner of that .onion). Using browser crypto with end-to-end hidden services is redundant. The slides are entirely missing out on distinguishing public-key routing infrastructures such as Tor, I2P, GNUnet, cjdns etc from the traditional encryption-on-top-of-broken-routing technologies. The latter are by design all band-aids or snake-oil. Thus, your slides are missing out on most of the interesting projects happening. Crypto is not just about the algorithms. It's also about where you apply them. Best regards. Sorry, while some statements here are correct you give a totally wrong conclusion about crypto inside browsers. Let's take the Peersm project, it's all about crypto inside browsers, javascript modules for now and maybe WebCrypto later. Unlike obscure elefantesque open source code that you don't even know what it becomes when it gets compiled, it's trivial to see what it is doing. So Peersm is a monolithic js code app, monolithic so you don't load tons of potentially insecure modules, it does not use neither rely on any plugin/add-on, for always the same reason: you must be able to check precisely what the app is doing. But of course you must load the code at a certain point of time, I am not going to reexplain why the main page of Peersm is not using https, this will anyway not secure the code loading, this part can be insecure and whatever the specifications groups are inventing to solve this, you can minimize the risk but not eliminate it unless you have a way to check the code with different third parties and different communication channels. The easy fix for this is to package Peersm as a standalone app and run it locally [2]: you load the page locally (images, css, etc) and you inject the js code (after you have verified using different sources that the code that you have is the right one), you do not load anything from the outside (except peers and Tor/Peersm bridges details, but this too you can handle it locally if you like). This package is not available right now because of some lack of time and because it does not present any issue from a technical standpoint (so we focus on other issues like the final phase, do not even check the hash in [2] it's not up to date), it will for sure not be a plugin/add-on, just a package with a short explaination how to use it. Then please tell me what threat the app sould be afraid of, there are none, if we go further in the paranoia the only threat is a physical attack on your device, so if you do stupid things you can hack yourself, if someone else gets access to your device it can hack inside the app without you knowing about it, but even this is difficult the way the code is sandboxed, another layer could be added like complete DOM sandboxing using Caja principles but this seems really too heavy given that a physical attack is your problem, not the one of the app. From my standpoint it's more secure than anything else, because you do not install anything that can get access to your device, what you install is inside browsers, you can check in a determist way what it is and what it is doing, it can not access anything on your device not authorized by the web and yourself, it does not load anything from the outside that is not secure by the app. Peersm concepts can be challenged, I am still surprised that on this list and others the wrong ideas of insecure browser, js, nodejs keep propagating and that the uses are systematically disregarded. Regards [1] http://www.peersm.com (current phase) and (final phase)
Re: [liberationtech] Snakeoil and suspicious encryption services
On Mon, Jul 21, 2014 at 12:59 PM, Aymeric Vitte vitteayme...@gmail.com wrote: Unlike obscure elefantesque open source code that you don't even know what it becomes when it gets compiled, it's trivial to see what it is doing. I suggest that you read about the process of just-in-time compilation, which is Javascript engine browser- and version-specific. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Snakeoil and suspicious encryption services
I don't need to read that's exactly what I meant: you can trust a compiled package only if you have compiled it yourself, and have previously checked the complete code or have it audited, which is unlikely for both in most of cases, but happens systematically with js for the compilation phase, while the check of the code, which does not depend on tons of libraries, is trivial. Le 21/07/2014 15:57, Maxim Kammerer a écrit : On Mon, Jul 21, 2014 at 12:59 PM, Aymeric Vitte vitteayme...@gmail.com wrote: Unlike obscure elefantesque open source code that you don't even know what it becomes when it gets compiled, it's trivial to see what it is doing. I suggest that you read about the process of just-in-time compilation, which is Javascript engine browser- and version-specific. -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Snakeoil and suspicious encryption services
On Mon, Jul 21, 2014 at 2:59 AM, Aymeric Vitte vitteayme...@gmail.com wrote: So Peersm is a monolithic js code app, monolithic so you don't load tons of potentially insecure modules, it does not use neither rely on any plugin/add-on, for always the same reason: you must be able to check precisely what the app is doing. Browser extensions allow you to use web technologies, including HTML/JS, while still providing a verifiable archive of its contents that can be digitally signed. Compare to a web page, which is ephemeral and makes it difficult to detect changes between versions. But of course you must load the code at a certain point of time, I am not going to reexplain why the main page of Peersm is not using https, this will anyway not secure the code loading, this part can be insecure Then an attacker with a privileged network position (e.g. your barista) can rerwrite your JS code to exfiltrate whatever secrets you were hoping to protect with it. Or perhaps they could just shut the encryption off. Your opinions about web security are about as diametrically opposite from reality as they can be. What are you expecting people to do, read the source code of your web page every time they intend to use it? Please read this: http://matasano.com/articles/javascript-cryptography/ -- Tony Arcieri -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Snakeoil and suspicious encryption services
Please read again what I have written, your answer just extracts really basic parts out of the context and does not take into account the whole picture that I have explained, I already read the link you provided some years ago, I recall it as trivial and/or too old statements unfortunately having still enough visibility on the web to disinform people. The code loading is an unsolvable issue unless you do what I have writen. Extensions, plug-in, add-on can not secure you more than a js code that you can not hide (the question is not only to make sure you have the right code, but to be able to check what it is doing). And at the end, what I am talking about is a standalone js app inside browsers, this is highly doubtful that someone can question the security of this, I would like to see it (but then please read exactly what I wrote) Regards Le 21/07/2014 19:44, Tony Arcieri a écrit : On Mon, Jul 21, 2014 at 2:59 AM, Aymeric Vitte vitteayme...@gmail.com mailto:vitteayme...@gmail.com wrote: So Peersm is a monolithic js code app, monolithic so you don't load tons of potentially insecure modules, it does not use neither rely on any plugin/add-on, for always the same reason: you must be able to check precisely what the app is doing. Browser extensions allow you to use web technologies, including HTML/JS, while still providing a verifiable archive of its contents that can be digitally signed. Compare to a web page, which is ephemeral and makes it difficult to detect changes between versions. But of course you must load the code at a certain point of time, I am not going to reexplain why the main page of Peersm is not using https, this will anyway not secure the code loading, this part can be insecure Then an attacker with a privileged network position (e.g. your barista) can rerwrite your JS code to exfiltrate whatever secrets you were hoping to protect with it. Or perhaps they could just shut the encryption off. Your opinions about web security are about as diametrically opposite from reality as they can be. What are you expecting people to do, read the source code of your web page every time they intend to use it? Please read this: http://matasano.com/articles/javascript-cryptography/ -- Tony Arcieri -- Peersm : http://www.peersm.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Snakeoil and suspicious encryption services
On Mon, Jul 21, 2014 at 12:59 PM, Aymeric Vitte vitteayme...@gmail.com wrote: Please read again what I have written, your answer just extracts really basic parts out of the context and does not take into account the whole picture that I have explained, I already read the link you provided some years ago, I recall it as trivial and/or too old statements unfortunately having still enough visibility on the web to disinform people. I read what you wrote. You're wrong. You are very, very wrong. The code loading is an unsolvable issue unless you do what I have writen. Loading JavaScript of any kind over plaintext HTTP is a bad idea. Loading JavaScript implementing cryptography is a sign you have no fucking clue what you're doing. It's the equivalent of a giant DANGER WILL ROBINSON: THIS CODE IS UNSAFE sign. Extensions, plug-in, add-on can not secure you more than a js code that you can not hide Browser extensions are cryptographically signed. Plaintext HTTP is trivially rewritten by an attacker. Systems like Peersm are horrendously vulnerable to an active attacker. And at the end, what I am talking about is a standalone js app inside browsers, this is highly doubtful that someone can question the security of this, I would like to see it (but then please read exactly what I wrote) If someone has a privileged network position (i.e. your barista), they can catastrophically compromise the alleged security of such a system via an incredibly trivial MitM attack. This same attack cannot be performed against cryptographically signed browser extensions. Even adding HTTPS to your HTML/JS site would be a step up. This app is poorly implemented and dangerous and it would be best for you to either find some way to serve it over HTTPS or delete it from the Internet. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Snakeoil and suspicious encryption services
On Mon, Jul 21, 2014 at 5:52 PM, Aymeric Vitte vitteayme...@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 -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Snakeoil and suspicious encryption services
On Mon, Jul 21, 2014 at 5:52 PM, Aymeric Vitte vitteayme...@gmail.com wrote: ... including your focus on elementary mitm issue, your arguments and judgement are so basic that I am wondering why I am answering it, you should do some reading, and if you can trivially defeat Peersm, then just show us how problems with js crypto: - side channels / non constant run time - lack of access to robust entropy sources - unless delivered over pinned HTTPS with CSP vulnerable to mitm attack - unless an extension, vulnerable to code injection or malicious servers - even as extension, keeps keys in address space of browser with rich attack surface. (this is true for SSL/TLS as well) contrast this with a configuration where key material is kept isolated from the rich browser attack surface through low level protections, e.g. Qubes throwaway browser app vm talking to hidden service. A separate Tor VM would contain keys for your client on the network and accessing hidden sites, while the vulnerability rich browser speaks over this transparent channel managed outside its purview. for advanced threats, isolation and defense in depth are paramount. peersm is inherently limited in this regard, not matter how many other pitfalls it successfully avoids. unfortunately strong isolation and defense in depth are even more difficult to make easy to use, once again highlighting the complexities of usability and security in privacy enhancing technologies. best regards, -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Snakeoil and suspicious encryption services
Aymeric Vitte writes: 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. So unfortunately I have to stop this discussion right here with you, not to waste the time of serious people on this list, if you want to restart with another tone, then please go, but first checkout what is writen on Peersm site, everything is explained, including your focus on elementary mitm issue, your arguments and judgement are so basic that I am wondering why I am answering it, you should do some reading, and if you can trivially defeat Peersm, then just show us how The Peersm homepage is loaded over HTTP and right at the bottom says /divscript type=text/javascript id=script src=https://peersm.com/node-browser.js; nonce=90f64442274ffb89dd6a1c409f28404e35d514f6/script Well, that nonce is probably different for different users. An attacker (like the barista) can make that get loaded as /divscript type=text/javascript id=script src=https://peeersm.com/node-browser.js; nonce=90f64442274ffb89dd6a1c409f28404e35d514f6/script The version of the node-browser.js file there can be slightly changed to leak the user's crypto keys by synthesizing an HTTP GET to some other host with the user's private keys as part of the URL. The security of your crypto protocol is not relevant to this attack because substituting a modified client leaks key material _outside of your protocol_, much as redirecting http://www.mozilla.com/ via a captive portal and then giving users a backdoored download of Firefox would allow leaking TLS session keys (without breaking TLS). It's true that the user could detect the change if they view source, but the change may be a very small percentage of the real code, so it's a pretty significant practical question how the user will detect the change. (And will the user be willing to check what is currently 456 kB of Javascript every time they use Peersm?) There have also been some tricks to make it hard for the user to view source (or to make the source that appears look wrong). Hopefully future browsers will reliably show authentic source code, but even if they do, we're left with the how does the user know that this 456 kB of Javascript is really right? problem. The fact that it was apparently loaded from the right domain is not very satisfactory by itself, both because of small typos, attempts to make it look like the Javascript was loaded over a CDN for efficiency reasons, and maybe homoglyph attacks, while even if the user is sure that it was genuinely loaded over HTTPS from peersm.com, there is still a risk that you as the software developer could somehow be forced to give particular users a fake version (based on their client IP address), or that the peersm.com server could be hacked and could give some users a fake version without your even realizing it. I would be happy to accept that browser extensions only partially address these threats -- especially threats of attacks by the browser extension developer, or involving attacks against the extension developer's infrastructure. We have better assurances that the network operator can't substitute Javascript code for the Javascript code that we wanted (by installing the browser extension only over HTTPS, and not re-downloading it every time). But currently, we don't have a good assurance that the browser extension we got is the same one that everyone else got (and that may have been audited), nor that we get the same updates as all other users. I think it's quite important for browser developers and browser extension developers to address these limitations. -- Seth Schoen sch...@eff.org Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107 -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Snakeoil and suspicious encryption services
On Fri, Jul 18, 2014 at 7:59 AM, Lorenzo Franceschi-Bicchierai lorenzo...@gmail.com wrote: I was wondering if it's time to make a list of not-so-good snakeoil encryption services that have popped up after the Snowden revelations. Too much effort really. It's easier to document the technical criteria for judgment. There are three general categories: projects that look for real long-term solutions, band-aids for the time being (although they frequently think of themselves as solutions) and ultimately snake-oil humbug, although there is no clear separation line between band-aids and snake-oil. Let's look at the long-term solutions. We keep a map of them on http://youbroketheinternet.org - anything that uses public-key routing instead of trying to put a band-aid over the existing Internet is in it. Everything that has a chance of protecting metadata is there. Everything that tries to insist on using insecure technologies such as X.509, DNS, DANE can at best be a band-aid. Everything that tries to put encryption on top of SMTP, XMPP, HTTP instead of underneath, is vulnerable. If it's not vulnerable technically, it is by usability. If you really really make no mistakes, then PGP and similar tools will allow you to have a secret conversation, but none of this stuff properly protects who is talking to whom. And there is a further trade-off, if the end-to-end encryption is only granted to you by a server that sends you the suitable javascript code and you are somehow supposed to trust it. So from a suitably radical perspective (can we afford anything less?) many even respected projects are more close to snake-oil than actually useful at protecting us from the pervasive active adversary we are confronted with. Why insist? There are many projects designed in a more secure way. On Fri, Jul 18, 2014 at 08:32:36AM -0700, Steve Weis wrote: Somewhat relevant, I recently gave a talk about Crypto Projects that Might Not Suck: http://saweis.net/pdfs/CryptoMightNotSuck-2014.pdf I don't really understand these slides. There is a confused mix of libraries that could of course be used properly or not, then many band-aids and a few recommendable things and there is no differentiation between tools that protect metadata such as Tor and Pond and all the rest that merely tries its best to achieve end-to-end encryption. Combining PGP/SMTP with Tor only works if all participants use pseudonymous mail accounts, hardly anyone does - even then, one small mistake can deanonymize you and having a social graph too similar to your regular mail account might, too. Pond and I2PBote are way ahead concerning this, providing mail systems that protect the social connections, and since all participants have to upgrade to be safe, why are we still talking of solutions that use the old broken Internet? OTR works well for encrypted communications if we didn't fail to activate it and respected the bureaucracy of ensuring its accuracy. But even if we didn't fail in that, we still entrust servers with the knowledge of our social graph. To avoid that, chat systems that use hidden services are better - but then there is no reason to insist on XMPP and OTR as invisible.im does: Tor already provides end-to-end and forward secrecy, circuits are reestablished all the time. OTR is redundant in this case. Browser crypto is an oxymoron. As long as the browser has no way to verify that credibility of the code, the entire architecture is snake oil. Some folks are producing add-ons that verify JS crypto code by PGP signatures, but those are special solutions that expect you to trust certain PGP keys. A redo of the certification system. Band-aids. You may do the crypto directly in your add-on, but that won't protect your social graph. If you want a safe web, you should go the way of cjdns, Tor, GNUnet, I2P: The content was delivered with end-to-end encryption underneath, so you don't need to worry about encryption on the upper layers such as the web browser. Any .onion site is more secure than browser crypto (if your aim is to talk to the owner of that .onion). Using browser crypto with end-to-end hidden services is redundant. The slides are entirely missing out on distinguishing public-key routing infrastructures such as Tor, I2P, GNUnet, cjdns etc from the traditional encryption-on-top-of-broken-routing technologies. The latter are by design all band-aids or snake-oil. Thus, your slides are missing out on most of the interesting projects happening. Crypto is not just about the algorithms. It's also about where you apply them. Best regards. -- http://youbroketheinternet.org ircs://psyced.org/youbroketheinternet -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
[liberationtech] Snakeoil and suspicious encryption services
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey guys, After The New York Times video suggesting a few questionable services to encrypt email (see here: http://www.nytimes.com/video/technology/personaltech/10003002385/easily-encrypt-your-email.html?smid=tw-nytimes) I was wondering if it's time to make a list of not-so-good snakeoil encryption services that have popped up after the Snowden revelations. As a reporter, I have received pitches for around a dozen different products, but wanted to ask you if you've seen any, and why you think they might not be good. Here's a short list to get you started (I'm not saying all these are terrible, we should look into them and figure out why they might or might not be good): - -Virtru (https://www.virtru.com/) - -Shazzlemail (http://shazzlemail.com/) - -Protonmail (https://www.indiegogo.com/projects/protonmail) - -InfoEncrypt (https://www.infoencrypt.com/) Feel free to also highlight good sevices, Cheers, lfb -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTyTYjAAoJEPHPGY+/UITwULUQAIg4PzGrM2lQW8bp/89NpxQa xUlkCijBu2fJ3hFg/qejN+xGxcNHFwny4zzROfpDGLEPU36JxLjoSugXF5mLTUJg k9LrFyS9//jTfp3h1E09up6L+qaFlk5ThIRbFKuQH/MCk+Vxhxqrf0C5lmAGuY3Z lbYVBXdEw+u3DMeFTAqC9drcuigYbN7ycYTPo+FjSLrtavWY9ddcQAjp94X9zT7W 6c+JsGpskezfqvXwkRNMV8mF/AbvqtGmQ8EfA+8AcOFnsLP/o+Lf3n0ZYPzqxIXs XEVGfcsOxg+NEdpq4KM9j1t5pPRwcJWERDtXVb29VKX4rkKguoasgLpaOEZOdZje dYY7WrOu+i7k8U1A0zE0Ob16gQJrYpOBV+WXEnP60rctlKzkerT5mY6JHUk0sdqR ox24ZEDLJiGMf/c1cXxBmwpnlb52yalo6xMoOFGlLogSbrW0eV9ZWPpcl+sxu/0h UIVj/HxHYbm5KJ9OMPPGFatBufPklaL92Nx71JPOQDlHTte0cH0VF52z6BQAqG/W tQLQwKFNXuRuBPQMcJuWekcnGEaqIHzzLN5Nbm6djvh0o+2fIWKCpPS2s4LkVG6N IutlEkuZa7z5WJChYZk/8Ch2yJ/Uh78mTPGykO9GI0r7dJ9qlpSujDVOsRBQSz5x MoKFdM+zVWpu5NXctAWC =rbQK -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Snakeoil and suspicious encryption services
I wouldn't use any of these. InfoEncrypt is especially bad. If a product doesn't have a link to source code, doesn't have detailed documentation, or relies on code running on their servers, then do not expect privacy of your messages. Somewhat relevant, I recently gave a talk about Crypto Projects that Might Not Suck: http://saweis.net/pdfs/CryptoMightNotSuck-2014.pdf On Fri, Jul 18, 2014 at 7:59 AM, Lorenzo Franceschi-Bicchierai lorenzo...@gmail.com wrote: After The New York Times video suggesting a few questionable services to encrypt email (see here: http://www.nytimes.com/video/technology/personaltech/10003002385/easily-encrypt-your-email.html?smid=tw-nytimes) I was wondering if it's time to make a list of not-so-good snakeoil encryption services that have popped up after the Snowden revelations. As a reporter, I have received pitches for around a dozen different products, but wanted to ask you if you've seen any, and why you think they might not be good. Here's a short list to get you started (I'm not saying all these are terrible, we should look into them and figure out why they might or might not be good): - -Virtru (https://www.virtru.com/) - -Shazzlemail (http://shazzlemail.com/) - -Protonmail (https://www.indiegogo.com/projects/protonmail) - -InfoEncrypt (https://www.infoencrypt.com/) -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
