Hacker News Reader

Comment by mkup | Hacker News Reader

This thing won't replace https anyway, because if transferred over http, Javascript code could be intercepted and modified by adversary before it reaches client browser and before it is actually executed.

And if this JS code is transferred over https, what's the point of it? Don't we already have crypto in this case?

View on HN

Not all uses of cryptography are for encrypting information sent over a channel. Consider bitcoin, which uses public/private keys and hashing functions to create a digital currency. No encryption is even involved.

Couldn't the client verify the integrity of the code against a published hash?

yes, but hash comparison operator will be executed on client side only if it wasn't stripped away along the path

I was thinking of a manual check, which would be a hassle, but would only have to be done when the script was changed.

I suppose it could be combined with some sort of grease monkey type component, where the user supplies their own hash operator code.

At that point, why bother implementing crypto in JavaScript anyway? You might as well just use a proper clientside app (a halfassed version of which is your suggestion).

No! Very common misconception!

You cannot verify the integrity of a browser Javascript cryptosystem by checking a SHA2 hash of the Javascript file containing the crypto.

That's because any other piece of content, from Ajax requests and whatnot to, in many browsers, the CSS files, some of them cached and some of them loaded on the spot... any other piece of content that contributed to the page that hosts the crypto code can alter the runtime to trivially intercept secrets or fix keys.

Until browsers provide a primitive to verify the whole runtime, cryptographic hashes won't do anything to ensure integrity for Javascript.

Unless you are an expert cryptographer and write your own code from scratch, including the compiler and if you are really paranoid building your own hardware, you are always relying on third parties as your source for crypto code and the devices upon which it executes, and you have to trust they they have not inserted backdoors.

This is not an abstract, advanced threat like "someone backdoored your processor."

Javascript sent over the Internet in cleartext is trivial to intercept and alter.

Can you expand on "trivial to alter" part? I get an impression there that many claim that altering JS you get is almost as easy as sniffing your traffic, I'd like to know more why it is so.

Just one possible scenario is pretending to be the access point of your local coffee shop. Some of the coffee shop patrons will connect to your fake access point. Your system can subsequently run their traffic through a proxy that alters web pages to defeat any JS-based crypto, install malware, etc.

http://newstweek.com/overview

I threw together my own implementation of that from scratch when it hit hacker news a few months ago. Mine uses an arbitrary sed script, not sure what theirs does but I believe they've released their source now.. It took about 2 hours max.

Deploying it? Seconds.

Reply on news.ycombinator.com