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

Scramble.io: secure email for everyone

dcposch.github.io

Post reply on HN
Print view View original

131–140 of 142 posts

Re: Scramble.io: secure email for everyone

#131

Post by jahewson »

jaekwon wrote: post #75
jahewson wrote: post #50

Earlier quoted context omitted.

Two big questions: 1. How do you revoke a compromised signature comitee certificate embedded in the browser extension? 2. How can you prevent a hostile browser extension from hijacking the validation process?

Hi! These are good questions. 1. We could require the signatures to be recent, and if there are any certificates that need to be revoked, we could require that all signers include that information in the data signed. What do you think? 2. If other hostile browser extensions can hijack the validation process, then the only solution is to not have other browser extensions. Paranoid users who need strong security should…

Re: 1. Yuck - that leaves a window of vulnerability as long as "recent". It also opens up the possibility of hijacking "recent" via NTP to change the client's clock for just the duration of the HTTP GET to the update server - this is not as difficult as it sounds. A better approach would be to have the client pull a list of revoked certs along with the JS source/hash. You'll need a majority wins system for the revocation otherwise the compromised cert could be used to revoke all other certs. Also you need to avoid replay attacks, so you'll have to embed a chain of all previously signed hashes/revocations as well (just being "recent" is not good enough).

Re: 2. Yes, you can't have any other browser extensions. But that is totally unrealistic. It's just a a complete showstopper.

Even a bookmarklet could bypass your cryptosystem!

Re: Scramble.io: secure email for everyone

#132

Post by jaekwon »

jahewson wrote: post #131
jaekwon wrote: post #75

Earlier quoted context omitted.

Hi! These are good questions. 1. We could require the signatures to be recent, and if there are any certificates that need to be revoked, we could require that all signers include that information in the data signed. What do you think? 2. If other hostile browser extensions can hijack the validation process, then the only solution is to not have other browser extensions. Paranoid users who need strong security should…

Re: 1. Yuck - that leaves a window of vulnerability as long as "recent". It also opens up the possibility of hijacking "recent" via NTP to change the client's clock for just the duration of the HTTP GET to the update server - this is not as difficult as it sounds. A better approach would be to have the client pull a list of revoked certs along with the JS source/hash. You'll need a majority wins system for the revoca…

Thanks for the feedback!

>> A better approach would be to have the client pull a list of revoked certs along with the JS source/hash.

That's not much better, as the client will have to pull a list from somewhere, and that somewhere could have been compromised to serve a bad list. At least with a window you always need an absolute majority. I'm not liking any of these solutions, so you make a good case for packaging an extension with all of the client code!

>> It's enough for me because I don't use any browser extensions. Maybe it's a showstopper for you because you use other chrome extensions that you don't trust. Here's an idea -- we could offer the client as a standalone application with embedded Chrome. Then you can have your untrusted browser for all your normal browsing purposes, and a separate Scramble app.

I have no idea what you mean about a bookmarklet bypassing the cryptosystem. Are you suggesting that a user clicking on a malicious bookmarklet can thwart security? The user can always thwart his own security.

Re: Scramble.io: secure email for everyone

#133

Post by jaekwon »

tptacek wrote: post #43
revdinosaur wrote: post #38

Earlier quoted context omitted.

Just to clarify, as I've seen many of your responses to posts on this subject, you're advocating against use of javascript encryption in client-side applications served through the browser. If the encryption library were running on a server using node.js or packaged into a mobile app using a framework like Phonegap it doesn't matter that the implementation is in javascript, does it?

The issue is with browser Javascript, specifically with sensitive Javascript that has to coexist in the same runtime and even the same variable scope as content-controlled code.

All client code is essentially equally sensitive. I'm not sure why you're making a distinction at all.

Re: Scramble.io: secure email for everyone

#134

Post by jaekwon »

peterwwillis wrote: post #126
jaekwon wrote: post #104

Earlier quoted context omitted.

What do you mean by "The only way this could work is based on network participants, and that's highly subjective." ?

If you design based on trusting other nodes (committee and/or trusted peer groups), you have to inherently trust those nodes, and they have to be highly reliable/available, which is kind of ridiculous if you're trying to account for things like oppressive nation states. If you design based on anonymous communication, it's still subject to analysis of network traffic. Even if the messages you're sending are secret, an…

