Doesn't virtually all encryption on user computers come from servers? I mean, Chrome updates itself from a server, and I first downloaded it from the same server. Google (or anyone breaking in to Google) could maliciously break the SSL code in my browser and I'd never even know it had been updated.
Likewise, I downloaded dropbox and putty and ssh.exe from servers, all apps I installed on my phone came from a server and were put there by people I don't know at all.
Why is in-browser encryption considered so different that even smart people like tptacek get all worked up about it? Is it that browser apps get "reinstalled" on every use, and not "only" when an autoupdater or user detects a new version? If so, can I use appcache to achieve the same and enjoy the exact same security as I'd get in an installed app(lication)?
In short, what am I missing?
(note to the angry security people: I'm not dissing you, I really don't know. I'd appreciate non-snarky replies)
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.
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).
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.
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.
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?
> 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.
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.
There should be a way of having the browser (outside of the JS) verify the hash/signature of a page against an external repository which would verify that this page had been independently audited.
It's interesting that it's relatively easy to do this with native client software (hash/signature, manually check it), but less so with browser based applications.
That's not necessarily what we want in the land of crypto. We want something more like "Offer to get the latest code from the server, but ask the user for permission first, because maybe the server has been compromised."
It's more of a self-hosting solution I think.