Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cryptography in the Browser

blog.opal.io

Post reply on HN
Print view View original

61–70 of 85 posts

Re: Cryptography in the Browser

#61

Post by IgorPartola »

moxie wrote: post #2

Client side cryptography is almost always about providing a solution that doesn't require server trust. This article mentions end-to-end encrypted messaging, for instance, which provides the nice property that not even the messaging server can read the message contents. The problem with webapp-based javascript cryptography is that if the crypto code is delivered by the server, then the client is back to trusting the…

So the question then is when will browsers provide access to crypto libraries as a built-in JS API? Clearly, the browser already requires crypto to function. Why can't we standardize a way to access it from the runtime and provide a way to run code against it in a sandbox that would be impervious to things like wrapping one JS function in another?

On top of that we would need some code delivery system with built-in trust verification. This way you could load an up to date copy of PGP written in JS and verify that this code comes from a source you trust.

Then again, this is starting to look a lot like a secure package management system and downloaded software vs the continuously updated web apps we have today, so it might not be worth reinventing the wheel...

Re: Cryptography in the Browser

#62

Post by chinpokomon »

derefr wrote: post #56
lmm wrote: post #36

Earlier quoted context omitted.

If you're running a decent linux you can turn auto-update off. No browser will let you do that.

All the portable-app versions of Chrome and Firefox (for example, the Firefox that comes with the Tor bundle) have auto-update disabled, for both the browser, and included extensions.

I think that was in reference to a web app.

Re: Cryptography in the Browser

#63

Post by ptoomey3 »

moxie wrote: post #2

Client side cryptography is almost always about providing a solution that doesn't require server trust. This article mentions end-to-end encrypted messaging, for instance, which provides the nice property that not even the messaging server can read the message contents. The problem with webapp-based javascript cryptography is that if the crypto code is delivered by the server, then the client is back to trusting the…

I've gone back and forth in my own head about this argument over the years, and I'm still not entirely sure where I come down. But, that said, I have seen the following problem several times, and it seems like client-side crypto provided a reasonable solution.

Challenge: I have a client (web browser) and I have a back-end server (sitting deep behind several layers of intermediate servers of varying degrees of trust) and these two entities need to exchange some sensitive piece of information (a credit card number, etc). How do I transmit this information (either from client to server or the reverse)?

Problems/Assumptions: Let's assume I trust the front end server explicitly to serve fully server-controlled data. Obviously, if we don't trust the server serving me the JS it is all for not. Now, let us also assume that, although my front end server is trusted, it, as well as all of the intermediate servers may accidentally log data that flows through them. In other words, we assume that if I pass a plaintext credit card number over a trusted SSL connection to the server, it, or any of the intermediate servers on the path to the trusted back end server, may accidentally log the sensitive data. How do you solve that problem?

Solution: You could use client-side crypto to create an end-to-end channel that transmits the sensitive data to the back end server.

So, yes, the above solution assumes a fully trusted front end server. In this case, the client side crypto is more to protect the service provider than for the user, but it does seem to provide some sort of "existence proof" in so far as it is a problem that exists in the real world, is made better using client-side crypto, and doesn't seem to have many alternative solutions that provides the same assurances.

