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

71–80 of 85 posts

Re: Cryptography in the Browser

#71

Post by ptoomey3 »

dsl wrote: post #65
ptoomey3 wrote: post #63

Earlier quoted context omitted.

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.

I didn't mean to imply a debate...only that the reductionist viewpoint "it is only as secure as SSL, so just use SSL" doesn't quite sit right with me; the problem feels a bit more grey.

In the particular scenario I proposed the only attacker we are trying to protect against is a completely passive attacker than can possibly view our logs from servers along the path to our back end server. Obviously in the world of crypto that is a ridiculously weak adversary, and not one you want to hang your hat on when designing a crypto system. But, it is an adversary that plenty of companies are concerned with.

For example, because sensitive data is not something you can "unsee", it would be ideal if one could ensure that even trusted employees are never witness to the information. For example, I could be a completely trusted employee that sees an accidentally logged credit card. The bell has been rung..there is no going back. In that situation, even though there is no adversary in the malicious stance, it is a problem that can occur and many people would like to solve it.

Re: Cryptography in the Browser

#72

Post by derefr »

tptacek wrote: post #68
derefr wrote: post #64

Earlier quoted context omitted.

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.

Okay, you're right here. (I said you were right the other two times, too. This time I'll emphasize it.)

Content-controlled Javascript is not alright. Content-controlled Javascript is, in fact, why browsers have sandboxes in the first place (think about this: if they could get away with less, they would; and in the current security model, you don't get to sandbox yourself from your content when you are the content, so you don't get to get away with anything.) You need some sort of stable base, living in the client, to build any sort of cryptographic security upon. That means, at the very least, Javascript that comes from a file: or blob: URI.

You can use SSL to bootstrap up to that, delivering an initial payload which will then be loaded. But you can't keep the advantages of the web-app model (refreshed from the server with every page-load! embed arbitrary DOM content by URL!) when you do this; you have to switch to thinking like a local-app developer, who downloads and sig-checks "updates", and who downloads and validates "content" (so your image doesn't turn into a script half-way through), before making use of either. Effectively, you don't have a web-app any more.

You can't take any web-app that's already been written and just "throw in" a crypto library, and consider yourself secure. You aren't. Don't listen to the article. Either trust SSL (i.e., trust your crypto provider with your plaintexts), or use some sort of locally-fixed-client implementation: if not a native app, then at least a Chrome App or something.

Re: Cryptography in the Browser

#73

Post by IgorPartola »

tptacek wrote: post #69
IgorPartola wrote: post #61

Earlier quoted context omitted.

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 .

It doesn't (though one might argue that as a result we will see much fewer JS implementations of AES coming out). What I am talking about is a better way to distribute the code, the ability to verify the code, the ability to sandbox it, and a proper secure crypto implementation to rest this on.

Basically, I want the contents of GMail messages (ones I compose and ones I read) to be rendered in a sandbox to which the rest of the page has no access. Moreover, I want to get the code that makes the sandbox tick to not come from Google, but from a third part I actually trust.

Once again, this starts looking a lot like normal downloaded apps with package signing, and less like the web. I am not certain there is a middle ground between the two that provides both security and convenience.

Re: Cryptography in the Browser

#74

Post by Jach »

tptacek wrote: post #47
Jach wrote: post #28

Earlier quoted context omitted.

The benefit of a plugin to verify assets is that it can work with other things besides the crypto lib. As your sibling comment mentions an attacker could deliver other JS that just traces your input or something different. Well, a user could ask a plugin to say "Hey, track the JS on this page. Alert me if any of it changes, any of it is removed, or any new JS is added." After an alert, the user can see a diff, decide…

How exactly do you use a plugin to verify the state of a Javascript runtime? You can't just verify assets; you need to verify the current bindings of every function relevant to your crypto code.

How are the bindings supposed to change without loading different assets, apart from an eval() somewhere?

Re: Cryptography in the Browser

#75

Post by zentrus »

Having the crypto code delivered by the server to provide real-time "end-to-end" security is surely a problem. But, I believe there is a specific use case where even not-so-perfect javascript crypto increases security in a significant way. Imagine you have a system where you want to send encrypted files that are stored on the server to be downloaded later by other users. With javascript public key crypto a la PGP, the user could encrypt this file using keys stored locally. These keys are "uploaded" to the web page when they are needed but not actually sent to the server. The cipher text only is then uploaded to the server and stored. Recipient users can then download the file and decrypt in a similar manner.

