[j0ev]

That's a bad assumption. I could feasibly purchase the appsp0t.com domain, grab an ssl cert for nodecrypt.appsp0t.com, hop onto the LAN and run sslstrip, redirect the user to https://nodecrypt.appsp0t.com and wall-a, green address bar with a close looking address. That would probably fool me.

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.

[ryalfalpha]

I think it's also worth pointing out in Moxie's sslstrip talk he does go into detail on using IDN http://en.wikipedia.org/wiki/Internationalized_domain_name to spoof something similar (for non-english TLDs).

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.

[Dylan16807]

And what is the method of bypassing the similar-glyph detection and the very strict language whitelists for different TLDs?

[ryalfalpha]

I said 'Not sure how valid that still is' for a reason :). I just found it extremely interesting and 'out of the box'. After reading up a bit on modern defences, I think you're right that it's irrelevant nowadays. (Unless you're in legacy hell, doubtful for the target user demographic)

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.

[Dylan16807]

To me it seems far too pedantic to give an award for pointing out, based on a forum post that blocks links (ask HN posts), that if you incorrectly use the partial url you are at risk.

[ryalfalpha]

That's a valid point, but I can't see it being an impossibility that the user will never accidentally stumble sending a http request rather than https. Whether that is user input, or a maliciously placed link.

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 )

[Dylan16807]

Some day maybe we'll see browser-enforced secure DNS that has the ability to include certificates or set HTST. Maybe the same day ipv6 finally takes over in a few centuries.

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.