3 ms·

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

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

walterbell 12y ago
> 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?
- JulianMorrison 12y ago
  That (c) honestly sounds to me like it ought to be a web standard, signed authenticated javascript.
- taf2 12y ago
  (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...
  - walterbell 12y ago
    In theory, users could choose their own verification authority.
- tptacek 12y ago
  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.
  - walterbell 12y ago
    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?
skrebbel 12y ago
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.

walterbell 12y ago

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

JulianMorrison 12y ago
That (c) honestly sounds to me like it ought to be a web standard, signed authenticated javascript.
taf2 12y ago
(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...
- walterbell 12y ago
  In theory, users could choose their own verification authority.
tptacek 12y ago
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.
- walterbell 12y ago
  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?

skrebbel 12y ago

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.