It seems like there are two strains of thought in this little drama:
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.
He's not paying. He contacted Moxie Marlinspike privately, and then Moxie posted on Twitter saying he wasn't paying. So he's not only wrong, but also a weasel. A WEASEL. I said it!
I haven't paid anyone yet because no attack has yet met the conditions. As others have noted, a valid SSL certificate is required for this to work.
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.
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".
That aside, is there a reason you're naming and shaming? It seems a little malicious. You know that your announcement is going to come up under search results for his real name.
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.
Moxie Marlinspike is not hiding behind an alias, and neither is Sherwin. I didn't sleuth his name from anywhere; it was public at least since last night, on Twitter. Presumably, the guy who starts a contest under an HN nick with his name in it and then emails numerous people from an address with his name in it is not trying to hide his identity.
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.
Yes, my name is public. I don't really care about you mentioning it. What I care about is my name being mentioned in a way that implies my dishonesty which is all lawnchair_larry originally argued. His argument had two components: You're making a false accusation and it's more harmful because you're using my real name.
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.
I am not making a false accusation. I understand that you believe I have, but we both know I don't agree with that. You and I also both know why I haven't delved into whatever specific points you think need delving-into.
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.
Look, the fact is you're directly attaching Firstname Lastname to a derogatory claim, signed by a respected expert, to the permanent record of the searchable internet over something rather petty.
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."
There is an extreme lack of detail here for me to come to that conclusion about another human being.
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.
I truly appreciate your attitude. As you can imagine, having my integrity questioned is quite hurtful. So before I address, your point, thank you. Your comment means a lot to me.
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.
If it helps you understand the objection I have to this whole exercise: I think the whole contest was weaselly. You designed a challenge that stipulated away the simplest and most reasonable attacks on the system, and created an objective for the contest that would have been equally annoying to achieve had you used repeated-key XOR as your cipher instead of AES, and suggested in your promotion for the contest that its intent was to demonstrate something about cryptography. I think the commenter who parodied the exercise with a contest about a post-it on his computer hit the nail on the head.
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.
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.
Since it's too late to edit, I'm posting here to correct my statement that Chrome is the only browser that supports HSTS preload; Firefox does as well.
Boy you need to calm down tptacek. Personal attacks on the OP based on a highly disputable claim (it's just a description of a possible attack that doesn't fulfill the original conditions in the first place) is a bit unseemly and makes you sound desperate to an extent.
Thanks. This is an attempt at doing three things:
1. Learning more about the security risks of JavaScript
2. Facilitating a more create and nuanced discussion of its pros and cons
3. Learning about interacting with HN
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.
