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

21–30 of 85 posts

Re: Cryptography in the Browser

#21

Post by tptacek »

derefr wrote: post #7
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…

> Basically, the JS crypto is reducible to the strength of the SSL connection. Anyone on the other end of the SSL connection, or anyone who can break the SSL connection, can get your plaintext. This makes the JS crypto nothing but overhead. It's just hand-waving at that point. This is true. However, you can say the same thing about, for example, retrieving an ISO of Ubuntu. A cryptosystem is as weak as its weakest li…

People always seem to think that comparing the security of a content-controlled Javascript runtime to that of an ISO image is somehow insightful, as if there was no meaningful difference between those trust models. But I don't think anyone making those comparisons believes what they're saying; I think it's sophistry.

Obviously, you cannot simply assume that an ISO you download off the Internet is secure. That's a problem that's been well known since the mid-1990s, when projects began publishing hashes and PGP signatures of their binaries, widely, so that a discrepancy between what you saw and what someone else saw would stand a good change of being noticed.

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. And not only that, but it complicates the trust evaluation by making it just about as hard as possible to figure out all the components that you actually need to evaluate.

Re: Cryptography in the Browser

#22

Post by tptacek »

ww520 wrote: post #19
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…

Client side Javascript cryptography is about equivalent to SSL; however, it doesn't mean it's not worthwhile to do crypto on the client side. At least the computation load is distributed to all the browsers involved, thus lessen the demand and load on the server.

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.

Re: Cryptography in the Browser

#23

Post by rosser »

bmm6o wrote: post #20
rosser wrote: post #11

Earlier quoted context omitted.

Can you please help me find even an argument in that deck, let alone any refutation ? Did I get an incomplete deck, perhaps? The version I'm seeing stops at slide 22.

He's presumably referring to slides 17-20. It essentially boils down to "JS crypto in the browser is better than nothing".

But it's not — at least not necessarily. That's the problem. It creates a potentially incredibly dangerous false sense of security, and nothing in the deck refutes that, or even argues against it.

Re: Cryptography in the Browser

#24

Post by nlacasse »

foobarqux wrote: post #18

Compiling nacl to javascript is probably a very bad idea without some further analysis. There are almost certainly specialized code constructs that will be lost in the transformation, like branchless code paths, that are designed to prevent certain types of attacks. In fact this is a pretty insidious mistake since you think you are doing the right thing by using a high-quality library.

Emscripten compiles the input source with LLVM, then converts the LLVM bytecode to JS. Most of the optimization passes are done by the LLVM compiler. Are you suggesting that LLVM (or optimizing compilers in general) should not be used to compile crypto libraries?

I completely agree that further analysis is needed on js-nacl, but I hadn't considered that compiler optimizations might lead to vulnerabilities.

Re: Cryptography in the Browser

#25

Post by derefr »

tptacek wrote: post #21
derefr wrote: post #7

Earlier quoted context omitted.

> Basically, the JS crypto is reducible to the strength of the SSL connection. Anyone on the other end of the SSL connection, or anyone who can break the SSL connection, can get your plaintext. This makes the JS crypto nothing but overhead. It's just hand-waving at that point. This is true. However, you can say the same thing about, for example, retrieving an ISO of Ubuntu. A cryptosystem is as weak as its weakest li…

People always seem to think that comparing the security of a content-controlled Javascript runtime to that of an ISO image is somehow insightful, as if there was no meaningful difference between those trust models. But I don't think anyone making those comparisons believes what they're saying; I think it's sophistry. Obviously, you cannot simply assume that an ISO you download off the Internet is secure. That's a pro…

> 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 retrieved on each request. It then becomes exactly equivalent in security to, say, a second-party Ubuntu PPA repository, like the nginx.org PPAs. (With the difference that, even when trusted, the compromised webapp will still run in a browser sandbox, while the compromised PPA gets root access to run scripts.)

Re: Cryptography in the Browser

#26

Post by _prometheus »

foobarqux wrote: post #18

Compiling nacl to javascript is probably a very bad idea without some further analysis. There are almost certainly specialized code constructs that will be lost in the transformation, like branchless code paths, that are designed to prevent certain types of attacks. In fact this is a pretty insidious mistake since you think you are doing the right thing by using a high-quality library.

Or, could use pepper.js.

http://trypepperjs.appspot.com/

https://github.com/google/pepper.js

(note the `google` in the link).

Re: Cryptography in the Browser

#27

Post by cortesoft »

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…

While these known issues are true, and still need to be worked out, I don't think stopping all work on crypto in the browser is the best course of action.

There are technical ways we could mitigate these vulnerabilities (signing of JS downloaded from a site, for example). Maybe having crypto in the browser become a thing is the way that these features get the support to be implemented.

Re: Cryptography in the Browser

#28

Post by Jach »

Judson wrote: post #5
bennyg wrote: post #4

Earlier quoted context omitted.

Is there no way to independently verify that a) the scripts are what they are, and b) that the values change before going to the server?

I have seen people point to using plugins to verify assets delivered by the server, but at that point, why not just do the crypto with the plugin.

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 to trust the new set of JS (maybe it was just a jquery update), try and run the old set instead, or don't run anything. A cool plugin could even connect with a repository of peer-reviewed changes so that non-technical users can still safely use it, so they might see "This change to blah.js has been marked as OK by X respectable users (see reasons)" or "It's a trap! Foobar.com has been compromised by (feds|anonymous|gary)."

Re: Cryptography in the Browser

#29

Post by tptacek »

derefr wrote: post #25
tptacek wrote: post #21

Earlier quoted context omitted.

People always seem to think that comparing the security of a content-controlled Javascript runtime to that of an ISO image is somehow insightful, as if there was no meaningful difference between those trust models. But I don't think anyone making those comparisons believes what they're saying; I think it's sophistry. Obviously, you cannot simply assume that an ISO you download off the Internet is secure. That's a pro…

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

Re: Cryptography in the Browser

#30

Post by pcwalton »

_prometheus wrote: post #26
foobarqux wrote: post #18

Compiling nacl to javascript is probably a very bad idea without some further analysis. There are almost certainly specialized code constructs that will be lost in the transformation, like branchless code paths, that are designed to prevent certain types of attacks. In fact this is a pretty insidious mistake since you think you are doing the right thing by using a high-quality library.

Or, could use pepper.js. http://trypepperjs.appspot.com/ https://github.com/google/pepper.js (note the `google` in the link).

Different NaCl. djb's NaCl is a crypto library. Google's NaCl is a "native code in the browser" component of Chrome/Chromium.

It's terribly confusing, especially since this article talks about both :)

Post reply on HN