4 ms·

SSL vs JS crypto is kind of missing the point. There are use cases that SSL does not address. This contest is obviously silly, and I'm not defending the app, b

SSL vs JS crypto is kind of missing the point. There are use cases that SSL does not address. This contest is obviously silly, and I'm not defending the app, but I take issue with the "break SSL = break JS crypto" argument. sslstrip, while a legitimate issue, is closer to phishing than an attack on JS crypto. It's based on tricking the user, not breaking the protocol. I'm not trying to downplay it but I don't think it's fair to equate that with an attack on JS crypto. In an audit, I would point out the things you mention. Consider: 1. The user knows how to look at their address bar and verify that they're on HTTPS. 2. The server gets raided or changes ownership, and the new "owners" are untrusted. Now the inevitable counter argument is, "if you don't trust the server, how do you trust the JS that they are sending you?" My retort would be: 1. Such attacks wouldn't be retroactive. Data is only compromised from the point that you execute the modified JS forward. If it gets owned or raided, and you don't log in, you're still safe. If you trust just SSL, you don't gain this advantage. 2. There can be varying degrees of trust. I can trust that the site operators won't actively attack me, but not trust that the data is unreadable by anyone. Your webhost could expose your data either out of malice or carelessness. It's a significant escalation for your webhost to hijack your site and start changing the code in it. I'm not trying to suggest that JS crypto is safe or that this is a solved problem, but SSL does not provide any solution at all here. JS crypto provides a poor solution, but a much better one than only SSL (though of course it must also be used with SSL). Mega is an example of where JS crypto might have some value. For users to be charged, Mega has to not only get raided, but the feds have to keep it running long enough so users can be attacked with the malicious JS, after which their files can be decrypted. That is far better protection than the first iteration, where a raid meant they already have everything they need to charge everyone, and they just have to start digging offline.

marshray 13y ago
> I can trust that the site operators won't actively attack me, but not trust that the data is unreadable by anyone. Who would it be readable to if not the site operators? > Mega is an example of where JS crypto might have some value. So it might be useful to someone, somewhere as a legal subterfuge. > For users to be charged, Mega has to not only get raided, but the feds have to keep it running long enough so users can be attacked with the malicious JS Good to know that it's secure in the absence of an attacker.
- lawnchair_larry 13y ago
  Well you're being snarky, but I'll address those points anyway. Please understand that I'm not advocating for JS crypto or ignoring its other problems. > Who would it be readable to if not the site operators? SSL offers no protection against the following: Amazon AWS employees. Azure employees. External attackers with read-only access. Employees of the website with read-only access. Employees that get curious and want to snoop, but not badly enough to inject code. Anybody with access to the backups. Other tenants on the same cloud who notice that memory or storage wasn't properly zeroed. Someone who breaks into the office and physically steals the server. > So it might be useful to someone, somewhere as a legal subterfuge. If you acknowledge that it's sufficient to prevent evidence recovery, and you have taken the position that is the only practical scenario under which that property has any utility, you're not a very creative thinker. I'll try to expand your mind a little. I tried to use an easy real example. There was a Google "Site Reliability Engineer" who got fired for snooping on young girls chats and harassing them. He or others in his position would not have been able to deploy new gmail code to perform an active attack, but reading offline storage is trivial. If Gmail sent down Javascript that did the crypto before they got it, this employee would not have been able to do that. I'm reasonably confident that rogue Google or facebook employees aren't going to target me, insert active attacks, and get away with it. I'm not very confident that nobody there will ever passively snoop (don't even need to speculate, both companies have had public incidents at least once). http://www.informationweek.com/security/vulnerabilities/dropbox-files-left-unprotected-open-to-a/231000111 http://www.informationweek.com/security/vulnerabilities/drop... "Dropbox on Monday acknowledged that its vast store of files was left open to the world on Sunday for four hours as a result of a bug. During this period, any account could be accessed using any password. The flaw, a software bug that rendered the service's authentication mechanism non-functional, only took five minutes to fix, once it was discovered. As if on cue, Wuala, a competing cloud storage service operated by hard disk maker La Cie, published a blog post on Tuesday stating that Dropbox's problems wouldn't be an issue if files were encrypted by the client. "Encrypting your files before they are sent to the cloud makes Wuala inherently more secure than solutions that rely on server-side encryption," the company said." http://news.cnet.com/8301-1009_3-57578766-83/vudu-resets-user-passwords-after-hard-drives-lost-in-office-burglary/ http://news.cnet.com/8301-1009_3-57578766-83/vudu-resets-use... > Good to know that it's secure in the absence of an attacker. No, I'll give you a few minutes to read it again though ;) Again, to reiterate, JS crypto has major issues, but it's untrue that you can simply use SSL instead. These are different problems. JS crypto, in its broken state, offers some improvement for some real-world scenarios that SSL does not even attempt to address.
bloblaw 13y ago
> [..] but I take issue with the "break SSL = break JS crypto" argument. Respectfully, I'd suggest that this is not the argument. The argument is that breaking SSL = accessing the data the crypto protects. Crypto is a means to an end...which is protecting sensitive information. moxie decidedly did not "break" the crypto, because he didn't have to. It's a bit like a bank vault with the world's strongest door, but when it was installed they put in a 4' x 5' window next to the door. The vault door (aka the crypto) is fine and unbroken, but I still can get access to your money because your security system has a weak point.
- lawnchair_larry 13y ago
  But it's not a given that you can "break" SSL. The problem that moxie is highlighting actually has no solution (even HSTS isn't a solution) and relies on users to not notice that they have been downgraded to HTTP. Unless moxie also wants to say, with a straight face, that twitter and gmail would be better off disabling HTTPS, I don't think that claim is fair.