P.S. This is more or less what BrainTree does with their client-side encryption for credit card processing (https://www.braintreepayments.com/braintrust/client-side-enc...). In this case, the front end server needs to be trusted, as it is serving up the public key to bootstrap the whole system. But, if we assume the server is trusted (even without client-side crypto we have to assume this for any security) then this approach mitigates the problem of logging credit card data by accident.

Now, maybe this use case is the only legit use of client-side crypto. But, it does make me take pause before dismissing the approach entirely.

Re: Cryptography in the Browser

#64

Post by derefr »

tptacek wrote: post #29
derefr wrote: post #25

Earlier quoted context omitted.

> The problem with booting up crypto in a browser is that it forces you to do that kind of checking on every page load, often at sub-second rates. You ignored the second half of my statement: that by using offline storage and application manifests, URLs become effectively a reference to an application stored in the browser's cache (which can update itself from the web if it wants to), rather than something to be retr…

No, this doesn't work, because the user still needs to validate the DOM every time the page loads.

Also true, for the time being, in most browsers. (Sort of like how "SSL is broken because we don't have certificate pinning yet" is true, for the time being, in most browsers.)

To make sure I understand, let me expand: you're talking about web apps that ever load external assets besides their code package, and then embed those external assets directly into the DOM by giving the DOM the URL (this covers anything from an to a to a ).

This doesn't cover, on the other hand, resources that are retrieved by the code-package into HTML5 ArrayBuffers/Blobs/Files, then validated against a cryptographic signature transmitted over the trusted crypto (SSL or code-package-custom) before the resources are allowed into the DOM through data:/blob: URIs.

These resources, of course, must be self-contained--they can't refer to other resources by URL (which would then be loaded directly by the DOM), only to other data:/blob: URIs. You basically need to pre-parse and "static-check" any HTML, CSS, or Javascript you plan to embed--transitively, spidering referenced URLs--before embedding. This runs into the Halting problem in extremis; if a script you want to embed dynamically builds URLs, you're kind of screwed.

But all this is a diversion from the real problem here, which is that web-applications are inherently not sandboxed from their own "trusted" third party code. You're pretty much "letting Jesus take the wheel" (Jesus being the SSL certificate authorities) when you stick a URL into your web-app's DOM.

The solution, obviously, is to let web-apps have another layer of sandboxing between them and their "content." And there are browsers that do this for web-apps, in specific circumstances; you just usually don't call the result a "web-app." Firefox and Chrome will treat their extensions (which are, in fact, HTML+JS+CSS) this way; Chrome will also treat its "apps" this way (which includes "apps" loaded by URL, instead of being delivered in the .crx!); as will my favorite RIA-toolkit-du-jour, node-webkit. We just need this "fully sandboxed DOM cut-point" feature for the web as a whole.

As far as I know, the only reason we don't have DOM-subtree sandboxing is the potential for iframe-based clickjacking. If we can figure out a way to avoid that specific problem, we'd likely get this feature quite immediately--the code for it is, in most cases, already there. I think we will, eventually. Until then, the data:/blob: workaround is pretty good in limited cases; you rarely need to load HTML/CSS/JS "content" (the kinds that can have transitively-embedded DOM URL references), but can instead build those locally from AJAX conversations, and just verify that the content you do want to embed (images, say) is in a benign file-format before translating it into a blob:.

---

My own favorite solution, by the by, would be something like the Chrome Web Store, but a lot more transparent: you browse to https://example.com/, and if that's registered as a domain "owned" by a web-app in this browser-service, it downloads and zero-config installs the app code-package, temporarily (not yet granting it any permissions in the process) and presents it as if that is exactly what is "at" that URL. This could be combined with storage of an initial pre-HSTS cert, if you do want to use SSL. This means you're implicitly switching from trusting CAs to trusting the browser-manufacturer... but you're doing that anyway by installing the browser in the first place.

Re: Cryptography in the Browser

#65

Post by dsl »

ptoomey3 wrote: post #63
moxie wrote: post #2

Client side cryptography is almost always about providing a solution that doesn't require server trust. This article mentions end-to-end encrypted messaging, for instance, which provides the nice property that not even the messaging server can read the message contents. The problem with webapp-based javascript cryptography is that if the crypto code is delivered by the server, then the client is back to trusting the…

I've gone back and forth in my own head about this argument over the years, and I'm still not entirely sure where I come down. But, that said, I have seen the following problem several times, and it seems like client-side crypto provided a reasonable solution. Challenge: I have a client (web browser) and I have a back-end server (sitting deep behind several layers of intermediate servers of varying degrees of trust)…

> I've gone back and forth in my own head about this argument over the years, and I'm still not entirely sure where I come down

I think you are unfairly reframing it as some sort of debate. It's like not being totally decided on if you should log into your server over telnet from a coffee shop. Even if you don't see the weakness, attackers do.

Re: Cryptography in the Browser

#67

Post by misterparker »

tptacek wrote: post #29
derefr wrote: post #25

Earlier quoted context omitted.

> The problem with booting up crypto in a browser is that it forces you to do that kind of checking on every page load, often at sub-second rates. You ignored the second half of my statement: that by using offline storage and application manifests, URLs become effectively a reference to an application stored in the browser's cache (which can update itself from the web if it wants to), rather than something to be retr…

No, this doesn't work, because the user still needs to validate the DOM every time the page loads.

What about a site like Passpack? https://www.passpack.com/en/home/

- Does that mean a site like passpack is only waving its hands at its security, and that its client-side cryptography is irrelevant and basically insecure??

Re: Cryptography in the Browser

#68

Post by tptacek »

derefr wrote: post #64
tptacek wrote: post #29

Earlier quoted context omitted.

No, this doesn't work, because the user still needs to validate the DOM every time the page loads.

Also true, for the time being, in most browsers. (Sort of like how "SSL is broken because we don't have certificate pinning yet" is true, for the time being, in most browsers.) To make sure I understand, let me expand: you're talking about web apps that ever load external assets besides their code package, and then embed those external assets directly into the DOM by giving the DOM the URL (this covers anything from…

When you come up with a browser design you like that does this, you should submit it to Mozilla or elsewhere to have it considered. But we're not talking about new browser features, or even extensions. We're talking about content-controlled Javascript delivering crypto functionality to end users, and a web page that says that's alright because some browsers have better RNGs now.

Re: Cryptography in the Browser

#69

Post by tptacek »

IgorPartola wrote: post #61
moxie wrote: post #2

Client side cryptography is almost always about providing a solution that doesn't require server trust. This article mentions end-to-end encrypted messaging, for instance, which provides the nice property that not even the messaging server can read the message contents. The problem with webapp-based javascript cryptography is that if the crypto code is delivered by the server, then the client is back to trusting the…

So the question then is when will browsers provide access to crypto libraries as a built-in JS API? Clearly, the browser already requires crypto to function. Why can't we standardize a way to access it from the runtime and provide a way to run code against it in a sandbox that would be impervious to things like wrapping one JS function in another? On top of that we would need some code delivery system with built-in t…

How exactly does it help to provide access to built-in crypto libraries through a JS API? The code that manages those crypto primitives is still content-controlled Javascript.

Re: Cryptography in the Browser

#70

Post by bitexploder »

Came to this thread knowing tptacek would be here, discussing what a terrible idea this was. Got moxie and tptacek. Was not disappointed.

This is effectively a me too, but as someone who has spent considerable time researching, understanding, and explaining this problem to customers, let me just say it is a very dangerous thing to do (try to implement a "secure" system on top of JS Crypto in the browser). Moxie and Tom are completely correct and I cringe every time I see one of these projects.

And if you aren't convinced after reading this thread: http://rdist.root.org/2010/11/29/final-post-on-javascript-cr... start here. He covers the topic exhaustively. I feel like anyone arguing about if this is a good idea should do some research and come to the discussion informed. Nate wrote this article over 2.5 years ago.

Post reply on HN