Hacker News Reader

It is impossible. The features required to make browser Javascript safe for crypto aren't even on the roadmaps of browser vendors.

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!

> it's fatal to security

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 (a) don't have a Chrome extension that verifies anything right now, (b) are currently publishing the pure- browser- JS version of your application, and (c) envision a future in which a small number of "power users" can "safely" use the system while the majority of users, who you correctly note will not install your extension, will be at the mercy of attackers or, for that matter, your own server.

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.

But doesn't this approach if implemented the best we can , at least blocks dragnet surveillance ? isn't that valuable ?

How are you going to block dragnet surveillance if they can surveil the method of your delivering encrypted messages? NSA can already see, and modify, the JS used to create encrypted messages (because they've owned the HTTPS gateways), so they can see, and modify, the encrypted messages.

If they do this for many users, then those who don't have a secure environment (including the browser extension) are vulnerable, but it would be easy to detect that this is happening on a large scale -- those running the extension would be notified. If they don't do this for every user, then it wouldn't be effective dragnet surveillance, and Scramble would have a made a dent in dragnet ability.

Let's stipulate that your detection system, which does not currently exist even as a design document, actually works. By your own admission, only a small minority of users will actually install it. Now: a whistleblower in the USG, who is much more likely not to be a "power user" (if they were clueful they wouldn't be using this system to begin with) leaks a document from your service to a journalist and begins a conversation.

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.

Tptacek, whistle blowers level security should not be a use case for this extension , and should be advertised as part of it.

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 ?

Its not a personal insult. This system just doesn't provide serious protection from "dragnet surveillance". Distributing keys and allowing the client to encrypt a message to another user ala GPG is a great idea...you just can't use server delivered code to do it in the traditional web server/browser way. The JavaScript is modifiable in transit.

I think the disconnect here is, many of us can't imagine offering something with known technical security issues such as browser side JS encryption, and branding that "secure". Much less with all the unknown legal, operational, and techical security issues that may arise later in a project like this. As well, from what I read this project transfers your (encrypted with only a passphrase) private key over the internet, where it will be caught in the dragnet for decryption later.

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...

Could you be more specific? I don't know who "everyone" is, or what a large scale is, or who is detecting what by whom. In any case, I don't see how anyone could detect real HTTPS MITM.

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.

We assume that the server is compromised, so the extension wouldn't interpret just any JS from the server, whether or not it was delivered by HTTPS. Our idea is to require a committee to review and sign the code, and the extension would only execute code signed by the committee in consensus. This is just as secure as shipping all of the program logic in the extension, except in the case where all the signing committee member keys get compromised, which is unlikely.

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.

So far, i've failed to see a reliable committee-signing trust system. Moxie's Convergence blows chunks all over my network connections in practice.

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.

Perhaps I'm ignorant, but I've read your "JS crypto considered harmful post" and I disagree with the key points.

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?

We are not talking about crypto done in browser extensions. We're talking about a project that knows about extensions, knows how to package their project as an extension, but refuses to do so, because that would cost them users, who generally don't want to install extensions.

Let's try to keep things friendly, or at least correct. We haven't refused anything. Everything is on the table.

Your partner, just upthread, explained why you tabled the idea of using a browser extension to house all the logic for your app. I think your argument is with them, not me.

You falsely accused us of refusing to offer a browser extension for fear of losing users. Again, that is false.

Java, Python, etc don't have a DOM to consider.

When you're just an XSS away from an attacker doing:

  function encrypt(plaintext) {
    $.post(plaintext, ...);
    return plaintext;
  }

then you lose. The post talks about this, and XSS isn't the only way either.

Right, but an attacker needs access to the DOM first. If everything is packaged, this is just as difficult as being able to inject random python code.

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.

Right, like getting access to the DOM was ever a hard thing to do. I was specifically referring to web apps in that point, but because you insist, I'll just reference [1].

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...

Cache poisoning won't work if an extension loads all of its code from its own bundle. So I fail to see how this applies to an app that is fully self-contained within an extension (extensions themselves are signed, so it's not like you could MitM the extension bundle itself...)

If all of the Javascript code and application functionality is bundled into the add-on, it's trivial to avoid XSS. There's no "site" to script into via the URL, and rendering of dynamic elements can be done via a sandboxed iFrame, preventing any scripts from running within dynamic data. This is fairly basic security that any add-on developer should be aware of: http://developer.chrome.com/apps/sandboxingEval.html

"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.

I don't like the article either, but you're wrong about it being "extremely out of date", and you'd have a very hard time defending your argument with evidence. Do try.

I respect your well-considered opinions most of the time, but here, you seem to not really be presenting anything constructive. "Javascript doesn't have the features needed to be secure" Which features? Enlighten us.

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.

PS: Most users are not power users, and won't download the extension and manually check signatures.

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.

WAT. This is a PGP application that works as long as a specific user isn't targeted. PGP did better than that in 1995: keep your key safe, and if the NSA has a 50 foot poster of your head shot hanging in the lobby of Fort Meade, they still can't decrypt the message.

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.

This is also a PGP application that most people can benefit from immediately (compared to using Hotmail), and one that can be used by even the most targeted users if their environment is set up correctly once the extension is out.

You say that because you want it to be true, not because you have any real confidence that it is true.

What you said applies more to you than it does to me.

Usually, when people claim to have refuted our crappy old article on Javascript crypto, they have some misguided but at least potentially falsifiable argument for having accomplished that; for instance, "there are browsers with secure RNGs now".

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.

My argument is this: "This is also a PGP application that most people can benefit from immediately (compared to using Hotmail), and one that can be used by even the most targeted users if their environment is set up correctly once the extension is out."

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.

That's the point. If you have to "setup the environment correctly" you should implement a native client. GPG is secure because it transfers data...not code. That's actually the webs biggest problem...you can't trust code given to you by some stranger. If you transfer data you can verify that it hasn't been modified in transit. Its really impossible to verify that code given to you performs the way that you think it will.

Great is the enemy of good. Especially when great is not even possible to achieve (wide public adoption of PGP).

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'.

> 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.

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.

[1] https://panopticlick.eff.org/browser-uniqueness.pdf

Yes. This will happen. Most browsers on the Internet today can't even install extensions.

>> I want to make it as easy as possible for users to try out and adopt. Just testing it out? No installation required.

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.

I think you can do that now with one of the GPG browser plugins (or just copy/pasting from a GPG app)

It's different when everything is integrated , drive much much more usage, which is the whole point.

It's been a while since I've tried, but I think there are GPG plugins that add buttons for encryption/decryption right to web forms... FireGPG used to integrate directly with GMail but I don't think it works any more.

Two big questions:

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?

3. How do you prevent secret agents from looking in your window with binoculars?

Curtains.

Hi! These are good questions.

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: 1. Yuck - that leaves a window of vulnerability as long as "recent". It also opens up the possibility of hijacking "recent" via NTP to change the client's clock for just the duration of the HTTP GET to the update server - this is not as difficult as it sounds. A better approach would be to have the client pull a list of revoked certs along with the JS source/hash. You'll need a majority wins system for the revocation otherwise the compromised cert could be used to revoke all other certs. Also you need to avoid replay attacks, so you'll have to embed a chain of all previously signed hashes/revocations as well (just being "recent" is not good enough).

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!

Thanks for the feedback!

>> 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.

> That's not much better ...

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.