marshray 13y ago

> I can trust that the site operators won't actively attack me, but not trust that the data is unreadable by anyone. Who would it be readable to if not the site operators? > Mega is an example of where JS crypto might have some value. So it might be useful to someone, somewhere as a legal subterfuge. > For users to be charged, Mega has to not only get raided, but the feds have to keep it running long enough so users can be attacked with the malicious JS Good to know that it's secure in the absence of an attacker.

lawnchair_larry 13y ago
Well you're being snarky, but I'll address those points anyway. Please understand that I'm not advocating for JS crypto or ignoring its other problems. > Who would it be readable to if not the site operators? SSL offers no protection against the following: Amazon AWS employees. Azure employees. External attackers with read-only access. Employees of the website with read-only access. Employees that get curious and want to snoop, but not badly enough to inject code. Anybody with access to the backups. Other tenants on the same cloud who notice that memory or storage wasn't properly zeroed. Someone who breaks into the office and physically steals the server. > So it might be useful to someone, somewhere as a legal subterfuge. If you acknowledge that it's sufficient to prevent evidence recovery, and you have taken the position that is the only practical scenario under which that property has any utility, you're not a very creative thinker. I'll try to expand your mind a little. I tried to use an easy real example. There was a Google "Site Reliability Engineer" who got fired for snooping on young girls chats and harassing them. He or others in his position would not have been able to deploy new gmail code to perform an active attack, but reading offline storage is trivial. If Gmail sent down Javascript that did the crypto before they got it, this employee would not have been able to do that. I'm reasonably confident that rogue Google or facebook employees aren't going to target me, insert active attacks, and get away with it. I'm not very confident that nobody there will ever passively snoop (don't even need to speculate, both companies have had public incidents at least once). http://www.informationweek.com/security/vulnerabilities/dropbox-files-left-unprotected-open-to-a/231000111 http://www.informationweek.com/security/vulnerabilities/drop... "Dropbox on Monday acknowledged that its vast store of files was left open to the world on Sunday for four hours as a result of a bug. During this period, any account could be accessed using any password. The flaw, a software bug that rendered the service's authentication mechanism non-functional, only took five minutes to fix, once it was discovered. As if on cue, Wuala, a competing cloud storage service operated by hard disk maker La Cie, published a blog post on Tuesday stating that Dropbox's problems wouldn't be an issue if files were encrypted by the client. "Encrypting your files before they are sent to the cloud makes Wuala inherently more secure than solutions that rely on server-side encryption," the company said." http://news.cnet.com/8301-1009_3-57578766-83/vudu-resets-user-passwords-after-hard-drives-lost-in-office-burglary/ http://news.cnet.com/8301-1009_3-57578766-83/vudu-resets-use... > Good to know that it's secure in the absence of an attacker. No, I'll give you a few minutes to read it again though ;) Again, to reiterate, JS crypto has major issues, but it's untrue that you can simply use SSL instead. These are different problems. JS crypto, in its broken state, offers some improvement for some real-world scenarios that SSL does not even attempt to address.

bloblaw 13y ago

> [..] but I take issue with the "break SSL = break JS crypto" argument. Respectfully, I'd suggest that this is not the argument. The argument is that breaking SSL = accessing the data the crypto protects. Crypto is a means to an end...which is protecting sensitive information. moxie decidedly did not "break" the crypto, because he didn't have to. It's a bit like a bank vault with the world's strongest door, but when it was installed they put in a 4' x 5' window next to the door. The vault door (aka the crypto) is fine and unbroken, but I still can get access to your money because your security system has a weak point.

lawnchair_larry 13y ago
But it's not a given that you can "break" SSL. The problem that moxie is highlighting actually has no solution (even HSTS isn't a solution) and relies on users to not notice that they have been downgraded to HTTP. Unless moxie also wants to say, with a straight face, that twitter and gmail would be better off disabling HTTPS, I don't think that claim is fair.