7 ms·

No need to setup a clone website or to obtain a valid SSL certificate. If I'm in a position to observe a notecrypt users's communication (the reason encryption

by moxie 13y ago

No need to setup a clone website or to obtain a valid SSL certificate. 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.

rarrrrrr 13y ago
FWIW, my reading of the OP is that it's stipulated that the user will check for the presence of a valid SSL session (i.e. with in browser visual indicators) before login. BTW, have been following your work on TACK with great interest.
- j0ev 13y ago
  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 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 13y ago
    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 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 13y ago
      And what is the method of bypassing the similar-glyph detection and the very strict language whitelists for different TLDs?
      - ryalfalpha 13y ago
        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 13y ago
        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.
- wglb 13y ago
  I am not seeing it's stipulated that the user will check for the presence of a valid SSL session. Can you clarify?
  - rarrrrrr 13y ago
    I'm offering my interpretation of the OP's original words defining the terms of the challenge "I won't promise to log in if you can't provide a valid SSL certificate :)". 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.
absherwin 13y ago
Intercepting the plaintext of the communications to the server isn't sufficient since the password is sent to the server after being hashed and the plaintext is encrypted. It may provide the basis for an attack but in itself it doesn't break the second layer of security. 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.
- j0ev 13y ago
  Using his same attack, it's easy to spoof the js crypto libs to be insecure/have a backdoor, while the site appears unmodified to the user. 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

by moxie 13y ago

rarrrrrr 13y ago

FWIW, my reading of the OP is that it's stipulated that the user will check for the presence of a valid SSL session (i.e. with in browser visual indicators) before login. BTW, have been following your work on TACK with great interest.

j0ev 13y ago
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 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 13y ago
  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 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 13y ago
    And what is the method of bypassing the similar-glyph detection and the very strict language whitelists for different TLDs?
    - ryalfalpha 13y ago
      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 13y ago
        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.
wglb 13y ago
I am not seeing it's stipulated that the user will check for the presence of a valid SSL session. Can you clarify?
- rarrrrrr 13y ago
  I'm offering my interpretation of the OP's original words defining the terms of the challenge "I won't promise to log in if you can't provide a valid SSL certificate :)". 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.

absherwin 13y ago

Intercepting the plaintext of the communications to the server isn't sufficient since the password is sent to the server after being hashed and the plaintext is encrypted. It may provide the basis for an attack but in itself it doesn't break the second layer of security. 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.

j0ev 13y ago
Using his same attack, it's easy to spoof the js crypto libs to be insecure/have a backdoor, while the site appears unmodified to the user. 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