Hacker News Reader

Comment by tptacek | Hacker News Reader

If the protocol is delivered over HTTP and runs in Javascript DOM context, it will be straightforward for an adversary that MITMs all traffic to defeat it.

View on HN

Yes, you'd have to sideload the initial keys/code, presumably outside the country. It works for Netflix because it's baked into the client. But at least once you've somehow gotten the keys you won't get stopped by the government blocking it since it isn't 'https' and doesn't look like 'https'.

Until they figure it out and start blocking that too of course.

Curious. How do you go about (trivially) defeating asymmetric encryption?

EDIT: or do you mean to replace "all" (content + js)?

No, just inject some JS that reads the required keys.

Okay, so it's (just) for reading the delivered data. Somehow I keep considering MitM a harmful attack (i.e. manipulating the data before it hits the user). My bad :)

Can do that through injected JS as well.

Given that you're relying on server-provided JS to verify the integrity of the data in the first place, a MITM could replace the verification function with return(true) and then inject whatever data they want.

Pretty sure that Netflix loads a Flash client (or some other trusted code module) to prevent this. But you're right; the browser isn't secure enough to enable client-side encryption over HTTP as it would be trivial to MITM and sideload JS code to defeat it.

That's the problem with "client-side encryption". It doesn't work because the provider also has the power to replace the code with no say from you.

And it's not very detectible because they do it all the time.

It’s the same reason why any DRM is completely pointless: It only provides inconvenience for the legitimate user.

I own Anno 2070 (as can be seen on my steam profile), but can only play with RELOADED crack under wine because UPlay refuses to run.

Same with this type of encryption: Kazahstan can easily defeat it, but it makes it harder for people trying to debug why they can’t use Netflix (for example, in case that Kazahstan MitM's everything, and encrypts with a different certificate than your Netflix client is using).

Client side encryption works just fine. It's only a problem in a browser where you have to download the possibly-MitM'd program each time you want to use it. Actual installed client software that encrypts end-to-end is the proper way to use encryption.

One catch: remember that the browser itself absolutely should not be the installed program doing the end-to-end encryption, where bugs can allow the private keys to be leaked. Important data like the private keys shouldn't even be in the same address space. See gpg-agent/ssh-agent as an examples of how to keep sensitive data in a separate process.

Nit: you are effectively re-downloading browser DOM JS crypto programs every time your browser loads a new DOM element for the page hosting the app. It's not just something that happens when you first visit the site.

That's one of the things that makes securing browser JS crypto so intractable.

Meh; you can't trust the first version anyway, which makes anything happening later on the page just as broken.

If it's an additional source being added much later on that you are concerned with, that's always been a broken design that Douglas Crockford warned[1] about years ago.

[1] https://www.youtube.com/watch?v=V13wmj88Zx8

Reply on news.ycombinator.com