So what does this help protect against? You are mitigating the situation where the server becomes compromised. In the event your server is compromised, any previously encrypted files are protected as long as the keys are not used again after compromise (since malicious javascript could be delivered to obtain the key).

Re: Cryptography in the Browser

#76

Post by IgorPartola »

ptoomey3 wrote: post #71
dsl wrote: post #65

Earlier quoted context omitted.

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

I didn't mean to imply a debate...only that the reductionist viewpoint "it is only as secure as SSL, so just use SSL" doesn't quite sit right with me; the problem feels a bit more grey. In the particular scenario I proposed the only attacker we are trying to protect against is a completely passive attacker than can possibly view our logs from servers along the path to our back end server. Obviously in the world of cr…

Security is reductionist. Once your system is broken it doesn't matter how or where, it just is. If you need SSL, you must use it. You cannot hack around it, since the attacker will simply MITM you without it, or find a side channel to load the malicious code and then use one of the dozens of flexibilities in the JS runtime to get your sensitive info.

The opposite is also true: if your SSL setup is compromised (e.g. Leaked private key), client side crypto does nothing to protect you since the attacker can just MITM your crypto code inside the runtime, get data out of the DOM, etc.

There are no cases left where client side crypto provides any additional security. Some future server-browser model might change that, but not anything that exists on the web currently.

Re: Cryptography in the Browser

#77

Post by napoleond »

Say it with me: browser crypto is bad. But if everyone really wants to build crypto apps using front-end skillsets (which I can understand, because I've done it[0]), go for it! Who says you need a browser? Use Phonegap[1], or node-webkit[2], or appjs[3], or TideSDK[4] (well, not Tide, unless you're a masochist). If you don't want/can't use Node's crypto stuff[5], use SJCL[6] or OpenPGP.js[7] (the last two are not battle-proof libraries, though, because browser crypto is bad so few serious cryptographers have bothered to review them... hopefully that will change if enough people use them outside of the browser). Voila! The convenience of the tools you know, and automatic cross-platform access, without the badness of browser crypto.

0. https://parley.co

1. http://phonegap.com/

2. https://github.com/rogerwang/node-webkit

3. http://appjs.com/

4. http://www.tidesdk.org/

5. http://nodejs.org/api/crypto.html

6. http://crypto.stanford.edu/sjcl/

7. http://openpgpjs.org/

Re: Cryptography in the Browser

#78

Post by yeleti »

We implemented a system where the key used to encrypt messages is generated in the browser and never leaves the browser. This ensures even we cant decrypt messages. The downside is the end user has to remember a 'Room Secret Key'.

You can read more here: https://www.tesla.im/#encrypted_rooms

We are just a few weeks into beta and have only a few hundred users. Been working well so far. However it's too early for us to give solid validations.

Re: Cryptography in the Browser

#79

Post by tptacek »

Jach wrote: post #74
tptacek wrote: post #47

Earlier quoted context omitted.

How exactly do you use a plugin to verify the state of a Javascript runtime? You can't just verify assets; you need to verify the current bindings of every function relevant to your crypto code.

How are the bindings supposed to change without loading different assets, apart from an eval() somewhere?

List every possible way a browser Javascript application might end up rebinding a function.

Re: Cryptography in the Browser

#80

Post by JoachimSchipper »

ww520 wrote: post #52
tptacek wrote: post #22

Earlier quoted context omitted.

You can't securely load crypto into a browser without SSL, so the server is bearing that load anyways. All you're doing is adding additional load on the clients.

Given a client side crypto implementation with SSL as the delivery mechanism, the only load on the server is the content delivery and the SSL computation itself. Any of the application-specific crypto load can be done on the browser instead on the server. Let's say the app is encrypting 1meg Excel file and 100K people are using it. I would rather letting the browsers do the work than beef up the servers to do the enc…

This article has long scrolled off the front page, so just a quick reply: modern crypto is fast. Look up the speed on AES-GCM with AES-NI, PCLMULQDQ; on a modern multicore server, your 100GB can be encrypted in a couple of seconds. (Or rather, the crypto isn't remotely the bottleneck.)
Post reply on HN