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...
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.