Your reason for using browser Javascript for crypto --- here, Recurity's JS PGP implementation --- is the same as every other JS crypto project's reason: doing everything in the browser makes it easier for users to adopt your project. You are not the first person to point this out and you won't be the last.
The problem is, you acknowledge one side of this design ("it's super easy for users") and ignore the other ("it's fatal to security").
Here, you even acknowledge that there was a simple mechanism available to you that might have marginally improved security (packaging the whole application as a Chrome extension). But that made your life too hard! So you abandoned that idea and just made all the crypto downloadable from the server on HTML pages!
1. Browsers, at least the ones that matter, provide window.crypto (with a CSPRNG). This makes generating IV's for CBC "safe," makes generating RSA keys "safe," makes generating random keys "safe." Or am I missing something? Assuming the JS crypto code itself is actually sound, the PRNG seems to be the missing link...or at least, it was.
2. Packaging the entire app as an addon (assets, javascript, views, everything) means the app can be signed and verified. No in-app code updates. If you want an update, download the latest extension. The article assumes that people will do what OP is doing: downloading code and running it dynamically. I agree this is a no-no, even if verifying.
Is there some sort of attack vector I'm missing? I think it's fair to assume the browser is an attack vector, just like hardware is, just like the OS is, or whatever language VM you're running on, etc...but that seems tangential to the process of packaging/signing an entire javascript app and distributing it as an add-on. I also know about the unsafe memory stuff, but this just brings browser encryption down to the level of Python/Ruby/etc. I'm not dismissing this concern, I'm saying that if you're attacking javascript for having this vulnerability, you must also attack any GC language (which you do in the article).
How is in-browser encryption so different from any other java/python/etc app when packaged/signed? I'm not talking about replacing SSL, I'm talking about encrypting data via AES/blowfish in a browser extension with a key generated from a password, and if the data leaves the browser, using SSL on top of that.
What makes it impossible to do this and gain the same level of security as any other language/platform?
When you're just an XSS away from an attacker doing:
function encrypt(plaintext) {
$.post(plaintext, ...);
return plaintext;
}
"XSS isn't the only way either." That's about as illuminating as saying "something bad could happen."
No one is saying JavaScript or browser security is perfect, but if you actually know what you're doing, it can be done properly.
The original "JavaScript security is doomed" Matasano article is extremely out of date at this point, and yet people keep referring to it like it's gospel.
Sure, you can set up your app to stupidly do evals everywhere, but you can program a bad app in any language.
> XSS isn't the only way either
That's very, very vague. I asked what the attack vectors are. Saying "others" doesn't really work for me.
Another vector to get rogue JS into a user's browser is cache-poisoning, something the article also brings up.
[1] http://media.blackhat.com/bh-us-12/Briefings/Osborn/BH_US_12...
I'll respectfully disagree.
> But that made your life too hard! So you abandoned that idea
We haven't abandoned the Chrome extension idea at all. We just think there's a better approach than "packaging the whole application as a Chrome extension". Doesn't sound like you read my reply.
You're essentially asking to be the next Lavabit. You've added a verification component that probably won't work even for the verifiers. But that doesn't even matter, because the majority of your users won't even be doing that verification.
As for the chrome extension thing, the project clearly states that it is currently a proof of concept and is missing this crucial part which is currently being built. Somehow you try to turn this into an ad-hominem attack on the developer's supposed laziness.
The FBI decides they'd like to read that conversation. They issue a court order requiring you to hand over your TLS private key, and use it to MITM your users to feed them corrupted JS code that discloses PGP private keys.
The small minority of users "detect" this change. But not quickly enough: the whistleblower has already logged in to check their mail, and has now disclosed their private key to the FBI.
What now? What's the feature you're going to build to keep that from happening?
Not only are you using Javascript crypto to provide this "service" to users, but you're not even forward secure.
But decreasing the amount of dragnet surveillance by some extent sounds like a good thing to me. For example, many people wouldn't like the government to know mundane stuff about them, like having an abortion.This could help.
* BTW haven't moxie written about an asynchronous diffie hellman key exchange ? it could at least give PFS to this , so the private key would be much less useful ?
I find it far more dangerous for someone to think they're secure against government level threats, than to know they're not. And if you're not worried about government level threats, gmail with MFA and pinned chrome certs is likely safer than this project. Of course, this is all just my humble opinion...
If the Scramble.io people ship ALL OF THE PROGRAM LOGIC IN THE EXTENSION, it could be secure. But if any program logic (javascript) they interpret is delivered to the user via HTTPS, it will not be secure.
In general, dragnet security will always be possible as long as you can do statistical analysis over both targets in the network (or the whole network), which the NSA has proven it can do.
My point in the previous comment was that dragnet surveillance wouldn't work at all unless the client's code was compromised, but there isn't a good way for the NSA to compromise ALL OR MOST of the clients' code without it being detected by those users who use the extension. Remember the TorMail episode where malicious javascript was injected in the response? If some users had a Firefox extension that checked to make sure that all the JS code was signed by a committee, then they would have raised the flag and alerted everyone not to use TorMail.
Committee depends on things like number of nodes in the network and integrity of the nodes, not to mention you can still do analysis on who was sending or receiving something at a particular time (which may not be enough to stand up in court, but it's enough for the NSA to know that Mike is talking to Jeff, or whomever).
At the end of the day, the best method currently available for clandestine activity on the internet is one-time anonymous drop boxes, and luck.
As mentioned in the writeup, there's a beautiful way you can protect even non-power-users. Because the extension downloads and verifies the webapp HTML, CSS and JS every time it runs, the web app is constantly being validated.
As long as you have a critical mass of power users who installed the extension, an adversary cannot tamper with the web application without immediately being noticed.
A strong adversary could still commandeer the server and serve tampered JS to a specific IP without being detected. Users who are specially targeted by such an adversary must either install the extension, use Tor, or both.
My goal is to make Scramble usable by a wide range of people. For a nontechnical user, it's just as easy as using Gmail--and at a minimum, they get the advantage that Scramble servers never store plaintext.
A user with stronger requirements can do more, and can get stronger security guarantees.
Imagine the following. An Attacker manages to hijack your server. They fingerprint[1] the browsers of each user and only send malicious JS to certain users that dont use your extension. No one will ever know, that they have been compromised.
When you build and promote a system like this, you are assuming a responsibility on behalf of your users. You should take that responsibility more seriously.
EDIT: And you seem to be saying that this is actively bad, which I think is just jumping the gun without identifying any actual issues. Having it be only partially secure until you install a browser extension and then having it properly secure most certainly falls into 'good' and not 'bad' or 'great'.
You don't even have that. From what I can tell, you have literally no argument at all; instead, you "agree" with the article while drawing exactly the opposite conclusion that the article draws, then point out again and again how much users don't want to install things, as if that changed the security of this system at all.
Scramble performed encryption on the server, then my argument is false. But the design of Scramble's protocol is such that the security of the application depends only on securing the client code, which I argue can be done, for those who set up their environment correctly.
Why not offer an option to try it out in the browser(with same GUI), and if they want security tell them to install it(and verify)? It would be just a bit harder than installing the extension.
BTW:there's another use case for extension based encryption: As the backbone for private messaging for various sites(which requires integration with the browser) , for example reddit.
private messages in reddit are :
(a)viewable to sniffers due to http usage
(b)can be viewed by reddit staff
(c)can be viewed by dragnet and targeted surveillance
An extension would definetly reduce attack scenarios, and has a good viral marketing vector. In fact implement the right way i could see it being a very reliable way to making something like this popular.
1. How do you revoke a compromised signature comitee certificate embedded in the browser extension?
2. How can you prevent a hostile browser extension from hijacking the validation process?
1. We could require the signatures to be recent, and if there are any certificates that need to be revoked, we could require that all signers include that information in the data signed. What do you think?
2. If other hostile browser extensions can hijack the validation process, then the only solution is to not have other browser extensions. Paranoid users who need strong security should boot from a fixed image that has a vetted browser with only one browser extension already installed.
Re: 2. Yes, you can't have any other browser extensions. But that is totally unrealistic. It's just a a complete showstopper.
Even a bookmarklet could bypass your cryptosystem!
>> A better approach would be to have the client pull a list of revoked certs along with the JS source/hash.
That's not much better, as the client will have to pull a list from somewhere, and that somewhere could have been compromised to serve a bad list. At least with a window you always need an absolute majority. I'm not liking any of these solutions, so you make a good case for packaging an extension with all of the client code!
>> It's enough for me because I don't use any browser extensions. Maybe it's a showstopper for you because you use other chrome extensions that you don't trust. Here's an idea -- we could offer the client as a standalone application with embedded Chrome. Then you can have your untrusted browser for all your normal browsing purposes, and a separate Scramble app.
I have no idea what you mean about a bookmarklet bypassing the cryptosystem. Are you suggesting that a user clicking on a malicious bookmarklet can thwart security? The user can always thwart his own security.
Yes it is. As I said you'll need a majority-wins system, i.e. the list of revoked certs is signed by a majority of the signature committee members. Using a window is wide open to attack, it has no redeaming features.
> It's enough for me ...
Unfortunately, "it works on my computer" is not going to cut it. I use a few browser extensions, but now those extensions' own update mechanisms can be used to attack your cryptosystem - even a "good" extension could be hijacked this way. That gives me a lot to worry about...
My point with bookmarklets was that many bookmarklets pull down code from an external server and inject it into the local page, so if the user makes use of any booklets as part of their email workflow then those bookmarklet sites now become attack vectors for your cryptosystem. Likewise, browser 0-days are also attack vectors for your cryptosystem which would not be present in say, a stand-alone client. The attack surface area of a browser is huge.
But it's not impossible.
The reason I chose that route is because I want to make it as easy as possible for users to try out and adopt. Just testing it out? No installation required.
I think that security is at least equal parts a technical problem and an adoption problem. The status quo is that nearly all email is searchable plaintext as far as strong adversaries are concernd. I want to fix that.
> If you're going to build a browser extension, put the crypto code in the extension.
The hard part is running known, trusted JS. Simply packaging the same HTML/CSS/JS as a browser extension was certainly my first impulse! The issue then is that you can never ship an update--users must proactively upgrade--unless you have an auto update mechanism for the extension (eg, Play Store) at which point you're again at the mercy of the server, no better than a web app.
Once you get trusted code running on the client, you can bootstrap. The system I envision is as follows: you, a power user, download the browser extension. You verify the signatures. There are multiple signatures--not just my own--so that no one party can release a tampered client. A set of independent, trusted organizations around the world must sign each release. Let's call them the Signature Committee.
The browser extension simply contains the public keys of each member of the signature committee, and a small bootstrap loader. When you run the browser extension, it gets the latest assets from the server, along with a signature file---and it checks that enough members of the signature committee have signed them.
You know have trusted code, but the developer can still--with the consent of the signature committee--push out updates.
I think that the Signature Committee concept has very cool properties. Currently, even security-critical client applications--for example, the Tor Browser Bundle--are usually only signed by a single organization--in that case, the Tor Foundation. Given that governments have shown themselves willing to coerce organizations to conspire against their users, and to do so in secret, we need something better. I envision a future where Scramble keeps improving continuously, but no one organization--not even any one country--can unilaterally ship an update.
Thanks for your feedback!