undefined | Better HN

0 pointsmpowers12y ago0 comments

If your device or browser is compromised, you have bigger problems than someone subtly modifying your js runtime.

Similarly if a host is compromised to serve bad js files. We can't solve endpoint security. And clearly NSA is now very good at breaking the endpoint at both ends.

I agree that it's not useful to say "just inspect the code"; no one really inspects their binary executables either, but we're committed to let you do so.

Let me be clear that JS is not required; it's just how we're making our reference client because we don't believe most people are going to download a custom client.

You can write a working client with bash+openSSL+curl if you want. The whole thing is simply signed text snippets over http.

0 comments

timtadh12y ago

> If your device or browser is compromised, you have bigger problems than someone subtly modifying your js runtime.

It is trivial to compromise the browser context of the page. In the case of a browser bug another tab can interact badly with the current tab. In the case of a MITM attack on (sadly quite possible given the potential adversary) the attacker can modify the JS in flight to the browser. In the case of an externally loaded resource embedded on the page that resource may modify the execution of your crypto. There are also CSFR, XSS and other JS vulnerabilities to account for.

Javascript is a hopelessly bad place to do crypto. Consider doing an signed browser extension that does this on the desktop and native apps on the phone. I would also suggest a native app on the desktop as well. People seem to really like them for twitter.

mpowersOP12y ago

I appreciate your concern, but you can't fault JS for browser bugs or OS bugs.

It's also not clear to me why you're any more secure with a signed browser extension or native app. Just because it's signed doesn't mean you can trust it any more than you can trust JS that you download via HTTPS from a server. What's worse, you didn't compile it from source, so how can you know there's nothing sinister lurking in there?

You are correct that people like native apps for their microblogging, and we want to encourage many native, hardened, peer-reviewed implementations for every platform imaginable.

Because the client is just appending signed entries to the end of an RSS file, send pushing and pulling those files over http, you could write a nice client running inside emacs (if you trusted your os crypto libs).

e12e12y ago

> It's also not clear to me why you're any more secure with a signed browser extension or native app. Just because it's signed doesn't mean you can trust it any more than you can trust JS that you download via HTTPS from a server.

For one, one would hope that a team takes more care to manage their private (code) signing key, than their ssl private key. The signing key should probably be on an air gapped system. That isn't feasible with the key use for https/tls.

You could compromise ftp-servers all day without being able to generate a valid signature for your bad code.

Now, on the subject of: Wouldn't it be possible, in the future, to create mechanism where we could deliver signed js code in a more secure manner than we do today? Absolutely. But it that future doesn't seem to be arriving any time soon.

tptacek12y ago

I don't even know how to respond to this: "the endpoints might be compromised, so why bother making the crypto secure"? That's the idea?

Browser JS is a uniquely terrible vector for delivering crypto to end users. Use something different.

mpowersOP12y ago

Your logical fallacy is: putting words into my mouth (argumentum ad logicam). I didn't say "why bother making the crypto" secure. I said that you can't point to endpoint security as a reason to fault JS more than you can fault every other crypto implementation.

Schneier thinks NSA may have already compromised certain binaries and checksums, and John Gilmore is wondering if certain source trees have been compromised.

JS is not immune to these kinds of attacks, nor is it any more susceptible. All we can do is make sure our implementation is clear and correct and avoids browser exploits. We can't control your binaries, OS, browser, or otherwise.

j / k navigate · click thread line to collapse

0 comments

timtadh12y ago

> If your device or browser is compromised, you have bigger problems than someone subtly modifying your js runtime.

mpowersOP12y ago

I appreciate your concern, but you can't fault JS for browser bugs or OS bugs.

You are correct that people like native apps for their microblogging, and we want to encourage many native, hardened, peer-reviewed implementations for every platform imaginable.

e12e12y ago

You could compromise ftp-servers all day without being able to generate a valid signature for your bad code.

tptacek12y ago

I don't even know how to respond to this: "the endpoints might be compromised, so why bother making the crypto secure"? That's the idea?

Browser JS is a uniquely terrible vector for delivering crypto to end users. Use something different.

mpowersOP12y ago

Schneier thinks NSA may have already compromised certain binaries and checksums, and John Gilmore is wondering if certain source trees have been compromised.

j / k navigate · click thread line to collapse