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.
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.
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.
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.
> 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/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-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.
Any snake oil is sufficient to thwart some attacker somewhere some of the time.
Browser Script Crypto adds a lot of complexity. It also adds a metric crapton of insidious counter-intuitiveness to the security model.
These are real and serious engineering drawbacks to BSC. In order for BSC is worthwhile in a given situation, you need to show that any benefits it may bring outweigh the drawbacks and do so better than other solutions.
This is never the case in practice, because BSC is vulnerable to all the same attacks as the web browser.
> There was a Google "Site Reliability Engineer" who got fired for snooping on young girls chats and harassing them.
Solution: Publicly fire the guy. Don't log the chats.
> If Gmail sent down Javascript that did the crypto before they got it, this employee would not have been able to do that.
I think you're assuming that based on the belief that this engineer would not have been able and willing to conduct an active attack. What is your evidence for this belief?
> I'm not very confident that nobody there will ever passively snoop
Snooping is their (Google/Facebook) business model. It's just a question of whether or not their internal authorization process was followed.
BSC doesn't solve the problem of the insider threat. It may make it marginally more risky for some insiders some of the time, but there are already an unlimited number of ways to make life more complicated for insiders (legitimate or not).
> The [Dropbox] flaw, a software bug that rendered the service's authentication mechanism non-functional,
As a rule, if the authentication is broken, the encryption is too.
> [La Cie] stating that Dropbox's problems wouldn't be an issue if files were encrypted by the client
Only maybe if the user chose a strong password and there was literally no way for users to recover their data if they lost it.
I'm not against client-side encryption. I'm a fan of PGP and Truecrypt.
> JS crypto, in its broken state, offers some improvement for some real-world scenarios that SSL does not even attempt to address.
I can think of one or two such scenarios, but not many. Mr. Dotcom may well be the exception that proves the rule; his primary adversary is the US DOJ. It will be very interesting to see how this plays out.
Instead of make more comments for you to take out of context and condescendingly straw-man, I'm going to withdraw from this effort.
I am not being condescending I am being completely serious here: maybe I just don't understand your underlying point.
What are "these things that SSL does not do" that Javacript-over-SSL does do?
> and my disclaimers (JS crypto has huge, real problems, I'm not an advocate for it), and instead just replying so you can invite moxie and tptacek to circlejerk on twitter apparently: https://twitter.com/marshray/status/340239501446217728 Instead of make more comments for you to take out of context and condescendingly straw-man, I'm going to withdraw from this effort.
Oh give me a flippin break. Anybody who clicks that link can see that it a reply to someone.
Stand up for your point with rational arguments or admit your system is pwned by sslstrip.
1) This is just stupid because JS Encryption is only as strong as the weakest link in the whole website (SSL, Third-Party Scripts, etc.)
2) Actually completing the challenge, which I assume means hijacking Adam's session and retrieving and decrypting the reward instruction note.
It's okay for people to focus on point one, I suppose, because otherwise innocent people may get hurt if developers actually come away with the conclusions that JS Encryption is safe.
As for point two, I think it's okay to provide an intellectual proof of success in lieu of actually doing it, but what does that mean? Doesn't it hinge, in Moxie's case, on the condition Adam states, If you want to try injecting code, I'm happy to use a network you control if we can arrange the logistics though I won't promise to log in if you can't provide a valid SSL certificate :)?
Moxie would have to MITM notecrypt.appspot.com which I assume is allowed because of, I'm happy to use a network you control. However, what about the further condition, though I won't promise to log in if you can't provide a valid SSL certificate? This is unclear to me. A valid certificate to what? notecrypt.appspot.com? Moxie's tool is called sslstrip, not sslreplace, so I don't think it can provide a valid SSL Cert, in which case he would not succeed. Perhaps he would strip the SSL from the JS file only, but that might yield a mixed content warning.
What am I missing?
I'll totally back away if he tries to make this into a product.
Moxie suggested that I acquire a certificate for a similar domain to meet that requirement but that doesn't meet either the normal definition of valid (If a show requires a valid ticket to be shown at the entrance, will one from last night do?). He did claim that producing a forged certificate is possible and I have no reason to doubt him. However, he noted that he nor anyone else would produce one for a reward of this amount.
We were still corresponding when he made the tweet in question. I ultimately asked him if he believed that a certificate to another domain was a valid certificate and his reply didn't address that point but discussed instead why he and tptacek are frustrated by these kind of contests.
I'm sorry I seem to have offended you.
You did however launch a "contest" to demonstrate the soundness of using browser Javascript cryptography to protect user secrets, and made exactly the kind of slip-up that trivially demonstrates what a bad idea browser JS crypto is: to wit, your application couldn't even protect its own pages, let alone use them to safely deliver crypto code; you provided an ambiguous address and didn't properly lock the server down to SSL, so you couldn't even rely on users getting to your app under SSL.
Your app wouldn't have demonstrated any of the security value (largely nonexistent) of browser JS crypto even if it had been careful about SSL hygiene. But you spared Moxie the trouble of making that case.
Somehow I doubt Moxie cares too much about the $1000, but: you screwed up, lost the contest, and then (from what I can see) weaseled. The real point isn't "pay Moxie $1000"; it's, "don't try to run contests like this".
It says, plainly, he wouldn't click unless there was a valid SSL cert. Do you know what sslstrip does? I know you do, so stop playing dumb.
"I won't promise to log in if you can't provide a valid SSL certificate :)"
Apologize to absherwin and admit you were wrong, or it is you who is the weasel.
If that wasn't intentional and you hadn't considered it, it would be classy to delete that. Granted "absherwin" is not totally anonymous, your derogatory proclamation attached to the proper form of his name is a bit much. He's misguided, not malicious.
Again, stop playing dumb.
Type his Firstname Lastname into the search bar at the bottom - your "name and shame" post is the only result.
> Unlike you, Sherwin has never been anonymous.
News flash: Moxie Marlinspike isn't Moxie's real name either.
Nobody is playing dumb with you. I'm not afraid to be wrong in a debate with you; I just haven't had the opportunity to be, yet.
You chose to reassert that you believe your accusation is true without responding to the specific points raised and turn the focus of the discussion to the subsidiary point.
You introduced your name into the discussion, presumably because you're confident enough to sign your name to your opinions and arguments, which is admirable. It is thus not a valid argument to suggest that acknowledging your (public) name is a malicious act. But the obvious invalidity of the argument clearly didn't stop 'lawnchair_larry from making it!
If it helps you any, you can peruse the rest of my comments on HN. Whenever it's reasonable, I try not to use nicks and handles; I call 'patio11 "Patrick", I call Paul Graham "Graham" (I don't know him in person), &c.
Have you noticed how, despite you repeatedly insinuating that I'm knowingly making false statements about you, I'm not huffing and puffing about it? That's because the huffing and puffing is dreadfully boring and teaches us nothing about anything whatsoever. I think we can all agree this nitpicky little subthread isn't teaching anything either, so I'll concede it to you and 'lawnchair_larry, and respond to you elsewhere on the substantial points.
Is it worth dragging someone through the mud over? He said he didn't appreciate it, just edit it out. It's more important than "being right."
Did Moxie think that his description of what he would do was sufficient? Adam offered to enter whatever environment was offered.
Has Adam now refused to participate in that? Has he participated in that and Moxie broke it? If either of those has happened, I've seen nothing written about that on this HN page, on Moxie's blog, on Moxie's twitter feed, or on TFA. Maybe there is some big part of the discussion I'm not seeing.
Maybe it's not worth Moxie's time. That is perfectly fine. There's lot of things that I could do but don't because they're not worth my time, but I don't get to say I did them.
Moxie did provide a more detailed attack description. I had to correct an iptables command and modify sslstrip to alter the JS but otherwise his instructions were complete and correct. Per the original instructions, he should have had to configure the proxy but that's purely a function of who does that labor so I happily did the small amount of extra work.
Once I completed the attack, I learned as I suspected from reading about sslstrip, the SSL certificate was removed. I thanked Moxie for his efforts and praised his work but informed him that it didn't meet the initial requirements. He argued that it works in the wild and that I could acquire appspot.cc and a certificate for that. I replied that if he wanted to conduct a convincing enough demo that I would be fooled into clicking, I'd consider that sufficiently close to being valid. Alternatively, he could produce an SSL certificat e that the browser would accept as valid for that domain. I agreed that a user in the wild might not be as cautious but that in agreeing to route my traffic through a malicious proxy, I recognized I was giving an attacker a significant advantage and that's why I made a valid SSL certificate a requirement in the initial post.
He replied back that any LAN can be malicious so he disagrees with my assessment and that he didn't trust I wouldn't throw up more unreasonable objections and that I should pay.
I replied outlining exactly how I would evaluate any alterations to the MITM he's proposing. It was at this time he posted to twitter. I heard about that and emailed him and he denied he was accusing of of dishonesty but only noting that I had declined to pay the reward tptacek thought he was owed. I remained concerned that it wouldn't be taken that way and unfortunately tptacek has proven my fears correct.
In any event, I asked him if he believed his approach genuinely met the valid certificate requirement at this point because I wanted to assess whether he was he felt my rules were unfair or that I wasn't abiding by them. He declined to reply to that question.
But, since I didn't take the contest seriously, I didn't take the time to verify that you'd actually set up your server properly. Moxie, on the other hand, did. If I put $1000 on the line, I might have taken the time to ensure that the SSL connectivity I had set up for my server actually worked. You didn't; you left a vulnerability on your server that any security audit of any SSL-only service would have flagged as "MUST FIX". Moxie not only flagged the vulnerability but explained it to you and provided exact steps to reproduce it for you.
Here is is worth noting that $1000 probably does not buy enough of Moxie Marlinspike's time to compose the emails he seems to have sent you.
Instead of conceding the point --- that, in setting up a contest that obviously depended on your SSL/TLS connectivity actually working, you had made a material error that made the contest easy to win --- you raised an arbitrary objection: the judge of the contest was permitted to take arbitrary steps to verify in exacting detail which SSL certificate was presented, at least on the first connection if not on subsequent connections (as you note, Moxie didn't get that far with you). The same objection would have worked if you'd used a self-signed certificate; Moxie would have said, "any MITM could interpose a new certificate" and you'd have said "oh, but I would check the fingerprint of the certificate against the certificate pinning list I maintain in my head". Here, for obvious reasons, Moxie gave up.
Nobody cares about your money. The problem is that in "staking" $1000 on this contest, you've created a perception, exclusively among people who don't know much about cryptography, I'd add, that SJCL stapled to a web form is a viable mechanism for building a secure system (or at least, something more secure than just HTTPS). This perception is wrong, and it's aggravating that the $1000 gimmick reinforces it among precisely the people who most need to be made aware of how wrong it is.
I don't think you're a dishonest person, in the sense of, "I would avoid doing business with you". I don't know you at all, and certainly not well enough to judge your character. I do think you've fallen victim to message- board- lawyering, something (uh) many of us have problems with, and are reluctant to concede any point that harms your argument. That, sorry to say, is weaselly behavior. If it helps you any to hear it, I'm sure someone could find someplace on HN where I too have been weaselly in debates.
It is demonstrably more secure than just HTTPS. Even if only slightly. Because HTTPS doesn't even try to do those things.
Regarding Moxie, I noted in the original post and immediately after his first post that he'd need to provide a valid SSL certificate. He asserted one wasn't necessary and I assumed perhaps he had some other trick to make it appear as though he had one so I invited him to email me details. His attack didn't do that and it turned out he had interpreted the requirement for a valid SSL certificate to mean that he couldn't present one the browser would flag as invalid. I'm sorry if you or he feel that I wasted his time.
The SSL connectivity for the server did work. The only way to defend against the attack Moxie posted would be to modify my browser. The exploit Moxie used depends on the fact that if one doesn't type https:// the browser will request http. You could argue my error was abbreviating in the posting but that wouldn't change how users type it. The best defense against this is HSTS which comes in two flavors: The standard version is applied after first visting the site. Would you have said that invalidated the attack? The attack would work just as well on a browser with cleared cache or running in incognito mode.
The only real defense which, to my knowledge, only exists in Chrome is the HSTS preload. I suppose I could have noted that I'd modify my browser to have it on the HSTS but that doesn't effect real world security either.
That said, I am extremely curious how you would defend against SSL stripping in the wild. This seems like a potentially devastating attack. None of the banks that I checked are on the preload and many don't seem to use HSTS at all. What defenses would you have considered sufficient so as not to consider this trivially exploitable by an SSL redirect vulnerability that effects almost the entire web?
Your argument above effectively reduces to: The web is insecure so you always lose and putting in a disclaimer to ban such attacks is weaselly. The SSL vulnerability is a huge problem but that doesn't mean understanding the security of the rest of the system is worthless.
I never said I'd check the fingerprint of the certificate against my memory. Moxie used that retort against me after his attack produced a session that was obviously not over https. I explicitly denied that that was one of my criteria. That said, at least in chrome, appspot.com is pinned.
The irony is that this does show that SJCL provides a modest security increase over plaintext in the case of broken SSL. It requires a per-site attack to be constructed ahead of time vs. simply reviewing the plaintext for all sites after the fact and picking what's valuable.
Your key argument seems to be that naive developers might use JS crypto because of this. If they use it naively, I'm sorry for that. I'm also sorry if they exclude it naively because of other rhetoric. I hoped that this would generate more nuanced discussion that would cause them to be more aware of the risks if they chose to use it. Obviously that wasn't the case and nothing was learned about the various angles from this app could be exploited aside from the trivial one.
I truly appreciate your laying out your reasons above. I understand I struck a negative chord but am glad that we've been able to move into discussing the specific technical issues.
I failed at my second goal and while I've succeeded in the third it was in different way than anticipated.
I also to reiterate that this isn't some backhanded attempt at a product launch. I would have hoped that my statements, using an appspot domain, no design and limited functionality would have made that clear.
If I understand your attack, you'd need to set up a clone website that resends the password in the clear, have a malicious network redirect me to it and get me to enter my password. I'm happy to enable to you to demonstrate that it works. The hardest part is presenting a valid SSL certificate. As I warned in the initial post, "I won't promise to log in if you can't provide a valid SSL certificate."
Email me and we can arrange the details.
If I'm in a position to observe a notecrypt users's communication (the reason encryption is necessary), I can just run sslstrip (no SSL certificate required).
It will transparently intercept all of the notecrypt users's plaintext communication to notecrypt without generating any browser warnings.
At that point I also have the opportunity to modify any of the plaintext traffic as it passes by.
The user will be communicating with your actual website (no need to setup a clone), but I can just modify the JS as it is transmitted to the user so that it doesn't actually encrypt anything.
This attack just requires running a single command, no complex setup required. You might want to read more about sslstrip to understand how this works.
BTW, have been following your work on TACK with great interest.
The "green" indicator is nice but definitely should not be relied upon to protect the user.
note: i used appsp0t as an example, no idea if its really available to be bought.
Edit: it's not letting me reply to the below comment (probably because this is a new account), but afair most browsers have fixed the IDN problem by checking for "suspicious" characters (characters that look similar to roman glyphs) and forcing the URL to be rendered in the full punycode URL.
Not sure how valid that still is (as the talk is a couple of years old? I only watched it today), but it has to be assumed that a portion of users are going to fall for even a badly mimicked url.
Gotta say the IDN stuff is impressive in how generalised it could be. Terrifying. I'm convinced he's owed the $1,000.
But the parent comment is still valid, there's nothing to stop Moxie registering another domain even note-crypt.com or notecrypt.org or anything like that and the average user will be complacent with that. (same applies for appspot, note-crypt.appspot.com vs notecrypt.appspot.com vs notecrypto.appspot.com)
It only takes a single lapse in checking the domain and they've lost their login details and encryption key to the attacker.
Point is, the JS crypto does not add anything to the situation. All the security is provided by SSL, and once it goes, the JS doesn't help. It just gives the users a fake sense of an additional layer of security, which is dangerous.
Moxie broke the current SSL usage, and therefore, he broke the JS crypto (as he controls the communication channel). He beat the current state of the challenge.
My understanding is that the HTST header would make this attack less useful. But it's still a concern if you used Private Browsing/Incognito. The initial request will still hit a 301 (vulnerable to interception by MITM). I've just verified this with Facebook.com on my machine (Chrome 26, OSX).
I think it's quite fair to expect a user using this kind of site is likely to use Incognito.
I'm actually kind of surprised as I thought Chrome had a standard list of sites that use https only such as Facebook. (Woah.. seems the preload list is TINY http://www.chromium.org/sts )
I like the kind of pinning and preloading that chrome does but it's such a tiny gesture compared to the size of the internet, and nobody else seems to be trying to deploy better security.
Perhaps there could be open whitelists where sites could nominate their sites as 'https only'. Wouldn't even need to be built into the browsers, could just be a thing people do when they launch a clean browser install, hit up https://blahsitelist.com and click a button that fires off https requests to all of those sites which would cache the HTST header? (I've only stumbled on HTST headers today, so I may be overly flamboyant as to their usefulness)
Although, come to think of it, isn't that just basically what the HttpsEverywhere extension does?
So my read is that for this particular challenge there's only one "user", the OP. I read it as he's willing to facilitate the attack by using the site from a hostile network but has specifically said he'll check for a valid SSL session.
So by that interpretation, despite how much I think Moxie deserves another $1k for doing great work in general, it seems an SSL strip attack is unlikely to satisfy the offered terms.
Of course I expect an SSL strip attack would be effective against end users generally.
Ironically, this is an advantage of having a second layer of cryptography in the browser. It forces an attacker to do significantly more work to acquire the data passively or requires an active attack.
Even worse is that the attacker only really needs to spoof the JS assets once, and set an extremely long expiration date in the response cache headers, and then he's poisoned your site until the user forces a reload or kills his cache.
tldr; you owe mox $1000
It is easy enough for you to demonstrate it to yourself with the components that he describes.
The client never sees any SSL.
Edit: Found an article, by cperciva no less: http://www.daemonology.net/blog/2011-09-01-Iran-forged-the-w...
"...I wanted to see how easy it was to fail in practice so I built a simple app: notecrypt.appspot.com"
If you copy and paste that into your browser, your browser will make an HTTP request. Your webapp will send back a 302 redirect with an HTTPS link, but if I'm an attacker running sslstrip (http://www.thoughtcrime.org/software/sslstrip), that won't work.
What's more, you don't set HSTS headers:
$ curl -i https://notecrypt.appspot.com/ HTTP/1.1 200 OK ETag: "ibqapA" Date: Wed, 29 May 2013 18:59:37 GMT Expires: Wed, 29 May 2013 19:09:37 GMT Cache-Control: public, max-age=600 Content-Type: text/html Server: Google Frontend Transfer-Encoding: chunked
...so anyone that types "notecrypt.appspot.com" into their browser in the future will continually expose themselves to the same vulnerability.
At that point I can just modify the JS that gets transmitted back to the browser such that it doesn't actually do any encryption.
As always webapp-based JS cryptography is reducible to the strength of SSL. If I can break SSL, I can break your JS crypto, so there's really no point in doing the JS-based crypto.
How do I collect the $1000?