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

31–40 of 85 posts

Re: Cryptography in the Browser

#31

Post by nwh »

cortesoft wrote: post #27
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.

It always comes down to this; would you prefer security, or just something that makes you feel fuzzy? Crypto in JavaScript only gives the latter.

Re: Cryptography in the Browser

#32

Post by tinco »

cortesoft wrote: post #27
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.

Please note the implications of this. The signed javascript would have to be hosted on a separate third party website, and it would have to be the _only_ script content of the website.

Since code can be executed by almost every resource on a webpage, basically the entire would have to be stored on that separate third party website, the html, the css, maybe throw in the images too given their history of weird exploits.

Not saying that's a very crazy idea, but I'm saying it's way beyond the scope of these opal guys, and probably not what most people 'working out' browser crypto are after.

Re: Cryptography in the Browser

#33

Post by nlacasse »

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…

Thanks for the reply.

Opal requires as little trust as possible, but you are correct that some server-trust is required at the moment.

I hope that apps like Opal will encourage more progress on browser/javascript cryptography. The W3C crypto spec is coming along nicely, and things like Content Security Policy address some of the concerns about delivering secure javascript.

One nice thing about web-apps is that they are by-default open source, and browsers are bundled with all sorts of diagnostic tools. Anybody who worries that their data is being "sprayed" can just open the network tab and see exactly what is being sent over the wire. Obviously we don't expect many users to do this, but it's one way to enforce our honesty until better solutions exist.

Re: Cryptography in the Browser

#34

Post by moxie »

cortesoft wrote: post #27
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.

If this were a blog post with a proposal for changes to implement a workable JS crypto mechanism, that'd be great, but it's a actually blog post about how some people are going to implement a "secure" service using a mechanism that's known to be insecure.

This isn't a new idea that we're shooting down before it has a chance to fully form. It's something that people have been trying, and making dangerous security claims about, for at least 10 years.

It's possible that the core issues are resolvable, but they would likely require substantial changes to the way the web browser works. Whenever people start thinking about a way to make a mechanism like this work correctly, the scope of what's required unravels quickly. At this point, I don't know of any defined or even partially articulated proposal that makes sense and accounts for the bulk of the gotchas.

Given that we haven't even been able to get correctly-scopable cookies yet (something the vast majority of the web wants and which has been clearly defined and articulated for many years), I'm not sure that we should hold our breath for this.

Re: Cryptography in the Browser

#35

Post by nlacasse »

nwh wrote: post #31
cortesoft wrote: post #27

Earlier quoted context omitted.

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.

It always comes down to this; would you prefer security, or just something that makes you feel fuzzy? Crypto in JavaScript only gives the latter.

I disagree. Javascript cryptography can provide real security, it's just important to keep in mind what is being secured, and where the vulnerabilities are. Currently, js crypto is vulnerable in that its difficult to verify that the js a browser is running is the intented code.

Every day, millions of people are sending sensitive data over very insecure channels like email and DropBox because secure tools like PGP are to difficult for them or their friends to use. Clearly some security is better than none, as long as the limitations are known.

Re: Cryptography in the Browser

#36

Post by lmm »

derefr wrote: post #12
DanBC wrote: post #10

Earlier quoted context omitted.

> You can build a webapp that is only ever downloaded once, and from then on loads its own code from the filesystem; and which verifies new "releases" of its own source using whatever crypto it likes before overwriting the client-side stored copies of itself. But if you don't trust Hushmail they could force a back-doored update onto you.

At that point you've got "well, that's not worse than anything else, then" security. The NSA, for example, could MITM your computer's connection to Ubuntu's update servers, FISA a sysadmin for a copy of their package signing key, and inject a "critical security update" only for you. Auto-update systems are suspicious as a whole, now, and should only be trusted in general as a compromise to convenience, and the statis…

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

Re: Cryptography in the Browser

#37

Post by jerrya »

tinco wrote: post #32
cortesoft wrote: post #27

Earlier quoted context omitted.

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.

Please note the implications of this. The signed javascript would have to be hosted on a separate third party website, and it would have to be the _only_ script content of the website. Since code can be executed by almost every resource on a webpage, basically the entire would have to be stored on that separate third party website, the html, the css, maybe throw in the images too given their history of weird exploits…

And yet, jsquery works that way, doesn't it? Everyone pulls jsquery in from basically one site...

Does the entire website have to be on that separate third party location, or just a self-booting kernel of crypto to enable a signed website to be downloaded from the desired source?

Re: Cryptography in the Browser

#38

Post by peterwwillis »

All browsers already have crypto. Why the fuck are people trying to invent their own when it's built in?

http://en.wikipedia.org/wiki/Network_Security_Services

https://developer.mozilla.org/en-US/docs/Mozilla_Crypto_FAQ

All you need is some kind of new "Web Standard" glue between the browser and the JS and do whatever you feel like using the native crypto functionality of the browser. You don't need to add more layers of complexity. But you can add a small bit of abstraction to what is already there.

Re: Cryptography in the Browser

#39

Post by lmm »

cortesoft wrote: post #27
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.

No. Crypto is a rare case where broken crypto is actually worse than no crypto at all. When a product claims to have encryption people trust that encryption. If the encryption is not actually effective, that compromises their security. In some cases (e.g. dissidents in oppressive regimes), that gets them killed.

Re: Cryptography in the Browser

#40

Post by tptacek »

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

Thanks for the reply. Opal requires as little trust as possible, but you are correct that some server-trust is required at the moment. I hope that apps like Opal will encourage more progress on browser/javascript cryptography. The W3C crypto spec is coming along nicely, and things like Content Security Policy address some of the concerns about delivering secure javascript. One nice thing about web-apps is that they a…

I think building something you know to be insecure and providing it to your user along with an assurance that your service takes their security seriously is a poor way to motivate other people (here, browser vendors) to build that security for you.

Meanwhile: the network tab thing only does anything if you do it every time and validate all the content. Nobody does this, ever.

Post reply on HN