I see. We can't provide secrecy, but I think we can provide some level of deniability, and also make it a pain for those who are surveilling.

I'm not aware of any application that provides secrecy besides BitMessage. Are there others?

Re: Scramble.io: secure email for everyone

#135

Post by JulianMorrison »

mdip wrote: post #61
JulianMorrison wrote: post #10

Unvetted cryptography is worth 1 cereal packet sekrit decoder ring.

Precisely which vetted, client side, JS crypto library would you prefer the authors use to satisfy your concerns? I haven't looked at the code, and only recently started paying attention to the JS-Crypto space. I'm aware of implementations where scrypt was compiled to target the asm.js subset, however, this doesn't really mean the resulting JS running on platform x, in browser y is as secure as the resulting binary o…

This is like printing "may contain arsenic" on candy.

Re: Scramble.io: secure email for everyone

#136

Post by jaekwon »

tptacek wrote: post #107
orthecreedence wrote: post #100

Earlier quoted context omitted.

Perhaps I'm ignorant, but I've read your "JS crypto considered harmful post" and I disagree with the key points. 1. Browsers, at least the ones that matter, provide window.crypto (with a CSPRNG). This makes generating IV's for CBC "safe," makes generating RSA keys "safe," makes generating random keys "safe." Or am I missing something? Assuming the JS crypto code itself is actually sound, the PRNG seems to be the miss…

We are not talking about crypto done in browser extensions. We're talking about a project that knows about extensions, knows how to package their project as an extension, but refuses to do so , because that would cost them users, who generally don't want to install extensions.

Let's try to keep things friendly, or at least correct. We haven't refused anything. Everything is on the table.

Re: Scramble.io: secure email for everyone

#137

Post by tptacek »

jaekwon wrote: post #136
tptacek wrote: post #107

Earlier quoted context omitted.

We are not talking about crypto done in browser extensions. We're talking about a project that knows about extensions, knows how to package their project as an extension, but refuses to do so , because that would cost them users, who generally don't want to install extensions.

Let's try to keep things friendly, or at least correct. We haven't refused anything. Everything is on the table.

Your partner, just upthread, explained why you tabled the idea of using a browser extension to house all the logic for your app. I think your argument is with them, not me.

Re: Scramble.io: secure email for everyone

#138

Post by jaekwon »

tptacek wrote: post #137
jaekwon wrote: post #136

Earlier quoted context omitted.

Let's try to keep things friendly, or at least correct. We haven't refused anything. Everything is on the table.

Your partner, just upthread, explained why you tabled the idea of using a browser extension to house all the logic for your app. I think your argument is with them, not me.

You falsely accused us of refusing to offer a browser extension for fear of losing users. Again, that is false.

Re: Scramble.io: secure email for everyone

#139

Post by ronaldx »

jahewson wrote: post #24
DigitalJack wrote: post #9

Earlier quoted context omitted.

I'm not a programmer. Why can't you just digest or hash the JS?

Because when the JS files are updated the browser extension will have to fetch a new hash from the server, but how can that hash be trusted? The usual mechanism would be to RSA or DSA sign the JS files and have the extension validate the signature against a public key. However, we're still choosing to trust the server and hope that it's key is not compromised.

If the same argument can be applied to software, it's not an argument against using JS.

Re: Scramble.io: secure email for everyone

#140

Post by tptacek »

rubbingalcohol wrote: post #122
marcinw wrote: post #118

Earlier quoted context omitted.

Java, Python, etc don't have a DOM to consider. When you're just an XSS away from an attacker doing: function encrypt(plaintext) { $.post(plaintext, ...); return plaintext; } then you lose. The post talks about this, and XSS isn't the only way either.

If all of the Javascript code and application functionality is bundled into the add-on, it's trivial to avoid XSS. There's no "site" to script into via the URL, and rendering of dynamic elements can be done via a sandboxed iFrame, preventing any scripts from running within dynamic data. This is fairly basic security that any add-on developer should be aware of: http://developer.chrome.com/apps/sandboxingEval.html "XS…

I don't like the article either, but you're wrong about it being "extremely out of date", and you'd have a very hard time defending your argument with evidence. Do try.
Post reply on HN