[explorigin]

This is not a "good" article. It's very hand wavey with lots of fud.

For example, he talks about the chicken and egg problem of delivering javascript over an insecure connection and then solves it later with SSL/TLS (but he doesn't acknowledge that this is a valid solution). Furthermore, we're all harping on javascript when you can't download PuTTY over an SSL connection.

He talks about browser cache but says that javascript can't control it. That doesn't mean it can't be controlled (see MANIFEST file).

I could go on, but the point is made, there are answers to the problems raised in the article. They may not be _easy_ (as the article complains some things are complex), but it's security on wildly complex systems...of course it's hard.

[hluska]

I think that I disagree, but I am not experienced enough to know what I don't know. Judging from your response, you know way more than me, so if it's okay with you, I will tell you why I disagree. Then, it would make my day (and help me a tremendous amount) if you would tell me why I am wrong.

a) The chicken and egg problem of delivering javascript:

I am far from being good at this stuff, but I am confident that, given the opportunity if you deliver .js (or anything else) over an insecure connection, I can modify the content before it ever reaches the user.

As you and the article state, you could solve this problem by delivering the .js file with SSL/TLS. But, if you do this, I presume that you would need to encrypt every single resource on the page. And, if you have already gone that far, what would you gain by implementing browser based crypto when you have already solved the problem?

It strikes me that SSL/TLS are old enough to be well tested and researched, whereas if I wake up some morning and decide to implement my own crypto, I'm going to f* something up. I'd rather let smarter people do the heavy lifting.

But, I don't know what I don't know. What don't I know?

Furthermore, we're all harping on javascript when you can't download PuTTY over an SSL connection.

Please correct me if I am wrong, but if you can download PuTTY via an insecure connection, an attacker can just as trivially swap out the real version of PuTTY with a compromised version. That sounds really dangerous, but isn't that why the PuTTY developers add RSA/DSA signatures to their downloads page?

I would argue that if someone is smart enough to find a collision in both RSA and DSA, they can likely find easier ways to attack me than to swap out the real version of PuTTY with a compromised version.

What am I missing? disregard this question because I missed something very important - see my edit below

He talks about browser cache but says that javascript can't control it. That doesn't mean it can't be controlled (see MANIFEST file).

Thank you for this - I need to do some more reading. Though, wouldn't you get into the same problem where, unless you can control every single resource on the page (ie - serve it encrypted and make sure there are no XSS vulnerabilities) you can't guarantee that the browser is using the correct code? Then, doesn't that get back to the chicken and egg problem where if you're already implementing encryption, you don't need crypto in the browser?

--

Some of the ideas on that page (ie - the inability to generate strong random numbers) are kind of outdated. I believe that Opera uses a cryptographically secure Math.Random(). And, I think that there is an API to accomplish this in other browsers. window.crypto.GetRandom or something?

However, I still see all kinds of traffic with old versions of Internet Explorer (sorry to pick on IE). Wouldn't solving the crypto in a browser problem reliably require making everyone update to a modern browser?

I hope that I'm not coming across as being difficult, but I would love to learn and would appreciate any help you would provide.

Edited -- jimktrains2 wrote:

But those sigs are also coming over a non-ssl connection:-p

There goes my entire RSA/DSA argument! What a great thread...

[kybernetikos]

> if you have already gone that far, what would you gain by implementing browser based crypto when you have already solved the problem?

This is indeed the point made by Matasano, but I don't think it's valid. Sometimes you want to segment the trust, or maybe your software provider doesn't even want to be in the data storage game. So I might trust one entity to provide me with software to manage my inbox, particularly if I can inspect that software at will, and have seen it pass through a security review, however I might not want to trust them with actually storing the contents of my inbox. In that case, it's nice to be able to encrypt the inbox (and the index, to allow for nice searching) in my browser, and then actually store them on a commodity storage provider (s3 or dropbox). And yes, I'd use modern web standards to give the user control over when a new version was downloaded too.

So, I need to get the software over SSL, and be able to verify within reason that it does what it is supposed to, and then use that trusted software to work with data which I can store on untrusted services.

[rickycook]

Not to mention that it will protect the data at rest in the DB, where storing crypto keys on the server is as bad as plain text because they can just be harvested from wherever you store them... Obviously. Now, if your server is compromised then the attacker can deliver JS to the client, but the client needs to load the page and decrypt their data for this to apply; the attacker can't just wholesale steal all your data.

[dublinben]

>we're all harping on javascript when you can't download PuTTY over an SSL connection

This shouldn't matter, and would just provide a false sense of security. You ought to be verifying the signature of any program you're installing before you use it. Since you're running Windows the point is probably moot, but it is possible to install software reasonably securely.

[jimktrains2]

But those sigs are also coming over a non-ssl connection:-p

Honestly, whenever you download anything, evne over SSL, you're essentially trusting that the remote computer is not only who you think the computer is, but the person you expect to be controlling it is the only person controlling it.

Out-of-band communication built out-of in-person trust are really the only way around that (i.e. trusting someone who trusts the PuTTY devs and gets you the hash/sig).

[dublinben]

You only need to trust their signature to really be sure. That's why the Web of Trust aspect of PGP/GPG is so important. It's probably more valuable than the ability to encrypt a few emails.

[schoen]

It doesn't seem that PuTTY has made very effective use of this or managed to explain the problem to most of their users.

http://noncombatant.org/2014/03/03/downloading-software-safe... http://noncombatant.org/2014/03/05/followup-to-downloading-s...

[tptacek]

I don't much like this article either, despite being its author, but I don't see how you've managed to refute its applicability to the application being discussed on the thread. The mutual exclusion referenced up thread is real.

[_dps]

Because this article is highly cited, and because you strike me as a personality who would appreciate micro-detail feedback: there is a typo ("algoritms") in the first sentence that immediately threw off my attention from an otherwise quite interesting piece of writing.

This is offered with respect and not a desire to nitpick. I hope it doesn't come across as annoying :)