Hacker News Reader

Comment by danielweber | Hacker News Reader

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.

View on HN

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.

> (or at least, something more secure than just HTTPS).

It is demonstrably more secure than just HTTPS. Even if only slightly. Because HTTPS doesn't even try to do those things.

I appreciate your responding thoughtfully.

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.

Reply on news.ycombinator.com