Re: Long Term IDN/punycode spoofing strategy concept
Ian G wrote: > Your original comment was that they are not reversable. Not reversible assuming you don't have the original inputs. I would have thought that was a fairly obvious corollary. Just like "this safe is really hard for a thief to open" implies "...as long as they don't have a key". Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
Gervase Markham wrote: Ian G wrote: Yup. Go through their logs, pull out all the URLs that are cached there, and run them through the hash. Er... if the URLs are available in plain text in their "logs" (I presume you mean history), then there's no need for them to reverse the hash. They can just look at where they've been. Or have I missed something? Your original comment was that they are not reversable. That's a tricky assumption. Above I gave a way in which they can be "reversed" but perhaps it wasn't in the way you expected. Now, you might thing that's quibbling, but in security work we cannot afford to take text book security statements and just apply them as if they always hold true. Subtle things matter, and the attacker has the ability to change the rules. (I'd have to go back to the original design that you were discussing to see whether the reversing I described results in a weakness.) iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
Gervase Markham wrote: HJ wrote: The implementation will be publicly accesible by anyone, so you don't have a perfect world, so I can reverse it, because I know how it works! So you really don't understand one-way hash algorithms, then. :-) This is a good introduction: http://www.unixwiz.net/techtips/iguide-crypto-hashes.html The key is that they are _not_reversible_. Yeah, but then again, you don't know who you are messing with! No, I haven't. Why do you ask? Ok, another question: "So what do you think is more important, this preference or this SSL history?" "Which is more important, the colour blue or a magpie?" I don't understand the question. Gerv It is very clear to me that you don't understand what you are talking about, but again, you and most of the Mozilla clan will soon find out the hard way. /HJ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
HJ wrote: The implementation will be publicly accesible by anyone, so you don't have a perfect world, so I can reverse it, because I know how it works! So you really don't understand one-way hash algorithms, then. :-) This is a good introduction: http://www.unixwiz.net/techtips/iguide-crypto-hashes.html The key is that they are _not_reversible_. No, I haven't. Why do you ask? Ok, another question: "So what do you think is more important, this preference or this SSL history?" "Which is more important, the colour blue or a magpie?" I don't understand the question. Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
Ian G wrote: Yup. Go through their logs, pull out all the URLs that are cached there, and run them through the hash. Er... if the URLs are available in plain text in their "logs" (I presume you mean history), then there's no need for them to reverse the hash. They can just look at where they've been. Or have I missed something? Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
Gervase Markham wrote: HJ wrote: You can hash a particular domain and say "has the user visited https://www.foo.com?"; (which is the question the browser needs to know to do the "new site" indicator). But you can't say "give me a list of all the domains they visited." In a perfect world maybe, but do we live in a perfect world, no. I'm not sure what that's supposed to mean. I'm talking about the effects of a fundamental property of one-way hash algorithms. If you have some magic way of reversing (say) MD5 or SHA1, let us know :-) The implementation will be publicly accesible by anyone, so you don't have a perfect world, so I can reverse it, because I know how it works! p.s. I've asked you this question before, but you simply ignored it, so that's why I ask it again: "Gerv, have you set 'wallet.crypto' to 'true' or not?" Yeah, one day you will find out why, as I did two years ago :-) No, I haven't. Why do you ask? Ok, another question: "So what do you think is more important, this preference or this SSL history?" /HJ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
Gervase Markham wrote: HJ wrote: You can hash a particular domain and say "has the user visited https://www.foo.com?"; (which is the question the browser needs to know to do the "new site" indicator). But you can't say "give me a list of all the domains they visited." In a perfect world maybe, but do we live in a perfect world, no. I'm not sure what that's supposed to mean. I'm talking about the effects of a fundamental property of one-way hash algorithms. If you have some magic way of reversing (say) MD5 or SHA1, let us know :-) Yup. Go through their logs, pull out all the URLs that are cached there, and run them through the hash. Any that match a hash makes for a hit. Relying on the non-reversibility of the hash for security reasons does mean keeping accesss to the original as a secret as well. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
HJ wrote: You can hash a particular domain and say "has the user visited https://www.foo.com?"; (which is the question the browser needs to know to do the "new site" indicator). But you can't say "give me a list of all the domains they visited." In a perfect world maybe, but do we live in a perfect world, no. I'm not sure what that's supposed to mean. I'm talking about the effects of a fundamental property of one-way hash algorithms. If you have some magic way of reversing (say) MD5 or SHA1, let us know :-) p.s. I've asked you this question before, but you simply ignored it, so that's why I ask it again: "Gerv, have you set 'wallet.crypto' to 'true' or not?" Yeah, one day you will find out why, as I did two years ago :-) No, I haven't. Why do you ask? Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
Gervase Markham wrote: HJ wrote: So people are forced to trust other people, without having the option to clear it manually. If you are using a computer you don't control totally, you are trusting other people. Ok, but with my implementation you, the user, will at least have some control and IMHO having some control is better/saver. Man, I'm sure that this will make people mad, just wait and see, because it is still a privacy issues, especially when someone writes an extension to display all of your hash keys :-) I don't think you quite understand how the hash keys work. You may 'think' that I don't understand the concept of hash keys, but I know how it works. You also seem to forget that it was me that wrote the lines to made it work for MultiZilla :-) You can't reverse them to get the domain names back out again. You can hash a particular domain and say "has the user visited https://www.foo.com?"; (which is the question the browser needs to know to do the "new site" indicator). But you can't say "give me a list of all the domains they visited." In a perfect world maybe, but do we live in a perfect world, no. Note that the hash would include a user-specific component, so online dictionaries of hash values wouldn't be any use. Now we're talking, because that's a key factor, but I can only hope that it will be better implemented, unlike the wallet code, because that sucks rocks! p.s. I've asked you this question before, but you simply ignored it, so that's why I ask it again: "Gerv, have you set 'wallet.crypto' to 'true' or not?" Yeah, one day you will find out why, as I did two years ago :-) /HJ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
HJ wrote: My question was if you are forcing people to look at punycode all the time, like now, but you already answered my question. What TLD's are concidered to be save at the moment (the same onces as Opera checks in Beta 8)? At the moment, none. Firefox 1.0.1 was released very soon after the story broke, and we only had time to make a simple change. So, we changed it to punycode for everyone. Cool, so Mozilla Firefox won't re-enable the statusbar automatically? Nope, I don't think so. We might one day do this for popups, perhaps. Interesting idea. So people are forced to trust other people, without having the option to clear it manually. If you are using a computer you don't control totally, you are trusting other people. Man, I'm sure that this will make people mad, just wait and see, because it is still a privacy issues, especially when someone writes an extension to display all of your hash keys :-) I don't think you quite understand how the hash keys work. The hash keys would be things like: ab4b23d7254fa03ffce57e949fefa935 bdb6b31090e340968767e2f3b3cc6c9c 49623feff08b060d00b9b594b47ff508 You can't reverse them to get the domain names back out again. You can hash a particular domain and say "has the user visited https://www.foo.com?"; (which is the question the browser needs to know to do the "new site" indicator). But you can't say "give me a list of all the domains they visited." Note that the hash would include a user-specific component, so online dictionaries of hash values wouldn't be any use. Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
Gervase Markham wrote: HJ wrote: So you are forcing all people to look at punycode all the time, even if that makes it worse? What if I have a punycode look alike domain? Yeah, that will make it harder I guess. Nope, we're never going to display the punycode and Unicode at the same time. It'll always be one or the other, depending on whether we trust the TLD not to issue homographic domains to different people. My question was if you are forcing people to look at punycode all the time, like now, but you already answered my question. What TLD's are concidered to be save at the moment (the same onces as Opera checks in Beta 8)? How is this prevented by a Master Password? After you've typed the password in, the extension writer can then steal your data. Bad extensions may be an issue, but they are unrelated to this one. Yeah, just like I can real all of your password, with or without you knowing it, so that is crap in my eyes already! What if I hide my status bar? Are you (Mozilla Firefox) re-enabling "MY" statusbar, just to be able to display that silly lock and text again? That's your choice to do so. Cool, so Mozilla Firefox won't re-enable the statusbar automatically? > This is a problem for the Internet Cafe to deal with in their software configuration. E.g. EasyInternetCafe completely wipes the computer and restarts between customers; this action would (obviously) clear the SSL history. But there won't be a button or UI to do it. So people are forced to trust other people, without having the option to clear it manually. Man, I'm sure that this will make people mad, just wait and see, because it is still a privacy issues, especially when someone writes an extension to display all of your hash keys :-) /HJ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
Gervase Markham wrote: HJ wrote: Lets take this example, Gerv wrote in his paper that SSL History should be user accessible, That's not what I wrote. In fact, the reason it's a hash is so that no-one can look at it and see a list of sites visited. Gerv, you seem to have missed this one: news://news.mozilla.org:119/[EMAIL PROTECTED] >> Another problem is that Gerv paper only covers SSL protected sites, but most recent phishing attacks (example: http://www.rceasy.com/paypal/ ) do not even use SSL protection, so I might still be fooled, without being notified. Of course you are being notified - the "www.paypal.com" and lock you normally see on PayPal are totally absent! That's a massive UI difference. Well, that's not what I call a 'notification' (no protection) and in that case you don't need any notification at all. /HJ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
HJ wrote: Lets take this example, Gerv wrote in his paper that SSL History should be user accessible, That's not what I wrote. In fact, the reason it's a hash is so that no-one can look at it and see a list of sites visited. but I don't agree because what if I go to a public Internet cafe or use Internet from some public computer in my hotel? Someone might add the wrong validation keys, and I'll end up visiting a phony site, without being notified about my error! See my previous post on this. But, if you are suggesting this might happen, the previous malicious person may also install a malicious extension, or add dodgy certs to the root store, or anything. You can't trust a computer you don't have control of. Another problem is that Gerv paper only covers SSL protected sites, but most recent phishing attacks (example: http://www.rceasy.com/paypal/ ) do not even use SSL protection, so I might still be fooled, without being notified. Of course you are being notified - the "www.paypal.com" and lock you normally see on PayPal are totally absent! That's a massive UI difference. Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
HJ wrote: So you are forcing all people to look at punycode all the time, even if that makes it worse? What if I have a punycode look alike domain? Yeah, that will make it harder I guess. Nope, we're never going to display the punycode and Unicode at the same time. It'll always be one or the other, depending on whether we trust the TLD not to issue homographic domains to different people. Now, you might wonder, do we really need this, yes we do, because my bank site (for example) makes use of a chromeless window, without navigation- and status bar, so I need to have a way of displaying the certificate info, or I would be lost and it would still very easy to deceive our users without this kind of information. No, it doesn't make use of a window without the status bar, because the status bar is always-on in Firefox 1.0 and onwards. - I don't think it's necessary to involve the whole "Master Password" thing. Most users don't use them anyway. The question is, should we explain them why they need one, or do we wait till some ill extension writer steals your sensitive data? How is this prevented by a Master Password? After you've typed the password in, the extension writer can then steal your data. Bad extensions may be an issue, but they are unrelated to this one. Did you consider adopting the UI suggestions in my paper? I've said this before, and I keep repeating myself over and over again; go to a local school and ask young children what it is and you will find out that the 'silly character' suggestion doesn't stand long. Not that one (I've rather gone off that idea); the ones in the "New Site" section I referred you to. Also, using "new site" is a bit blurry to me Is it a new domain name, are you visiting the site for the first time, didn't you store a key for it, did you clear your SSL History The SSL history would not be clearable, and would always store the hash. So the meaning of the indicator is clear. or are you using a different profile/computer system? The indicator, fairly obviously, means that it's a new site for you on this computer. 99.99% of users don't use multiple profiles, and those who do tend to be technically competent, so I'm not worried about that case. What about theme and extension authors, they can undo/change/hide this, so that won't work either. Again, malicious extensions and themes are outside the scope of the discussion. What if I hide my status bar? Are you (Mozilla Firefox) re-enabling "MY" statusbar, just to be able to display that silly lock and text again? That's your choice to do so. Think about this; John Doe visits https://www.majorbank.com in an Internet cafe, and you're next, right, you shouldn't visit your bank site in a public Internet Cafe, but that's what happens every day, more than you can imagine. Ok, so now Jane Doe visits this Internet cafe, hopefully the owner is not a bad person, because they can already 'steal' lots of handy/important data for criminal use, anyway, she visits the same phishing site, without knowing it because she thinks that this is the right site, after all, there's no warning, right? So what happens to her money/bank account? This is a problem for the Internet Cafe to deal with in their software configuration. E.g. EasyInternetCafe completely wipes the computer and restarts between customers; this action would (obviously) clear the SSL history. But there won't be a button or UI to do it. Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
HJ wrote: Lets take this example, Gerv wrote in his paper that SSL History should be user accessible, That's not what I wrote. In fact, the reason it's a hash is so that no-one can look at it and see a list of sites visited. but I don't agree because what if I go to a public Internet cafe or use Internet from some public computer in my hotel? Someone might add the wrong validation keys, and I'll end up visiting a phony site, without being notified about my error! See my previous post on this. But, if you are suggesting this might happen, the previous malicious person may also install a malicious extension, or add dodgy certs to the root store, or anything. You can't trust a computer you don't have control of. Another problem is that Gerv paper only covers SSL protected sites, but most recent phishing attacks (example: http://www.rceasy.com/paypal/ ) do not even use SSL protection, so I might still be fooled, without being notified. Of course you are being notified - the "www.paypal.com" and lock you normally see on PayPal are totally absent! That's a massive UI difference. Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
HJ wrote: So you are forcing all people to look at punycode all the time, even if that makes it worse? What if I have a punycode look alike domain? Yeah, that will make it harder I guess. Nope, we're never going to display the punycode and Unicode at the same time. It'll always be one or the other, depending on whether we trust the TLD not to issue homographic domains to different people. Now, you might wonder, do we really need this, yes we do, because my bank site (for example) makes use of a chromeless window, without navigation- and status bar, so I need to have a way of displaying the certificate info, or I would be lost and it would still very easy to deceive our users without this kind of information. No, it doesn't make use of a window without the status bar, because the status bar is always-on in Firefox 1.0 and onwards. - I don't think it's necessary to involve the whole "Master Password" thing. Most users don't use them anyway. The question is, should we explain them why they need one, or do we wait till some ill extension writer steals your sensitive data? How is this prevented by a Master Password? After you've typed the password in, the extension writer can then steal your data. Bad extensions may be an issue, but they are unrelated to this one. Did you consider adopting the UI suggestions in my paper? I've said this before, and I keep repeating myself over and over again; go to a local school and ask young children what it is and you will find out that the 'silly character' suggestion doesn't stand long. Not that one (I've rather gone off that idea); the ones in the "New Site" section I referred you to. Also, using "new site" is a bit blurry to me Is it a new domain name, are you visiting the site for the first time, didn't you store a key for it, did you clear your SSL History The SSL history would not be clearable, and would always store the hash. So the meaning of the indicator is clear. or are you using a different profile/computer system? The indicator, fairly obviously, means that it's a new site for you on this computer. 99.99% of users don't use multiple profiles, and those who do tend to be technically competent, so I'm not worried about that case. What about theme and extension authors, they can undo/change/hide this, so that won't work either. Again, malicious extensions and themes are outside the scope of the discussion. What if I hide my status bar? Are you (Mozilla Firefox) re-enabling "MY" statusbar, just to be able to display that silly lock and text again? That's your choice to do so. Think about this; John Doe visits https://www.majorbank.com in an Internet cafe, and you're next, right, you shouldn't visit your bank site in a public Internet Cafe, but that's what happens every day, more than you can imagine. Ok, so now Jane Doe visits this Internet cafe, hopefully the owner is not a bad person, because they can already 'steal' lots of handy/important data for criminal use, anyway, she visits the same phishing site, without knowing it because she thinks that this is the right site, after all, there's no warning, right? So what happens to her money/bank account? This is a problem for the Internet Cafe to deal with in their software configuration. E.g. EasyInternetCafe completely wipes the computer and restarts between customers; this action would (obviously) clear the SSL history. But there won't be a button or UI to do it. Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
HJ wrote: First of all, i've just updated my screenshot: http://multizilla.mozdev.org/screenshots/features/spoofing/new-ssl-site-bimsheet-v2.jpg I doubt most users will ever "open this expander" :( > Nelson B wrote: While you're at it, you should display all the "subject alternative names" in the cert, in addition to the "Common Name". I came to the same conclusion, at least I hope you are revering at this kind of info: CN = www.paypal.com OU = Terms of use at www.verisign.com/rpa (c)00 OU = Information Systems O = Paypal, Inc. L = Palo Alto ST = California C = US All that info is part of the cert's "subject name". The data shown above follows the old legacy convention of putting the host's domain name into the subject name's "common name" (CN) field. Modern certs don't do that any more. They put the host names (there can be more than one) into the cert's list of "subject alternative names", something that is not part of the info shown above. Today, mozilla doesn't show the "subject alternative names" info at all. :( I propose that you change your UI to show that info. If you do that, you will have fixed bug https://bugzilla.mozilla.org/show_bug.cgi?id=230655 which is now over a year old. /Nelson ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
Duane wrote: HJ wrote: Another problem is that Gerv paper only covers SSL protected sites, but most recent phishing attacks (example: http://www.rceasy.com/paypal/ ) do not even use SSL protection, so I might still be fooled, without being notified. Out of all the spam emails that seem to by pass my filtering rules, I'm yet to see any actually using SSL, most try to hide the real URL with html, but for the most part a quick most over shows the real non-SSL URL... I saw one about a year ago. I followed it all the way through, trying to figure out how they'd "stolen" the cert. It took me about 10 mins to work it out, and it was a real "doh!" moment. Basically, they'd just got a cert issued in some random name like "secure-payments.com" and used that. You won't ever see much SSL activity on phishing until the browser forces the user to start looking for SSL. That's the beef with the little padlock... iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
HJ wrote: > Another problem is that Gerv paper only covers SSL protected sites, but > most recent phishing attacks (example: http://www.rceasy.com/paypal/ ) > do not even use SSL protection, so I might still be fooled, without > being notified. Out of all the spam emails that seem to by pass my filtering rules, I'm yet to see any actually using SSL, most try to hide the real URL with html, but for the most part a quick most over shows the real non-SSL URL... -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://happysnapper.com.au - Sell your photos over the net! http://e164.org - Using Enum.164 to interconnect asterisk servers "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
HJ wrote: Nelson B wrote: HJ wrote: Having troubles reading the text, try this one: http://multizilla.mozdev.org/screenshots/features/spoofing/new-ssl-site-bimsheet.jpg First of all, i've just updated my screenshot: http://multizilla.mozdev.org/screenshots/features/spoofing/new-ssl-site-bimsheet-v2.jpg Excellent. HJ, I would say your english is too good and too formal and too techie :-) There are simply too many long words there. Having said that, I'm not the right person to construct fewer words; I'm never ever been caught being concise when I have a chance of being comprehensive ;) Finding the right set of words is the prize. I suggest you talk to lots of people, who aren't techies, and don't understand. Use the experience to distill out the real essence of the message. Something like: "MultiZilla sees a new secure website! Are you sure this is the one you wanted? If it is, click [YES] and MultiZilla will remember that in future. If not, this may be a phishing site for one of your special trusted sites? Check the certificate details... If unsure, click [UNSURE] and MultiZilla will put a big red question mark on the site in the future. If this site is bad, click [BAD]... " Hmmm too many words... The "Common Name" is no longer considered the "right" place to contain the server's domain name. The right place is in the certificate's list of "subject alternative names", and that list may contain multiple domain names and/or IP addresses. It's good to continue to display the common name, as many legacy certificates still use that. But more and more we see modern certs that don't have the domain name in the "common name", and hence the server's domain name doesn't appear in that dialog. If the dialog was fixed to display subject alternate names, that would help a lot. It's a shame that this wasn't fixed in mozilla years ago. But PSM is an orphan. You're doing more to help PSM than has been done in a long time, and I (for one) appreciate it. I just wish your work was going into the main mozilla PSM source, rather than into an offshoot. Well, at least we're discussing a possible solution, and who knows what happens at the end. It sure won't hurt ;) Lets take this example, Gerv wrote in his paper that SSL History should be user accessible, but I don't agree because what if I go to a public Internet cafe or use Internet from some public computer in my hotel? That's a special case. If the place is untrusted, then it matters not what you do, as an attack involves perverting everything. It's better to fix what we can fix for the average stable user - Alice at home on her Windows PC. Later on, improve that and also tune for the exceptions like public computers. Someone might add the wrong validation keys, and I'll end up visiting a phony site, without being notified about my error! In practice, a proper company like Kinkos or whichever re-installs the whole thing every user. At least, that's the ideal, and I gather they do that because the FBI was grumbling that they couldn't get the data on what terrorists were communicating about... Another problem is that Gerv paper only covers SSL protected sites, but most recent phishing attacks (example: http://www.rceasy.com/paypal/ ) do not even use SSL protection, so I might still be fooled, without being notified. The problem with providing *any* protection for non SSL phishing is that even if it is done and done well, it still doesn't cover the DNS attack. The phisher can always just install a virus or poison the DNS system, so any protection will be a short term fix. (DNS viruses have been deployed against online payment systems, as of about 4-6 months back.) So the strategy is to de-emphasise non-SSL protections, and to emphasise that SSL protects against phishing. But it can only do that if the cert info and naming info is displayed and under user control. So there are several steps needed to get to that point. iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
HJ wrote: Nelson B wrote: HJ wrote: Lets take this example, Gerv wrote in his paper that SSL History should be user accessible, but I don't agree because what if I go to a public Internet cafe or use Internet from some public computer in my hotel? Err, make that: "...shouldn't be user accessible,..." /HJ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
Nelson B wrote: HJ wrote: Having troubles reading the text, try this one: http://multizilla.mozdev.org/screenshots/features/spoofing/new-ssl-site-bimsheet.jpg First of all, i've just updated my screenshot: http://multizilla.mozdev.org/screenshots/features/spoofing/new-ssl-site-bimsheet-v2.jpg While you're at it, you should display all the "subject alternative names" in the cert, in addition to the "Common Name". I came to the same conclusion, at least I hope you are revering at this kind of info: CN = www.paypal.com OU = Terms of use at www.verisign.com/rpa (c)00 OU = Information Systems O = Paypal, Inc. L = Palo Alto ST = California C = US The "Common Name" is no longer considered the "right" place to contain the server's domain name. The right place is in the certificate's list of "subject alternative names", and that list may contain multiple domain names and/or IP addresses. It's good to continue to display the common name, as many legacy certificates still use that. But more and more we see modern certs that don't have the domain name in the "common name", and hence the server's domain name doesn't appear in that dialog. If the dialog was fixed to display subject alternate names, that would help a lot. It's a shame that this wasn't fixed in mozilla years ago. But PSM is an orphan. You're doing more to help PSM than has been done in a long time, and I (for one) appreciate it. I just wish your work was going into the main mozilla PSM source, rather than into an offshoot. Well, at least we're discussing a possible solution, and who knows what happens at the end. It sure won't hurt ;) Lets take this example, Gerv wrote in his paper that SSL History should be user accessible, but I don't agree because what if I go to a public Internet cafe or use Internet from some public computer in my hotel? Someone might add the wrong validation keys, and I'll end up visiting a phony site, without being notified about my error! Another problem is that Gerv paper only covers SSL protected sites, but most recent phishing attacks (example: http://www.rceasy.com/paypal/ ) do not even use SSL protection, so I might still be fooled, without being notified. /HJ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
HJ wrote: Having troubles reading the text, try this one: http://multizilla.mozdev.org/screenshots/features/spoofing/new-ssl-site-bimsheet.jpg While you're at it, you should display all the "subject alternative names" in the cert, in addition to the "Common Name". The "Common Name" is no longer considered the "right" place to contain the server's domain name. The right place is in the certificate's list of "subject alternative names", and that list may contain multiple domain names and/or IP addresses. It's good to continue to display the common name, as many legacy certificates still use that. But more and more we see modern certs that don't have the domain name in the "common name", and hence the server's domain name doesn't appear in that dialog. If the dialog was fixed to display subject alternate names, that would help a lot. It's a shame that this wasn't fixed in mozilla years ago. But PSM is an orphan. You're doing more to help PSM than has been done in a long time, and I (for one) appreciate it. I just wish your work was going into the main mozilla PSM source, rather than into an offshoot. -- Nelson B ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
Jean-Marc Desperrier wrote: Gervase Markham wrote: - The text used to explain the feature isn't at all clear to average users. What is an "encrypted security key"? What does it mean if it's missing? The message bar doesn't say. +1 I thought it would be *really* obscure for the average user. Ok, so what would you have used? It is easy to blame one for not using the right words/expressions, but again, this is a concept, and not adding the "right words/expressions" yourself doesn't help anybody. /HJ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
Gervase Markham wrote: HJ wrote: Anyway, you may, or may not, nitpick about the used text and what not, but a fact is a fact, this works for MultiZilla users, but what do you think about this? So this is an implementation of "New Site", from http://www.gerv.net/security/phishing-browser-defences.html#new-site ? Yeah, that seems pretty much the same as what I did...I must be on the right track, this time :-) If so, that's great :-) However, I have a few comments on the implementation: Sure, burn away, after all this is a concept ;) - The text used to explain the feature isn't at all clear to average users. What is an "encrypted security key"? What does it mean if it's missing? The message bar doesn't say. - IMO, there's no need for preferences for this stuff. Firefox isn't going to have UI for an IDN preference, or a "display as punycode" preference. So you are forcing all people to look at punycode all the time, even if that makes it worse? What if I have a punycode look alike domain? Yeah, that will make it harder I guess. - The explanatory text in the popup is too verbose. Ok, but which part? The top, middle or bottom? Please note that that middle part is in fact an but without the CSS love that it needs. Now, you might wonder, do we really need this, yes we do, because my bank site (for example) makes use of a chromeless window, without navigation- and status bar, so I need to have a way of displaying the certificate info, or I would be lost and it would still very easy to deceive our users without this kind of information. Let me ask you another question; do you trust the site, the certificate, the domain holder or the CA that issued that certificate? - I don't think it's necessary to involve the whole "Master Password" thing. Most users don't use them anyway. The question is, should we explain them why they need one, or do we wait till some ill extension writer steals your sensitive data? I could ask you this; why have a Master Password feature in Mozilla/Mozilla Firefox, if "Most users" don't use it (your words)? Not using an important feature should be on the educational list for end users, how else would this anti phishing prevention work, because humans are still, and will always be, the weakest link... On a site note, do you have "wallet.crypto" set to 'true' or 'false'? I keep telling people to use 'true' and I made an extension to proof/explain why, I think that was about two years ago now. Some people, and I'm not pointing fingers, would have called that *the* first "MafiaZilla" extension :-) A "hashed SSL domain history" is even less privacy-invading than keeping a cache of SSL certificates, which is a fairly uncontentious thing for a browser to do. Good, because I don't keep certificates cached, that would be insane, but I keep a cache of hash keys, made out of the serial number and SHA-1 fingerprint of the certificate. Note the "MultiZilla validates websites that utilize SSL authentication..." part of the BIM text. How else can we validate certificates? Did you consider adopting the UI suggestions in my paper? I've said this before, and I keep repeating myself over and over again; go to a local school and ask young children what it is and you will find out that the 'silly character' suggestion doesn't stand long. Also, using "new site" is a bit blurry to me Is it a new domain name, are you visiting the site for the first time, didn't you store a key for it, did you clear your SSL History or are you using a different profile/computer system? What about theme and extension authors, they can undo/change/hide this, so that won't work either. What if I hide my status bar? Are you (Mozilla Firefox) re-enabling "MY" statusbar, just to be able to display that silly lock and text again? Oh btw, and not being able to clear SSL History, other than removing the file, is not a good thing, just think about public Internet spots. Think about this; John Doe visits https://www.majorbank.com in an Internet cafe, and you're next, right, you shouldn't visit your bank site in a public Internet Cafe, but that's what happens every day, more than you can imagine. Ok, so now Jane Doe visits this Internet cafe, hopefully the owner is not a bad person, because they can already 'steal' lots of handy/important data for criminal use, anyway, she visits the same phishing site, without knowing it because she thinks that this is the right site, after all, there's no warning, right? So what happens to her money/bank account? /HJ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
Gervase Markham wrote: - The text used to explain the feature isn't at all clear to average users. What is an "encrypted security key"? What does it mean if it's missing? The message bar doesn't say. +1 I thought it would be *really* obscure for the average user. ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
HJ wrote: Anyway, you may, or may not, nitpick about the used text and what not, but a fact is a fact, this works for MultiZilla users, but what do you think about this? So this is an implementation of "New Site", from http://www.gerv.net/security/phishing-browser-defences.html#new-site ? If so, that's great :-) However, I have a few comments on the implementation: - The text used to explain the feature isn't at all clear to average users. What is an "encrypted security key"? What does it mean if it's missing? The message bar doesn't say. - IMO, there's no need for preferences for this stuff. Firefox isn't going to have UI for an IDN preference, or a "display as punycode" preference. - The explanatory text in the popup is too verbose. - I don't think it's necessary to involve the whole "Master Password" thing. Most users don't use them anyway. A "hashed SSL domain history" is even less privacy-invading than keeping a cache of SSL certificates, which is a fairly uncontentious thing for a browser to do. Did you consider adopting the UI suggestions in my paper? Gerv ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
HJ wrote: I have a working concept that might be used for VanillaZilla, but I don't know if this is what you need/like: Here's a screenshot of MultiZilla's BIM (Browser Info Message) displayed when a new SSL protected site, without SSL Hash key, has been detected: http://multizilla.mozdev.org/screenshots/features/spoofing/new-ssl-site-bim.jpg Here's a screenshot after you click on the displayed BIM: http://multizilla.mozdev.org/screenshots/features/spoofing/new-ssl-site-bimsheet-overview.jpg Having troubles reading the text, try this one: http://multizilla.mozdev.org/screenshots/features/spoofing/new-ssl-site-bimsheet.jpg I also modified MultiZilla's Advanced Pref Panel, here's a screenshot of it: http://multizilla.mozdev.org/screenshots/features/spoofing/idn-support-pref-panel.jpg Anyway, you may, or may not, nitpick about the used text and what not, but a fact is a fact, this works for MultiZilla users, but what do you think about this? These are fantastic! Rush them out! Yes, I would nitpick on the text you use :-) The error message in the first picture seems meaningless tech drivel on first casual reading. Perhaps: "MultiZilla thinks 'www.dodgy.com' is a new website, ..." Experimentation called for here. (The next steps after that is to consider how you display the CA name, and how you would store a petname for that site.) Good stuff! iang -- News and views on what matters in finance+crypto: http://financialcryptography.com/ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
HJ wrote: HJ wrote: J. Greenlees wrote: HJ wrote: Duane wrote: HJ wrote: Having troubles reading the text, try this one: http://multizilla.mozdev.org/screenshots/features/spoofing/new-ssl-site-bimsheet.jpg any thoughts on the problem of sites using multiple private keys/certificates over multiple domains for the same hostname? Each certificate/security change will trigger a new BIM(Sheet) so that should not be a problem, but I don't have an example to verify this, do you have one for me? /HJ x-mail.net free webmail system that uses at least two certs. ( one with a name error [www.x-mail.net instead of x-mail.net] so it's real clear that it's a different cert ) That's just perfect, thanks J No, they just use one certificate for two different domain names :-( /HJ sorry, didn't know that. Jaqui ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
HJ wrote: J. Greenlees wrote: HJ wrote: Duane wrote: HJ wrote: Having troubles reading the text, try this one: http://multizilla.mozdev.org/screenshots/features/spoofing/new-ssl-site-bimsheet.jpg any thoughts on the problem of sites using multiple private keys/certificates over multiple domains for the same hostname? Each certificate/security change will trigger a new BIM(Sheet) so that should not be a problem, but I don't have an example to verify this, do you have one for me? /HJ x-mail.net free webmail system that uses at least two certs. ( one with a name error [www.x-mail.net instead of x-mail.net] so it's real clear that it's a different cert ) That's just perfect, thanks J No, they just use one certificate for two different domain names :-( /HJ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
J. Greenlees wrote: HJ wrote: Duane wrote: HJ wrote: Having troubles reading the text, try this one: http://multizilla.mozdev.org/screenshots/features/spoofing/new-ssl-site-bimsheet.jpg any thoughts on the problem of sites using multiple private keys/certificates over multiple domains for the same hostname? Each certificate/security change will trigger a new BIM(Sheet) so that should not be a problem, but I don't have an example to verify this, do you have one for me? /HJ x-mail.net free webmail system that uses at least two certs. ( one with a name error [www.x-mail.net instead of x-mail.net] so it's real clear that it's a different cert ) That's just perfect, thanks J /HJ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
HJ wrote: Duane wrote: HJ wrote: Having troubles reading the text, try this one: http://multizilla.mozdev.org/screenshots/features/spoofing/new-ssl-site-bimsheet.jpg any thoughts on the problem of sites using multiple private keys/certificates over multiple domains for the same hostname? Each certificate/security change will trigger a new BIM(Sheet) so that should not be a problem, but I don't have an example to verify this, do you have one for me? /HJ x-mail.net free webmail system that uses at least two certs. ( one with a name error [www.x-mail.net instead of x-mail.net] so it's real clear that it's a different cert ) ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
HJ wrote: > Each certificate/security change will trigger a new BIM(Sheet) so that > should not be a problem, but I don't have an example to verify this, do > you have one for me? I'm theorising about the possibility of it, for example large installations using clusters while it possibly isn't good security practise to reuse the same privatekey/certificate for a bunch of servers but I bet it occurs for things like large webmail installations if not banking clusters etc... -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://happysnapper.com.au - Sell your photos over the net! http://e164.org - Using Enum.164 to interconnect asterisk servers "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
Duane wrote: HJ wrote: Having troubles reading the text, try this one: http://multizilla.mozdev.org/screenshots/features/spoofing/new-ssl-site-bimsheet.jpg any thoughts on the problem of sites using multiple private keys/certificates over multiple domains for the same hostname? Each certificate/security change will trigger a new BIM(Sheet) so that should not be a problem, but I don't have an example to verify this, do you have one for me? /HJ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
HJ wrote: > Having troubles reading the text, try this one: > http://multizilla.mozdev.org/screenshots/features/spoofing/new-ssl-site-bimsheet.jpg any thoughts on the problem of sites using multiple private keys/certificates over multiple domains for the same hostname? -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://happysnapper.com.au - Sell your photos over the net! http://e164.org - Using Enum.164 to interconnect asterisk servers "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
Re: Long Term IDN/punycode spoofing strategy concept
Note that MultiZilla's BIM Sheets are displayed just like View/Toolbars/Customize in Mozilla Firefox, sort of a drop down window. Also note that this is my own 'work in progress concept' from the days before (January 15th to be exact) Gerv Blogged about something like this :-) /HJ ___ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
