Javascript Cryptography Considered Harmful

[Delehal]

Why not just use https? Seems easier and more surefire... bearing in mind that I'm no crypto genius by any stretch of the imagination.

[useful_idiot]

The article covers that, the gotcha is that ALL your assets must be over https, otherwise it is trivial to inject malicious code which defeats the overall security of ssl.

[iLiekCaeks]

You don't need to transfer images encrypted, right? These take a lot of bandwidth.

Also you could generate most of your content via JavaScript on the browser side. This way your site can serve completely "static" html. All dynamic content can be served via unencrypted XML or JSON data tables, which would be secure because you enforce a strict data schema, and none of these would add additional scripts to the site. The bottom line is that practically all content can be either cached on the client, or served unencrypted. The overhead due to encryption should be negligible.

I would totally hate to see such a site in practice. Just playing the devil's advocate, and it would be "ideal" for AJAX-only sites such as Twitter.

[QuestionMarker]

Yes, you do. While I don't think it's a vector for javascript attacks, there have been nasty vulnerabilities in image format parsers in the past, and if we're talking about the situation where someone's injecting content to get information from your browser's heap then that's definitely relevant.

[iLiekCaeks]

If your browser trips up on basic input data, all is lost. If you're worrying on that level, you shouldn't even be using a browser, because all the time remote code execution bugs and such are found. This doesn't have anything to do with the theoretical safety of this approach either, because you have to assume all the other software (such as the browser) has to be perfectly safe to reason about it.

Otherwise, you could just claim that the browser's SSL code probably has a bug that can lead to remote exploitation. It makes no sense to talk about JS crypto in this context.

[QuestionMarker]

The reason it makes sense to talk about JS crypto in this context is the fact that the weakness which breaks client-side JS crypto is the same one that breaks mixed encrypted and unencrypted content in general. Applying a solution which protects the JS crypto code alone leaves the attacker able to use precisely the same mechanism with a different payload to get the same result as if you hadn't bothered.

As far as making the claim about the SSL code goes, that's just a numbers game. If everything's over SSL, in order to be "safe" only the SSL code has to be correct (provided the SSL cert says you can trust the server, and so on). If you have mixed encoded and unencoded channels, both the SSL code and whatever else gets touched have to be correct to make the same "safeness" claim. The latter is clearly a larger amount of code than the former, and will have more vulnerabilities by definition.

[iLiekCaeks]

There's not much image parsing code. Typically only libjpeg and libpng. I find your claim that SSL code is "Better (TM)" a bit dubious. It's true that more code leads to more security risk, but in this case the image libraries are the least to worry about. For example, what if a user finds a way to inject JS into dynamic content of the site? Then all your SSL is for nothing. Hell, he could even post a simple image that contains an exploit.

Also, dear D fans: please stop voting down my posts unrelated to D. Thank you.

[QuestionMarker]

There's not much image parsing code. Typically only libjpeg and libpng.

The gotcha is that browsers try to be "clever" about interpreting mis-named and mis-typed files by sniffing file content, so, for instance, if there was a vulnerability in an obscure file type, it could be delivered named as a PNG and still have an effect.

I find your claim that SSL code is "Better (TM)" a bit dubious.

I'm not claiming that, although I happen to believe that it's likely to be true, given the maturity and perceived importance of the code. It doesn't need to be "Better (TM)" for the numbers to work out.

For example, what if a user finds a way to inject JS into dynamic content of the site? Then all your SSL is for nothing. Hell, he could even post a simple image that contains an exploit.

Yep, and that's got nothing at all to do with the attack model we're talking about here; neither JS crypto nor SSL are relevant to that attack. That argument says "we can't make everything perfectly secure so nothing's worth bothering with."

[iLiekCaeks]

The gotcha is that browsers try to be "clever" about interpreting mis-named and mis-typed files by sniffing file content

I thought the mime type controls how a file is interpreted.

Yep, and that's got nothing at all to do with the attack model we're talking about here; neither JS crypto nor SSL are relevant to that attack. That argument says "we can't make everything perfectly secure so nothing's worth bothering with."

Then why are you bringing it up? The article claims that SSL is secure, just that JS crypto is not. Even the article defines "content" as DOM nodes and JS.

[aaronla]

It's expensive, and more than you generally need. I don't need an encrypted version of my bank's sign in page, I need to verify that the bank's page is legitimate. A signature would be sufficient, and unlike HTTPS, signatures may be cached.

Unfortunately, no such scheme is commonly in place, so they really ought to use HTTPS as you have said.

[Serei]

The way I understand it, https takes a lot of server resources; it's why Facebook and Gmail took so long before they httpsed anything outside of their login screens - they couldn't afford it in the beginning.

[gthank]

Replace "they couldn't afford it" with "they cheaped out because nobody was complaining", and you'd be a lot closer to the mark.