Hacker News Reader

> Why is in-browser encryption considered so different that even smart people like tptacek get all worked up about it?

There's two issues that I can think of.

The first is philosophical, and not technological: in all these examples (e.g. this post) doing encryption on the client side gets you nothing. Furthermore, although it is in fact exactly as secure as not having client side encryption, it misleads users into thinking that now the backend can't read their data, etc.

Assume the server operators are 1) competent and 2) trustworthy. Then let them use the standard, time-tested technology of SSL to send data in the clear, and trust them to encrypt it on their end.

If you can't assume (1) and (2) above, remind me why I'm trusting the javascript code they deliver instead?

The point is, with web apps you have to either trust the provider or not. If you do, just use SSL. If you don't, then nothing they can provide via javascript should convince you otherwise. And them providing client side encryption so that you "don't have to trust them" is infuriatingly wrong.

The second point is technological. Let's say the developers are competent, and you understand that you have to trust them. Why then should you prefer that they write the encryption stuff on the backend rather than the frontend? This one I'm not so clear on and would like to hear more. It makes sense that the backend is a more controlled environment, but beyond that I don't know.

> nothing they can provide via javascript should convince you otherwise.

How about javascript that is:

(a) open-source

(b) third-party audited, with a third-party-published hash of the versioned javascript

(c) verified against the hash at runtime by a browser plugin that consults a hash directory of audited versions?

That (c) honestly sounds to me like it ought to be a web standard, signed authenticated javascript.

(c) would be great. potentially, it works in a very similar way as the CA system, but instead of a CA you have browser vendors who choose to include your JS file as verified... definitely a lot of details in there that could go seriously wrong if the wrong people decided to get involved in defining a process for validating those hashes and pushing them out to the vendors...

In theory, users could choose their own verification authority.

That's great, if it's running in an extension that is only downloaded once and firewalled off from the DOM. Otherwise, every single HTTP request your browser makes can potentially override it.

What design or implementation changes would you recommend for a future browser or HTTP spec, to enable 3rd-party validation of scripts and notification to the user when new, unvalidated scripts are requested?

Thanks for your detailed answer. You make a lot of good point, but I'm still not entirely convinced:

> Assume the server operators are 1) competent and 2) trustworthy. Then let them use the standard, time-tested technology of SSL to send data in the clear, and trust them to encrypt it on their end.

What if the developers are entirely trustworthy and almost competent? And, what if there'd surface a JS crypto library that's also pretty time-tested and be considered equally secure as, say, OpenSSL?

The almost competent developers could be relying on entirely standard OSS browser-side encryption library. If they then make a minor fuckup on the backend (say, forget to update OpenSSL in heartbleed-times, or look past that newest Rails vuln Egor Homakov found, or look over an intern-created SQL injection in a code review, etc), then the harm is smaller because there's simply no plaintext ever in memory on the server.

Like the GP said, by doing client-side security, you really do add another layer, right? This of course assumes that the client-side JS is decent, but there's no need for the coders of the app to homebrew that just like they don't tend to homebrew their HTTP server or their SSL layer.

Sure, some of the above-mentioned vulnerabilities could enable a hacker to also inject false encryption JS code but that's still way more complex than just injecting some server-side code that dumps plaintext to pastebin.

I'm interested because I consider myself to be such an "almost competent" developer, at least when it comes to security. If I can add another layer of security by using decent OSS and not becoming a crypto expert then I'm very interested.

Right, whether you use a native or a web app, you have to trust two things: The developer of the app, and the SSL infrastructure (assuming of course you use https).

A rouge developer or a compromized CA can harm you in any case.

The problem with in-browser encryption is when it replaces https. In that case, you have no insurance that the key hasn't been seen/touched by a man-in-the-middle attacker.

What in-browser-encryption on top of https does is it protects you in the case that the (honest!) app provider has a data breach. They never had your plaintext to begin with.

Whether or not this is acceptable depends on your threat model. If you believe your adversary might compromise or coerce the service operator, then you cannot trust in-browser encryption even if it is served over https - the code sent to you could be modified to be malicious, and you have no way to prevent or even detect that this is happening. See the Tor Freedom Hosting [0] incident for an example of how LEA already do this.

So, the inability to guarantee integrity of a web application remains a problem. TLS helps, but falls short if your adversary can MITM TLS or compromise/coerce the service operator. Web applications unfortunately make this a very convenient attack vector, since their code gets reloaded from the server so frequently and remote code execution (RCE) is trivial to achieve on the web platform (XSS, browsers are full of exploitable bugs).

[0] http://www.wired.com/2013/09/freedom-hosting-fbi/

GP's questions are (respectfully) being skirted around. The same reasoning applies to compiled, client-side code. Recent events show that open source code is as vulnerable as closed source. App stores may mitigate things somewhat, but not completely. It's probably easier to verify client-side encryption in a browser than it is to audit a thick client app, no?

> All apps I installed on my phone came from a server and were put there by people I don't know at all.

The apps on your phone can't be updated without notice to you. It's significantly more difficult for the app developer to maliciously update only your copy, and not every copy. Updating everyone's copy has higher much risk.

> Is it that browser apps get "reinstalled" on every use, and not "only" when an autoupdater or user detects a new version?

Yes. You might not be able to reverse engineer the Dropbox client, but you can download it from several places and see if it's the same.

If I'm a developer who releases some software version 1.2.3 with a trojan in it, I can't easily take it back, making the risk of detection significant. You have stuff like the NIST NSRL out there compiling databases of hashes of all the software they can get their hands on. You have security researchers reverse engineering patches looking for silently fixed vulnerabilities.

With a web page it's really easy to serve the trojan once to a specific user. The risk is very low. Hushmail did it, for example.

The fact that operating system vendors have the power to trojan us at will is a huge problem. And thanks to online activation many users are easily identified for targeting. I don't think many people want to talk about it because it's so difficult to fix.

The big issue, as you note, is that you download normal software once, while with a website you download it every time you visit (modulo caching, of course). With free software, you could download it, audit it, and then feel secure using it for a decade or more; with in-browser crypto you're highly unlikely to load the site, audit the code, then use it every time you use it.

Moreover, this constant redownloading enables user targeting: probably no-one will notice if Google serves a slightly different piece of JavaScript to one user.

That's one of the beauties of signed free software: it's public, and many people can collaborate on ensuring that it's secure.

I don't think that the appcache applies to this case because it's under the web server's partial control.