Re: Dear RIPE: Please don't encourage phishing
On Wed, 15 Feb 2012 10:44:38 +0100, Stephane Bortzmeyer said: Challenge taken. RFC 2277, IETF Policy on Character Sets and Languages, section 3.1, Protocols MUST be able to use the UTF-8 charset [...] Protocols MAY specify, in addition, how to use other charsets [something DNS does not do, so it must be UTF-8] (ooh.. an RFC lawyering fight. Goody goody, haven't had one in a while.. :) That requires overlooking the minor detail that the DNS RFC predates that by quite some time, and there's no combination of RFCs 2119 and 2277 that mandates retrofitting grandfathered protocols by fiat. It also requires overlooking the fact that 2277 is a BCP, not an Internet Standard, and as such isn't itself binding, merely A Good Idea. Nice try though. ;) pgpFmnL4w61nh.pgp Description: PGP signature
Re: Dear RIPE: Please don't encourage phishing
In message 86mx8kqpy7@seastrom.com, Robert E. Seastrom writes: valdis.kletni...@vt.edu writes: On Wed, 15 Feb 2012 10:44:38 +0100, Stephane Bortzmeyer said: Challenge taken. RFC 2277, IETF Policy on Character Sets and Languages, section 3.1, Protocols MUST be able to use the UTF-8 charset [...] Protocols MAY specify, in addition, how to use other charsets [something DNS does not do, so it must be UTF-8] (ooh.. an RFC lawyering fight. Goody goody, haven't had one in a while.. :) That requires overlooking the minor detail that the DNS RFC predates that by quite some time, and there's no combination of RFCs 2119 and 2277 that mandates retrofitting grandfathered protocols by fiat. It also requires overlooking the fact that 2277 is a BCP, not an Internet Standard, and as such isn't itself binding, merely A Good Idea. Nice try though. ;) Valdis, re-read the original assertion and challenge. Your attempt at RFC lawyering appears to be Experimental grin The Internationalised DNS uses IDNA suite of RFC's to encode UTF into A-labels. Before deciding to go the IDNA route, treating DNS labels as UTF-8 was discussed, evaluated and rejected. DNS labels are length tagged binary blobs with case folding of the 7 bit ascii values 'a'-'z' when performing lookups. If a server is fully compliant (and I don't think any is) answers should be returned in a case preserving manner, including owner names. The intent of RFC 1035 was to be able to use the DNS to store and retrieve binary data using binary keys. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Dear RIPE: Please don't encourage phishing
On 2/15/12 8:32 AM, Mark Andrews wrote: ... Before deciding to go the IDNA route, treating DNS labels as UTF-8 was discussed, evaluated and rejected. well, sort of. we started with idn as a wg label. the smtp weenies opined that they'd never have a flag day and anything other than a boot encoding in LDH would harm LDH limited mailers, so ... the code point problem (or problems) was moved out of infrastructure and into applications, so the work product was labeled idna, which the successor wg had no alternative except to follow the in a set of dependencies and assumptions. as you observed, labels are length tagged binary blobs, and where the blobs consist of 7 bit ascii values in the 'a'-'z' range, case folding is performed in lookup. what happens outside of that range is a path not taken, though i tried in 2929 to leave that open for future work, the sentence which read text labels can, in fact, include any octet value including zero octets but most current uses involve only [US-ASCII]. was, if memory serves, proposed by a co-author to have been more restrictive. i agree with the rejected statement, the evaluated and even the discussed overstate the room available after the smtp weenies weighed in on what was permissible in headers. -e
Re: Dear RIPE: Please don't encourage phishing
valdis.kletni...@vt.edu wrote: Doesn't actually matter, because the .ua registry isn't allowing Greek Gamma or Latin-E-with-diaresis, in domain names. Such local conventions have nothing to do with internationalization. But quite frankly, turning off IDN doesn't fix that problem - greekbank.gr is spoofable by greekbank.ua and greekbank.com. The problem is greekbank.gr is spoofable as greekbank.gr. Is a Russian word containing no unique (unique to ASCII) Cyrillic characters encoded as Latin character using ASCII, even though a Russian word containing unique (whatever unique means) Cyrillic character encoded as Cyrillic characters? No, it means you get to pick 'all-latin-chars.ua' or 'all-cyrillic-chars.ua'. And due to the requirement that a cyrillic name have a special char in it, you can's spoof an all-latin-chars.ua name. That a cyrillic name have a special char in it makes it impossible to have a Cyrillic representation of an Ukrainian word containing no special chars and is impractical. The only protection is to disable IDN. You also have to ban the use of numbers in domain names, because you need to prevent people being tricked by micros0ft.com and m1crosoft.com. No, the simple solution against such a simple problem is to use proper font, because all the people know that '0' and 'o' are different characters and treat them differently. Masataka Ohta
Re: Dear RIPE: Please don't encourage phishing
On 2/11/2012 4:37 PM, Keith Medcalf wrote: Unfortunately that's not under control of those businesses. This plain text email you sent comes across with clickable mailto and http links in your signature in most modern email clients despite you having sent it in plain text. Helpful email program defaults won't force people to copy and paste the URL. They just create the hyperlink for people based on the pattern in the plain text message. It seems anything beginning with www or http(s):// will be converted to a clickable link out of convenience to the user. It's always that endless struggle of security vs. convenience... At least it is what is says, and the effect is precisely the same as if one copied and pasted the link into the browser. What is truly evil is non text/plain email. Anyone who permits or assists in the rendering of non-plaintext email deserves whatever befalls them -- and they should not be permitted zero-liability for their stupidity and ignorance. They end-user is of course entitled to cross-claim against the manufacturer of the defective system or device which rendered the message in a deceptive way (such as Dell and Microsoft in particular). The average person won't know that it is what it says if it's possible for it not to be... which I think is what you're driving at with eliminating that as a possibility. And the effect is the same, but the time to do it is different. I wouldn't want to have to use web sites with no hyperlinks and I was expected to just copy and paste every URL I wanted to follow into the address bar. However, the vast majority of the Internet population (and human beings in general) like aesthetically pleasing things and therefore don't want to upgrade to mutt and lynx to be safe on the Internet. HTML based email looks much better despite embedded hidden evil tags. All recent email clients I've come across give you anti-phishing warnings in one way or another if the URL does not match the actual link. I honestly can't remember the last time I've seen a phishing email because they are so easy to detect before they even get to your inbox. Sure, you could also keep the HTML and disable the links (which I've seen done), but then you inconvenience people. Things take too long as it is now anyway despite the constant advancements we see constantly. We need to speed technology up more and make them easier AND safer. Technology needs to be unobtrusive to the end user and get out of their way. I personally don't believe the mantra of stripping away technology to solve problems rather than applying technology and advancing standards is the answer just because technology makes something dangerous for the average consumer. Despite all the car fatalities on a yearly basis and the constant safety advancements we have in the auto industry, I have never heard people say we should get rid of cars and go back to horses. Of course scam emails are much more prevalent than car fatalities by far, but they're also less serious. Most of the younger generation I know doesn't even use email. They have it as a formality because things require it and exchange everything via Facebook or video chat or IM... which simply means this concern over the trickery of immoral scammers on the average unsuspecting person will just shift mediums as has throughout history. It's already prevalent on these mediums now. Not sure what the jab at Dell was specifically other than the email address I posted from originally. As far as I have seen, Dell doesn't make email clients. That's like someone holding Sony/Samsung/LG liable because their TV showed them a TV program they didn't want to see. Anyway, just my $0.02 wrapped in rambling from a tired mind. Sorry if some of this didn't make sense as a result. :) -Vinny P.S. I prefer plain-text email. ;)
Re: PGP, S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage phishing)
In article 20120210213755.ga88...@ussenterprise.ufp.org, Leo Bicknell bickn...@ufp.org writes Hypothetically, I get an e-mail from ripe.ca Or from ripen.cc which is one of their actual domains (used briefly as a url shortener). -- Roland Perry
Re: Dear RIPE: Please don't encourage phishing
What is truly evil is non text/plain email. Have we fallen through a time warp into 1996? R's, John -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
Re: Dear RIPE: Please don't encourage phishing
The DNS industry is putting us a long way from when RFC 2826 was written. Christian On 12 Feb 2012, at 01:31, John Levine wrote: Nice. Basically, unless the TLD registrar has a public policy that basically says We don't allow names with cyrillic C to collide with MICROSOFT, their hostnames all get displayed as xn--gobbledygook. More or less. ICANN has been wrestling with the lookalike character issue in domain names for about a decade. I think it's fair to say that everyone agrees that all solutions are less than totally satisfactory. R's, John
Re: Dear RIPE: Please don't encourage phishing
The DNS industry is putting us a long way from when RFC 2826 was written. That's true, but you can't just blow off the majority of people in the world who use languages that you can't write in the ASCII character set. It's a hard problem. I wouldn't say that ICANN's approach has been optimal, but I also wouldn't say there's an obvious solution they've missed. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
Re: Dear RIPE: Please don't encourage phishing
What is truly evil is non text/plain email. Have we fallen through a time warp into 1996? Evidently yes. Look, it's a known-not-to-work SMTP callback: kmedc...@dessus.com: Connected to 69.172.205.65 but sender was rejected. Remote host said: 578 jo...@iecc.com address rejected with reverse-check -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
Re: Dear RIPE: Please don't encourage phishing
On Sun, Feb 12, 2012 at 04:44:13AM -0500, Vinny Abello wrote: All recent email clients I've come across give you anti-phishing warnings in one way or another if the URL does not match the actual link. Which is great, but doesn't help you if the URL and the link are: http://firstnationalbank.example.com because a significant number of users will only see firstnationalbank and .com. That's why I recommend that banks et.al. don't put *any* URLs in their messages. If they make this an explicit policy and pound it into the heads of their customers that ANY message containing a URL is not from them, and that they should always use their bookmarks to get to the bank's site, then they're training their customers to be phish-resistant. ---rsk
Re: Dear RIPE: Please don't encourage phishing
That's why I recommend that banks et.al. don't put *any* URLs in their messages. If they make this an explicit policy and pound it into the heads of their customers that ANY message containing a URL is not from them, and that they should always use their bookmarks to get to the bank's site, then they're training their customers to be phish-resistant. they do, and the next thing you know, someone in marketing sends out an email with an url -anyway-. considering the fact that banks don't seem to like to be contacted by emails nor get replies (noreply@...) i'd strongly suggest them not to use crappy obsolete SMTP at all but rather present the users with their messages they don't want to distribute by paper mail -after- logging into their online banking system, where they can use all the html, links, flash *kuch* etc they want. ---rsk
Re: Dear RIPE: Please don't encourage phishing
btw, i'm quite sure that -banks- of all things have the resources to just take the transaction part for consumers -off their pcs- and simply send them a dedicated device with an ethernet port to do the transactions on. the same way they do in shops. no more bothering with omg what if they click a link, get phished and end up in the transaction interface, as there simply won't be a web based transaction interface. guess the its not allowed to cost anything mentality of banks towards the internet is mostly gone (About time too ;) so they could consider other options besides using the hardware that's allready there and owned by the customer (and full of virusses and spyware ;) -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. Co. KG = Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration:HRA 42834 B BERLINPhone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE:CBSK1-RIPEe-Mail: s...@cb3rob.net = penpen C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob = Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Sun, 12 Feb 2012, Rich Kulawiec wrote: On Sun, Feb 12, 2012 at 04:44:13AM -0500, Vinny Abello wrote: All recent email clients I've come across give you anti-phishing warnings in one way or another if the URL does not match the actual link. Which is great, but doesn't help you if the URL and the link are: http://firstnationalbank.example.com because a significant number of users will only see firstnationalbank and .com. That's why I recommend that banks et.al. don't put *any* URLs in their messages. If they make this an explicit policy and pound it into the heads of their customers that ANY message containing a URL is not from them, and that they should always use their bookmarks to get to the bank's site, then they're training their customers to be phish-resistant. ---rsk
Re: Dear RIPE: Please don't encourage phishing
Heck, even Klingon made it to the private UTF-8 registry, http://en.wikipedia.org/wiki/Klingon_writing_systems :) Jeff
Re: Dear RIPE: Please don't encourage phishing
In article pine.lnx.4.64.1202121919390.10...@a84-22-97-10.cb3rob.net you write: btw, i'm quite sure that -banks- of all things have the resources to just take the transaction part for consumers -off their pcs- and simply send them a dedicated device with an ethernet port to do the transactions on. More likely USB, but yes, a doozit with a small screen to display the amount and recipient of a transaction and a verification code you type in, and sufficient crypto to set up a secure channel back to the bank would fix a lot of phishing. I don't understand bank security at all. HSBC recently sent me a Digipass 270 with a 12 button keyboard and a one-line display that is apparently able to do signatures, but all they use it for is a PIN. That's helpful against password theft, but not MITM. R's, John
Re: Dear RIPE: Please don't encourage phishing
On 2/12/2012 1:19 PM, Rich Kulawiec wrote: On Sun, Feb 12, 2012 at 04:44:13AM -0500, Vinny Abello wrote: All recent email clients I've come across give you anti-phishing warnings in one way or another if the URL does not match the actual link. Which is great, but doesn't help you if the URL and the link are: http://firstnationalbank.example.com because a significant number of users will only see firstnationalbank and .com. That's why I recommend that banks et.al. don't put *any* URLs in their messages. If they make this an explicit policy and pound it into the heads of their customers that ANY message containing a URL is not from them, and that they should always use their bookmarks to get to the bank's site, then they're training their customers to be phish-resistant. Yes, very true. I unfortunately see average people fall for these types of things all the time. Ultimately, the issue is getting the end user educated. However, I've also seen users get a message drilled into their heads for 10 years that an email admin will never ask for their passwords, yet they eagerly give them away to some random scammer that says they need their password or their account will be shut off, signed by the email team... and suddenly their email account is spewing spam from random IP addresses all over the net. sigh The weakest link is ultimately the person behind the device. We're attempting to make technology fix stupid, which is often harder for the people designing the technology. They would never think sticking their hand down a garbage disposal is a good idea, but there are people out there that do this. :( Likewise, a person wouldn't click on a link if it's blatantly obvious the link doesn't point to the real web site, right? :) Obviously no. To be very effective, security design needs to assume the biggest threat to the security of anything is the person on the good side of the fence who will open the gate. Lately, I get calls on a weekly basis from people trying to steal my credit card from me. If I have time I like to have fun with them, eating up their time so they have less of it to scam people who don't know any better. (Look on Youtube for people doing this. It's hilarious). These scammers have been around for at least 5 years or longer and nobody has yet fixed this problem, which is also astounding. As a result, customers who don't recognize the scam get their credit card whacked with random charges because they didn't think anything was wrong with giving away their credit card info and social security number to a random stranger who calls them and claims to be able to lower their interest rate. So at the same time making people aware the real emails will not contain links, banks should be doing a better job telling people not to give away their credit card info to anyone in a situation similar to this. It should be better handled by all banks and companies in genereal as a global security education process. I don't believe it should be limited just to email or Internet related usage of the bank or company's resources. I'm probably not giving people enough credit, but social engineering is likely the most effective hacking technique that exists because it targets the weakest link and often works. That's currently the easiest thing to target because security has improved so much over the years on the technological end. I'm not sure about others, but the most prevalent security threats I see today are vastly different than the ones from ten to fifteen years prior. -Vinny
Re: Dear RIPE: Please don't encourage phishing
On Sun, 12 Feb 2012 16:59:36 +0900, Masataka Ohta said: The problem is greekbank.gr is spoofable as greekbank.gr. That would be the .gr registry's problem then. They could take the same solution as the .ua registry -force lowercase and allow all-latin or all-greek names. Oh, what do you know... they *do* do something similar. https://grweb.ics.forth.gr/tomcat_docs/AP592_012_2011_.pdf See page 5 and 6, in particular: 8. Any [.gr] Domain Names that are homographs of a [.gr] Domain Name already assigned shall be automatically reserved for the Holder of the above assigned [.gr] Domain Name and shall be activated following the Holder's submission of an activation declaration to the Registry. So how do you spoof greekbank.gr with greekbank.gr under those rules? No, the simple solution against such a simple problem is to use proper font, because all the people know that '0' and 'o' are different characters and treat them differently. Well then, if all that's required is a proper font, what is the problem with your Saitoh families? You said they were represented by 4 similar but different characters, which is distinguished by people named Saitoh but not distinguished by most others, Why can't *they* use a proper font that makes the difference between the 4 characters recognizable? After all, *they* know the 4 characters are different and can treat them differently, right? (And no, it's *not* different for kanji - it's the exact same problem and you know it. In both cases, (I/l and your Sai issue), the problem is similar glyphs. Don't bother replying to suggest a fix for the lower-l/upper-I issue unless the *same* fix applies to your Sai issue). pgpmqXJtB2Vw6.pgp Description: PGP signature
Re: Dear RIPE: Please don't encourage phishing
valdis.kletni...@vt.edu wrote: The problem is greekbank.gr is spoofable as greekbank.gr. That would be the .gr registry's problem then. As it is the problem of IDN, same problem exist everywhere. They could take the same solution as the .ua registry -force lowercase and allow all-latin or all-greek names. DNS does not allow .ua registry force lowercase for ASCII. So how do you spoof greekbank.gr with greekbank.gr under those rules? I merely used your example. Well then, if all that's required is a proper font, what is the problem with your Saitoh families? All that's required is a proper font for ASCII. Beyond ASCII, you almost automatically loss. For example, in ISO8859-1 context, uppercase of 'y' with diaeresis is not 'Y' with diaeresis, because there is no 'Y' with diaeresis in ISO8859-1, which is bad enough. So, I can understand your attempt to insist on lowercase, but it does not work because DNS does not allow it. Masataka Ohta
Re: Dear RIPE: Please don't encourage phishing
Oh, and 'i' and 'l' need to be banned as well, because a san-serif uppercase I looks a lot like a san-serif lowercase l. (In fact, in the font I'm currently using, the two are pixel-identical). I don't see anybody calling for the banning of 'i' and 'l' in domain names due to that. The very first phishing message I ever saw was from paypa1.com. --Steve Bellovin, https://www.cs.columbia.edu/~smb
Re: Dear RIPE: Please don't encourage phishing
2012/2/12 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp: valdis.kletni...@vt.edu wrote: [snip] So, I can understand your attempt to insist on lowercase, but it does not work because DNS does not allow it. [snip] Not exactly... DNS is case-insensitive when you are talking about 7-bit ASCII; the set of alphabetic characters that can appear in a DNS label; with no punycode. IDN means that non-ASCII characters are represented using punycode. As soon as you have a browser parsing punycode stuff, any string containing unicode characters has a unique punycode encoding / RFC 3491 / RFC 3492. The symbols represented in the punycode encodings are not case sensitive. Uppercase A-Z vs Lowercase a-z in the generalized variable-length integers are not distinct, the punycode representation itself cannot really be case sensitive, but the codepoint represented by the encoding, the result of decoding the punycode is case-preserving. -- -JH
Re: Dear RIPE: Please don't encourage phishing
DNS is case-insensitive when you are talking about 7-bit ASCII pedantry dns itself is purely eight bit transparent. one can even have a dot as a non-separator. p.r.c could be a tld. it's strictly length/value. of course, everyone and their dog has placed restrictions on it for this use or that. randy
Re: Dear RIPE: Please don't encourage phishing
On Sun, Feb 12, 2012 at 11:36 PM, Randy Bush ra...@psg.com wrote: DNS is case-insensitive when you are talking about 7-bit ASCII pedantry dns itself is purely eight bit transparent. one can even have a dot as a non-separator. p.r.c could be a tld. it's strictly length/value. That's true, but there is no standard character representation for octet values 128 - 255. If you use them in a DNS record, they are just binary values that don't refer to a specific printable symbol. Only octets in the range from 65 to 90 (uppercase) and 977 to 122 (lowercase) have a case equivalent for DNS resolution. And IDN uses 7-bit ASCII DNS records. -- -JH
Re: Dear RIPE: Please don't encourage phishing
dns itself is purely eight bit transparent. one can even have a dot as a non-separator. p.r.c could be a tld. it's strictly length/value. That's true, but there is no standard character representation for octet values 128 - 255. utf-8 is the one used in the ietf community. Only octets in the range from 65 to 90 (uppercase) and 977 to 122 (lowercase) have a case equivalent for DNS resolution. dns resolution is eight bit clear. randy
Re: Dear RIPE: Please don't encourage phishing
On Sun, Feb 12, 2012 at 09:36:54PM -0800, Randy Bush wrote: DNS is case-insensitive when you are talking about 7-bit ASCII pedantry dns itself is purely eight bit transparent. one can even have a dot as a non-separator. p.r.c could be a tld. it's strictly length/value. of course, everyone and their dog has placed restrictions on it for this use or that. randy ah, the good'ol days. ^g.net as an early attempt for the visually impaired lasted for a couple months. about the same time you received your IPv4 /33 /bill
Re: Dear RIPE: Please don't encourage phishing
Jimmy Hess wrote: As soon as you have a browser parsing punycode stuff, any string containing unicode characters has a unique punycode encoding / RFC 3491 / RFC 3492. Labels (not any string) which happens to be pure ASCII are still case insensitive, which is DNS. Note that, according to Valdis; : (The actual policy for the .UA registrar is more subtle. : They *do* in fact allow U+0441 Cyrillic Small Letter ES : which is visually a C to us Latin-glyph users. However, : they require at least one character that's visually unique : to Cyrillic in the domain name. They also don't allow ; mixed Cyrillic/Latin scripts in one domain name). a label (not domain name) of a Ukrainian word all the characters of which have shapes identical to some ASCII characters can only be represented using ASCII characters only. Masataka Ohta
Re: Dear RIPE: Please don't encourage phishing
In message m2ipjbmgbq.wl%ra...@psg.com, Randy Bush writes: dns itself is purely eight bit transparent. =A0one can even have a dot as a non-separator. =A0p.r.c could be a tld. =A0it's strictly length/value. That's true, but there is no standard character representation for octet values 128 - 255. utf-8 is the one used in the ietf community. I challenge you to find a RFC that say it is UTF-8. Only octets in the range from 65 to 90 (uppercase) and 977 to 122 (lowercase) have a case equivalent for DNS resolution. dns resolution is eight bit clear. It may be 8 bit clear but only 0-127 have defined meaning. 128-255 may be UTF-8 but they could equally be ISO-LATIN-*. randy -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Dear RIPE: Please don't encourage phishing
dns resolution is eight bit clear. It may be 8 bit clear but only 0-127 have defined meaning. 128-255 may be UTF-8 but they could equally be ISO-LATIN-*. nothing means anything
Re: Dear RIPE: Please don't encourage phishing
On 11/02/12 01:16, Masataka Ohta wrote: Randy Bush wrote: My $0.02 on this issue is if the message is rich text I hover over the link and see where it actually sends me. idn has made this unsafe I pointed it out at IETF Munich in 1997 that with an example of: MICROSOFT.COM where 'C' of MICROSOFT is actually a Cyrillic character. But, people insisted working on useless IDN. Masataka Ohta Techniques to deal with this sort of spoofing already exist: see http://www.mozilla.org/projects/security/tld-idn-policy-list.html for one quite effective approach. -- Neil
Re: Dear RIPE: Please don't encourage phishing
My $0.02 on this issue is if the message is rich text I hover over the link and see where it actually sends me. idn has made this unsafe Techniques to deal with this sort of spoofing already exist: see http://www.mozilla.org/projects/security/tld-idn-policy-list.html for one quite effective approach. and grandma is gonna use this? with internet exploder or safari? let's try to remember that there are normal human beings on the net these years (bummer that, eh?), and this list is kind of about serving them. randy
Re: Dear RIPE: Please don't encourage phishing
The internet was way cooler before that chris On Feb 11, 2012 12:09 PM, Randy Bush ra...@psg.com wrote: My $0.02 on this issue is if the message is rich text I hover over the link and see where it actually sends me. idn has made this unsafe Techniques to deal with this sort of spoofing already exist: see http://www.mozilla.org/projects/security/tld-idn-policy-list.html for one quite effective approach. and grandma is gonna use this? with internet exploder or safari? let's try to remember that there are normal human beings on the net these years (bummer that, eh?), and this list is kind of about serving them. randy
Re: Dear RIPE: Please don't encourage phishing
On Feb 11, 2012, at 12:13 PM, chris wrote: The internet was way cooler before that Yes, and a lot of us could run open relays on our SMTP servers to help each other out, and a full usenet feed fit on a plain ol' 9600 baud link. But no way I could have at home the kind of bandwidth I can get today for a very reasonable price, and so on. -jav
Re: Dear RIPE: Please don't encourage phishing
On Sat, 11 Feb 2012 09:09:25 PST, Randy Bush said: My $0.02 on this issue is if the message is rich text I hover over the link and see where it actually sends me. idn has made this unsafe Techniques to deal with this sort of spoofing already exist: see http://www.mozilla.org/projects/security/tld-idn-policy-list.html for one quite effective approach. Nice. Basically, unless the TLD registrar has a public policy that basically says We don't allow names with cyrillic C to collide with MICROSOFT, their hostnames all get displayed as xn--gobbledygook. (The actual policy for the .UA registrar is more subtle. They *do* in fact allow U+0441 Cyrillic Small Letter ES which is visually a C to us Latin-glyph users. However, they require at least one character that's visually unique to Cyrillic in the domain name. They also don't allow mixed Cyrillic/Latin scripts in one domain name). Or so http://www.hostmaster.ua/idn/ tells me after Google Translate gets done with it. ;) and grandma is gonna use this? with internet exploder or safari? If the manufacturers of IE and Safari can't come up with a similar policy, then the people at Mozilla can use We protect you from malicious names as a marketing diffferentiation feature. pgp2ZWlIcg6HH.pgp Description: PGP signature
RE: Dear RIPE: Please don't encourage phishing
Unfortunately that's not under control of those businesses. This plain text email you sent comes across with clickable mailto and http links in your signature in most modern email clients despite you having sent it in plain text. Helpful email program defaults won't force people to copy and paste the URL. They just create the hyperlink for people based on the pattern in the plain text message. It seems anything beginning with www or http(s):// will be converted to a clickable link out of convenience to the user. It's always that endless struggle of security vs. convenience... At least it is what is says, and the effect is precisely the same as if one copied and pasted the link into the browser. What is truly evil is non text/plain email. Anyone who permits or assists in the rendering of non-plaintext email deserves whatever befalls them -- and they should not be permitted zero-liability for their stupidity and ignorance. They end-user is of course entitled to cross-claim against the manufacturer of the defective system or device which rendered the message in a deceptive way (such as Dell and Microsoft in particular). --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
Re: Dear RIPE: Please don't encourage phishing
Neil Harris wrote: Techniques to deal with this sort of spoofing already exist: see http://www.mozilla.org/projects/security/tld-idn-policy-list.html It does not make sense that .COM allows Cyrillic characters: http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html i script of a domain name is Cyrillic. Domain names do not have such property as script. Is the following domain name: CCC.COM Latin or Cyrillic? for one quite effective approach. The only reasonable thing to do is to disable so called IDN. Masataka Ohta PS Isn't it obvious from the page you referred that IDN is not internationalization but an uncoordinated collection of poor localizations?
Re: Dear RIPE: Please don't encourage phishing
On Fri, Feb 10, 2012 at 10:56 AM, Steven Bellovin s...@cs.columbia.edu wrote: You know, clickable objects in automated business communications are a standard practice, the larger the organization sending the message, the more complicated and annoying their standard e-mail template full of HTML eyecandy, the more clickable links to improve accessibility, and banks among the worst offenders. Those encourage phishing, because HTML just provides way too many methods of faking a URL, or making a 'button' or 'link' go to somewhere else besides what is suggested by the e-mail text. All an e-mail user needs to do is click on one unknown link, to be quietly diverted to a fake website, that will then ask the user to change a password; it makes no difference whether the e-mail itself is about passwords or a security issue or not. Convincing the user to log in can be done while they are visiting the fake website. There are plenty of phishers that rely on convincing users to hit the 'reply' button and divulge sensitive info, with no clickable items in the message at all. But this particular item from RIPE here appears to be a plain text message... text/plain The message from RIPE is darn benign, and does not really encourage phishing moreso. When was the last time you saw a phishing attempt in a text/plain e-mail showing the name of a HTTPS location on the real organization's web site ? If sending out a web address encourages phishers, then what are they supposed to provide to make sure maintainer users can easily and quickly change their password? RIPEs not encouraging phishing by sending such a message. MUA developers who included text/html MIME type support and support creating clickable objects in a HTML message have encouraged convincing phishing very much so. What RIPE did there is a perfectly example of what should be done. Send plain text e-mail with the URL location to review, no HTML doodads. They have no control of your e-mail client that for some reason perhaps turns a plaintext URL into something you can click. I received the enclosed note, apparently from RIPE (and the headers check out). Why are you sending messages with clickable objects that I'm supposed to use to change my password? -- -JH
Re: Dear RIPE: Please don't encourage phishing
valdis.kletni...@vt.edu wrote: (The actual policy for the .UA registrar is more subtle. They *do* in fact allow U+0441 Cyrillic Small Letter ES which is visually a C to us Latin-glyph users. However, they require at least one character that's visually unique to Cyrillic in the domain name. Unique within what? Is a Cyrillic character, which looks like Latin E with diaeresis, a unique Cyrillic character? Is CYRILLIC CAPITAL LETTER GHE, which looks like Greek Gamma, a unique Cyrillic character? Is Greek Gamma, which looks like CYRILLIC CAPITAL LETTER GHE, a unique Greek character? They also don't allow mixed Cyrillic/Latin scripts in one domain name). Is a Russian word containing no unique (unique to ASCII) Cyrillic characters encoded as Latin character using ASCII, even though a Russian word containing unique (whatever unique means) Cyrillic character encoded as Cyrillic characters? It is obvious that such confused scheme encourage phishing a lot. If the manufacturers of IE and Safari can't come up with a similar policy, then the people at Mozilla can use We protect you from malicious names as a marketing diffferentiation feature. The only protection is to disable IDN. Masataka Ohta
Re: Dear RIPE: Please don't encourage phishing
Nice. Basically, unless the TLD registrar has a public policy that basically says We don't allow names with cyrillic C to collide with MICROSOFT, their hostnames all get displayed as xn--gobbledygook. More or less. ICANN has been wrestling with the lookalike character issue in domain names for about a decade. I think it's fair to say that everyone agrees that all solutions are less than totally satisfactory. R's, John
Re: Dear RIPE: Please don't encourage phishing
On 12/02/12 00:09, Masataka Ohta wrote: Neil Harris wrote: Techniques to deal with this sort of spoofing already exist: see http://www.mozilla.org/projects/security/tld-idn-policy-list.html It does not make sense that .COM allows Cyrillic characters: http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html i script of a domain name is Cyrillic. Domain names do not have such property as script. Is the following domain name: CCC.COM Latin or Cyrillic? for one quite effective approach. The only reasonable thing to do is to disable so called IDN. Masataka Ohta PS Isn't it obvious from the page you referred that IDN is not internationalization but an uncoordinated collection of poor localizations? I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN safer, given that it already exists. Lots of people have thought about this quite carefully. See RFC 4290 for a technical discussion of the thinking behind this policy, and RFC 5992 for a policy mechanism designed to resolve the problem you raised in your example above. You will notice that the .com domain does not appear on the Mozilla IDN whitelist. -- N.
Re: Dear RIPE: Please don't encourage phishing
yes, domain names that cannot be typed in with any keyboard/charset on any computer out there, excellent idea, devide and conquerer, i wonder who came up with that idiotic plan again, probably the ITU or one of their infiltrants in icann. how about, we simply don't code any software or adjust any platforms to support it, if nobody uses it, no problem :P (or just deliberately break it as its nothing more than a devide and conquerer attempt of the UN anyway ;) On Sun, 12 Feb 2012, Neil Harris wrote: On 12/02/12 00:09, Masataka Ohta wrote: Neil Harris wrote: Techniques to deal with this sort of spoofing already exist: see http://www.mozilla.org/projects/security/tld-idn-policy-list.html It does not make sense that .COM allows Cyrillic characters: http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html i script of a domain name is Cyrillic. Domain names do not have such property as script. Is the following domain name: CCC.COM Latin or Cyrillic? for one quite effective approach. The only reasonable thing to do is to disable so called IDN. Masataka Ohta PS Isn't it obvious from the page you referred that IDN is not internationalization but an uncoordinated collection of poor localizations? I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN safer, given that it already exists. Lots of people have thought about this quite carefully. See RFC 4290 for a technical discussion of the thinking behind this policy, and RFC 5992 for a policy mechanism designed to resolve the problem you raised in your example above. You will notice that the .com domain does not appear on the Mozilla IDN whitelist. -- N.
Re: Dear RIPE: Please don't encourage phishing
as if it wasn't annoying enough already that some n00bs are using URI's with characters you can't type in (and in most cases don't even display correctly), icann has a better idea! hostnames you can't type in! all those struggeling regimes that want to keep local control over our internets are gonna be so proud of them :P (and that despite the fact that it's perfectly well possible to write -any language out there- in the first 7 bits of ascii) yay, a step back in time, everyone back to their cave and write on the wall with a piece of stone in characters nobody can read! so far for progress... we used to develop stuff so that people could communicate with one another, whatever went wrong, when did it move to preventing people from communicating with one another... i don't have keyboards with a million or so keys on it, do you? and no, i don't know the alt-codes for weird russian or japanese crap. if we wanted local shit only, we could just have stuck with tv and radio and telephones and fax machines. so; we're not implementing any of that, we'll deliberately make any software we produce go nuts on it and cause errors all over the place, and we strongly urge any nerd out there to do exactly the same. On Sun, 12 Feb 2012, Neil Harris wrote: On 12/02/12 00:09, Masataka Ohta wrote: Neil Harris wrote: Techniques to deal with this sort of spoofing already exist: see http://www.mozilla.org/projects/security/tld-idn-policy-list.html It does not make sense that .COM allows Cyrillic characters: http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html i script of a domain name is Cyrillic. Domain names do not have such property as script. Is the following domain name: CCC.COM Latin or Cyrillic? for one quite effective approach. The only reasonable thing to do is to disable so called IDN. Masataka Ohta PS Isn't it obvious from the page you referred that IDN is not internationalization but an uncoordinated collection of poor localizations? I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN safer, given that it already exists. Lots of people have thought about this quite carefully. See RFC 4290 for a technical discussion of the thinking behind this policy, and RFC 5992 for a policy mechanism designed to resolve the problem you raised in your example above. You will notice that the .com domain does not appear on the Mozilla IDN whitelist. -- N.
Re: Dear RIPE: Please don't encourage phishing
On Sun, 12 Feb 2012 03:47:24 GMT, Sven Olaf Kamphuis said: (and that despite the fact that it's perfectly well possible to write -any language out there- in the first 7 bits of ascii) And it's *equally* possible to write any language out there using a 7-bit encoding of the Cyrillic character set. Let me know how you'd enjoy doing that. Oh, that would suck because Cyrillic isn't very similar to your native character set? Welcome to the way the vast majority of the world feels. pgpxpRZIgaBLL.pgp Description: PGP signature
Re: Dear RIPE: Please don't encourage phishing
Neil Harris wrote: I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN safer, given that it already exists. It's like trying to make DES safer. Lots of people have thought about this quite carefully. Not at all. They (including some Japanese) just wished IDN work ignoring technical reality. See RFC 4290 for a technical discussion of the thinking behind this policy, Technically speaking, there are several sets of frequently used different but similar Japanese characters most people do not distinguish so vigorously. For example, Sai of Saitoh, the tenth most frequent Japanese family name, is represented by 4 similar but different characters, which is distinguished by people named Saitoh but not distinguished by most others, which means phishing is unavoidable. That is, RFC4290 covering such Japanese characters is not technical from the beginning. and RFC 5992 for a policy mechanism designed to resolve the problem you raised in your example above. It is nothing more than a political statement, because there is no reasonable way to use tables in Appendix A. You will notice that the .com domain does not appear on the Mozilla IDN whitelist. Which means IDN can not be Internationalized at all and selling IDN is nothing more than a fraud. Masataka Ohta
Re: Dear RIPE: Please don't encourage phishing
On Sun, 12 Feb 2012 10:25:53 +0900, Masataka Ohta said: valdis.kletni...@vt.edu wrote: (The actual policy for the .UA registrar is more subtle. They *do* in fact allow U+0441 Cyrillic Small Letter ES which is visually a C to us Latin-glyph users. However, they require at least one character that's visually unique to Cyrillic in the domain name. Unique within what? Is a Cyrillic character, which looks like Latin E with diaeresis, a unique Cyrillic character? Is CYRILLIC CAPITAL LETTER GHE, which looks like Greek Gamma, a unique Cyrillic character? Is Greek Gamma, which looks like CYRILLIC CAPITAL LETTER GHE, a unique Greek character? Doesn't actually matter, because the .ua registry isn't allowing Greek Gamma or Latin-E-with-diaresis, in domain names. So you can't find a domain bankname-containing-ghe.ua and spoof it with bankname-containing-gamma.ua. I suppose you *could* find a 'greek-bankame-containing-gamma-and-only-chars-spoofable-in-cyrillic.gr' and create a 'bankname-containing-ghe-and-cyrillic.ua'. But quite frankly, turning off IDN doesn't fix that problem - greekbank.gr is spoofable by greekbank.ua and greekbank.com. We *already* have companies that will register 'foobar.com', 'foobar.net', 'foobar.org' and every other variant they can to prevent squatters in the other TLDs. They also don't allow mixed Cyrillic/Latin scripts in one domain name). Is a Russian word containing no unique (unique to ASCII) Cyrillic characters encoded as Latin character using ASCII, even though a Russian word containing unique (whatever unique means) Cyrillic character encoded as Cyrillic characters? No, it means you get to pick 'all-latin-chars.ua' or 'all-cyrillic-chars.ua'. And due to the requirement that a cyrillic name have a special char in it, you can's spoof an all-latin-chars.ua name. The only protection is to disable IDN. You also have to ban the use of numbers in domain names, because you need to prevent people being tricked by micros0ft.com and m1crosoft.com. Good luck on that. Oh, and 'i' and 'l' need to be banned as well, because a san-serif uppercase I looks a lot like a san-serif lowercase l. (In fact, in the font I'm currently using, the two are pixel-identical). I don't see anybody calling for the banning of 'i' and 'l' in domain names due to that. It's interesting how some people are insisting that the IDN code has to be *perfect* and make it *totally* impossible to create a phishable spoof of a domain - but aren't willing to take the extra step of banning the characters in the Latin Ascii charset that are spoofable. pgpLQfSXhjYw1.pgp Description: PGP signature
Re: Dear RIPE: Please don't encourage phishing
valdis.kletni...@vt.edu wrote: (and that despite the fact that it's perfectly well possible to write -any language out there- in the first 7 bits of ascii) Yes, any language including FORTRAN. And it's *equally* possible to write any language out there using a 7-bit encoding of the Cyrillic character set. Yes, any language including FORTRAN, because KOI-7, a 7-bit encoding of the Cyrillic character set, includes all the uppercase Latin characters. Oh, that would suck because Cyrillic isn't very similar to your native character set? Welcome to the way the vast majority of the world feels. See how the vast majority of the world feels. http://en.wikipedia.org/wiki/ISO/IEC_646 Since the portion of ISO/IEC 646 shared by all countries (the invariant set) specified only those letters used in the ISO basic Latin alphabet, Masataka Ohta
Re: Dear RIPE: Please don't encourage phishing
On Sat, Feb 11, 2012 at 11:13 PM, valdis.kletni...@vt.edu wrote: On Sun, 12 Feb 2012 10:25:53 +0900, Masataka Ohta said: valdis.kletni...@vt.edu wrote: It's interesting how some people are insisting that the IDN code has to be *perfect* and make it *totally* impossible to create a phishable spoof of a domain - but aren't willing to take the extra step of banning the characters in the Latin Ascii charset that are spoofable. [snip] There aren't really any characters in the latin ASCII charset that are so spoofable. 0 and O, |, I, l, and 1 do come close, depending on the font chosen. This is easily avoidable, because there are so few spoofable characters, you can easily just avoid using a spoofable one in your domain name, or register all variants. These are minor compared to the issues you get expanding the possible URL character sets to all unicode, through IDN support. The extended character sets available under IDN provide a large number of spoofable characters from various different charsets that are indistinguishable. For phishing to not be a serious risk, IDN implementations have to have some kind of security policy. A start would be: don't display IDN characters, unless they are within a character set the user is expected to be familiar with. For example, for a web browser that ships in North America, only the locally relevant IDN character sets should be enabled by default. If you should want to see IDN characters from Cyrillic character sets, or Chinese Ideographs, there should be a requirement you very deliberately install support for specific character set you need. Or install a localized browser that has the specific IDN charsets allowed by policy. There should also be a browser-enforced policy that different charsets cannot be mixed in the same domain name. Then any increase in phishing risk is limited to regions / language localized browsers where the character set with spoofable characters makes sense and is in common use. Ideally there should be a table of every pair of characters that look somewhat similar to each other in every character set, and every registrar ensuring appearance uniqueness for every new domain registration. -- -JH
Re: Dear RIPE: Please don't encourage phishing
On 2/11/12 19:34 , Sven Olaf Kamphuis wrote: yes, domain names that cannot be typed in with any keyboard/charset on any computer out there, excellent idea, devide and conquerer, i wonder who came up with that idiotic plan again, probably the ITU or one of their infiltrants in icann. If it's worth shoveling blame indiscriminately it's worth informing yourself a little about the timeline and the actors involved. http://en.wikipedia.org/wiki/Internationalized_domain_name how about, we simply don't code any software or adjust any platforms to support it, if nobody uses it, no problem :P (or just deliberately break it as its nothing more than a devide and conquerer attempt of the UN anyway ;) On Sun, 12 Feb 2012, Neil Harris wrote: On 12/02/12 00:09, Masataka Ohta wrote: Neil Harris wrote: Techniques to deal with this sort of spoofing already exist: see http://www.mozilla.org/projects/security/tld-idn-policy-list.html It does not make sense that .COM allows Cyrillic characters: http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html i script of a domain name is Cyrillic. Domain names do not have such property as script. Is the following domain name: CCC.COM Latin or Cyrillic? for one quite effective approach. The only reasonable thing to do is to disable so called IDN. Masataka Ohta PS Isn't it obvious from the page you referred that IDN is not internationalization but an uncoordinated collection of poor localizations? I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN safer, given that it already exists. Lots of people have thought about this quite carefully. See RFC 4290 for a technical discussion of the thinking behind this policy, and RFC 5992 for a policy mechanism designed to resolve the problem you raised in your example above. You will notice that the .com domain does not appear on the Mozilla IDN whitelist. -- N.
Dear RIPE: Please don't encourage phishing
I received the enclosed note, apparently from RIPE (and the headers check out). Why are you sending messages with clickable objects that I'm supposed to use to change my password? --- From: ripe_dbannou...@ripe.net Subject: Advisory notice on passwords in the RIPE Database Date: February 9, 2012 1:16:15 PM EST To: [Apologies for duplicate e-mails] Dear Colleagues, We are contacting you with some advice on the passwords used in the RIPE Database. There is no immediate concern and this notice is only advisory. At the request of the RIPE community, the RIPE NCC recently deployed an MD5 password hash change. Before this change was implemented, there was a lot of discussion on the Database Working Group mailing list about the vulnerabilities of MD5 passwords with public hashes. The hashes can now only be seen by the user of the MNTNER object. As a precaution, now that the hashes are hidden, we strongly recommend that you change all MD5 passwords used by your MNTNER objects in the RIPE Database at your earliest convenience. When choosing new passwords, make them as strong as possible. To make it easier for you to change your password(s) we have improved Webupdates. On the modify page there is an extra button after the auth: attribute field. Click this button for a pop up window that will encrypt a password and enter it directly into the auth: field. Webupdates: https://apps.db.ripe.net/webupdates/search.html There is a RIPE Labs article explaining details of the security changes and the new process to modify a MNTNER object in the RIPE Database: https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database We are sending you this email because this address is referenced in the MNTNER objects in the RIPE Database listed below. If you have any concerns about your passwords or need further advice please contact our Customer Services team at ripe-...@ripe.net. (You cannot reply to this email.) Regards, Denis Walker Business Analyst RIPE NCC Database Group Referencing MNTNER objects in the RIPE Database: maint-rgnet
Re: Dear RIPE: Please don't encourage phishing
So because of phishing, nobody should send messages with URLs in them? On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin s...@cs.columbia.edu wrote: I received the enclosed note, apparently from RIPE (and the headers check out). Why are you sending messages with clickable objects that I'm supposed to use to change my password? --- From: ripe_dbannou...@ripe.net Subject: Advisory notice on passwords in the RIPE Database Date: February 9, 2012 1:16:15 PM EST To: [Apologies for duplicate e-mails] Dear Colleagues, We are contacting you with some advice on the passwords used in the RIPE Database. There is no immediate concern and this notice is only advisory. At the request of the RIPE community, the RIPE NCC recently deployed an MD5 password hash change. Before this change was implemented, there was a lot of discussion on the Database Working Group mailing list about the vulnerabilities of MD5 passwords with public hashes. The hashes can now only be seen by the user of the MNTNER object. As a precaution, now that the hashes are hidden, we strongly recommend that you change all MD5 passwords used by your MNTNER objects in the RIPE Database at your earliest convenience. When choosing new passwords, make them as strong as possible. To make it easier for you to change your password(s) we have improved Webupdates. On the modify page there is an extra button after the auth: attribute field. Click this button for a pop up window that will encrypt a password and enter it directly into the auth: field. Webupdates: https://apps.db.ripe.net/webupdates/search.html There is a RIPE Labs article explaining details of the security changes and the new process to modify a MNTNER object in the RIPE Database: https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database We are sending you this email because this address is referenced in the MNTNER objects in the RIPE Database listed below. If you have any concerns about your passwords or need further advice please contact our Customer Services team at ripe-...@ripe.net. (You cannot reply to this email.) Regards, Denis Walker Business Analyst RIPE NCC Database Group Referencing MNTNER objects in the RIPE Database: maint-rgnet
Re: Dear RIPE: Please don't encourage phishing
If they're intended as a path to log in with a typed password, that's correct. Sad, but correct. On Feb 10, 2012, at 12:18 PM, Richard Barnes wrote: So because of phishing, nobody should send messages with URLs in them? On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin s...@cs.columbia.edu wrote: I received the enclosed note, apparently from RIPE (and the headers check out). Why are you sending messages with clickable objects that I'm supposed to use to change my password? --- From: ripe_dbannou...@ripe.net Subject: Advisory notice on passwords in the RIPE Database Date: February 9, 2012 1:16:15 PM EST To: [Apologies for duplicate e-mails] Dear Colleagues, We are contacting you with some advice on the passwords used in the RIPE Database. There is no immediate concern and this notice is only advisory. At the request of the RIPE community, the RIPE NCC recently deployed an MD5 password hash change. Before this change was implemented, there was a lot of discussion on the Database Working Group mailing list about the vulnerabilities of MD5 passwords with public hashes. The hashes can now only be seen by the user of the MNTNER object. As a precaution, now that the hashes are hidden, we strongly recommend that you change all MD5 passwords used by your MNTNER objects in the RIPE Database at your earliest convenience. When choosing new passwords, make them as strong as possible. To make it easier for you to change your password(s) we have improved Webupdates. On the modify page there is an extra button after the auth: attribute field. Click this button for a pop up window that will encrypt a password and enter it directly into the auth: field. Webupdates: https://apps.db.ripe.net/webupdates/search.html There is a RIPE Labs article explaining details of the security changes and the new process to modify a MNTNER object in the RIPE Database: https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database We are sending you this email because this address is referenced in the MNTNER objects in the RIPE Database listed below. If you have any concerns about your passwords or need further advice please contact our Customer Services team at ripe-...@ripe.net. (You cannot reply to this email.) Regards, Denis Walker Business Analyst RIPE NCC Database Group Referencing MNTNER objects in the RIPE Database: maint-rgnet --Steve Bellovin, https://www.cs.columbia.edu/~smb
Re: Dear RIPE: Please don't encourage phishing
So because of phishing, nobody should send messages with URLs in them? more and more these days, i have taken to not clicking the update messages, but going to the web site manyually to get it. wy to much phishing, and it is getting subtle and good. randy
Re: Dear RIPE: Please don't encourage phishing
On Feb 10, 2012, at 9:29 AM, Randy Bush wrote: So because of phishing, nobody should send messages with URLs in them? more and more these days, i have taken to not clicking the update messages, but going to the web site manyually to get it. wy to much phishing, and it is getting subtle and good. Concur. It seems as if they're no longer written by non-native English speakers, which goes a long way towards making them more insidious. While still perfectly intelligible, most folks who use English as a second language don't speak in the same voice as, say, Wells Fargo corporate communications. -- Corey signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Dear RIPE: Please don't encourage phishing
On Fri, Feb 10, 2012 at 12:18 PM, Richard Barnes richard.bar...@gmail.com wrote: On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin s...@cs.columbia.edu wrote: I received the enclosed note, apparently from RIPE (and the headers check out). Why are you sending messages with clickable objects that I'm supposed to use to change my password? [...] attribute field. Click this button for a pop up window that will encrypt a password and enter it directly into the auth: field. So because of phishing, nobody should send messages with URLs in them? url != clickable object No problem with URLs in email. No problem with clickable objects that are unrelated to security. Minor problem with URLs that lead to changing passwords but can be mitigated by making the URL very plain and easy to read, even by a non-techie. They'll at least have to see the thing, even if the mail client automagically makes it clickable. Big problem with clickable objects which lead to PII (personally identifiable information) or passwords. That's how phishing works -- a disguised url that you either see at all or whose incorrect nature slips right past your brain. The only known working solution is to train folks to *never* click security-related URLs in email. Copy and paste only, and only if they're readable and read right. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Dear RIPE: Please don't encourage phishing
It seems as if they're no longer written by non-native English speakers, which goes a long way towards making them more insidious. While still perfectly intelligible, most folks who use English as a second language don't speak in the same voice as, say, Wells Fargo corporate communications. Most people who use English as their milk language don't speak in the same voice as Wells Fargo Corporate Communications. :-) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: Dear RIPE: Please don't encourage phishing
In a message written on Fri, Feb 10, 2012 at 09:29:30AM -0800, Randy Bush wrote: more and more these days, i have taken to not clicking the update messages, but going to the web site manyually to get it. wy to much phishing, and it is getting subtle and good. We know how to sign and encrypt web sites. We know how to sign and encrypt e-mail. We even know how to compare keys between the web site and e-mail via a variety of mechanisms. We know how to sign DNS. Remind me again why we live in this sad word Randy (correcly) described? There's no reason my mail client shouldn't validate the signed e-mail came from the same entity as the signed web site I'd previously logged into, and give me a green light that the link actually points to said same web site with the same key. It should be transparent, and secure for the user. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp2Levs78GW0.pgp Description: PGP signature
Re: Dear RIPE: Please don't encourage phishing
The line gets crossed when you send an unsolicited message that includes a clickable change password link, that a phisher would find interesting to emulate. After the fact, if a phisher gets one of your customers to click on such a link, you'd like to tell them them in response, or preemptively, that your company never asks for sensitive information via email. With good policies in place, the customer should not be receiving clickable links via email that ask them for a password, except for a scenario where they've actively generated that email in response to an I forgot my password link on a website. On 02/10/12 09:18 -0800, Richard Barnes wrote: So because of phishing, nobody should send messages with URLs in them? On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin s...@cs.columbia.edu wrote: I received the enclosed note, apparently from RIPE (and the headers check out). Why are you sending messages with clickable objects that I'm supposed to use to change my password? --- From: ripe_dbannou...@ripe.net Subject: Advisory notice on passwords in the RIPE Database Date: February 9, 2012 1:16:15 PM EST To: [Apologies for duplicate e-mails] Dear Colleagues, We are contacting you with some advice on the passwords used in the RIPE Database. There is no immediate concern and this notice is only advisory. At the request of the RIPE community, the RIPE NCC recently deployed an MD5 password hash change. Before this change was implemented, there was a lot of discussion on the Database Working Group mailing list about the vulnerabilities of MD5 passwords with public hashes. The hashes can now only be seen by the user of the MNTNER object. As a precaution, now that the hashes are hidden, we strongly recommend that you change all MD5 passwords used by your MNTNER objects in the RIPE Database at your earliest convenience. When choosing new passwords, make them as strong as possible. To make it easier for you to change your password(s) we have improved Webupdates. On the modify page there is an extra button after the auth: attribute field. Click this button for a pop up window that will encrypt a password and enter it directly into the auth: field. Webupdates: https://apps.db.ripe.net/webupdates/search.html There is a RIPE Labs article explaining details of the security changes and the new process to modify a MNTNER object in the RIPE Database: https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database We are sending you this email because this address is referenced in the MNTNER objects in the RIPE Database listed below. If you have any concerns about your passwords or need further advice please contact our Customer Services team at ripe-...@ripe.net. (You cannot reply to this email.) Regards, Denis Walker Business Analyst RIPE NCC Database Group Referencing MNTNER objects in the RIPE Database: maint-rgnet -- Dan White BTC Broadband Ph 918.366.0248 (direct) main: (918)366-8000 Fax 918.366.6610email: dwh...@olp.net http://www.btcbroadband.com
PGP, S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage phishing)
On 2012-02-10 18:37 , Leo Bicknell wrote: [..] There's no reason my mail client shouldn't validate the signed e-mail came from the same entity as the signed web site I'd previously logged into, and give me a green light that the link actually points to said same web site with the same key. It should be transparent, and secure for the user. That is a rather nice idea. Most people, especially the common ones, do not use PGP or heck even S/MIME though and only when one is included in the web-of-trust can one actually verify these. Of course when that is done, one should be able to match up email address and website URL quite easily and your trick will work, at least one can then state: the sender, who is verified by trust, is pointing to his/her own website. The problem still lies in the issue that most people, even on this very list, do not use PGP or S/MIME. (and that there are two standards does not help much there either ;) Greets, Jeroen
Re: Dear RIPE: Please don't encourage phishing
There's no reason my mail client shouldn't validate the signed e-mail came from the same entity as the signed web site I'd previously logged into, and give me a green light that the link actually points to said same web site with the same key. It should be transparent, and secure for the user. my paranoid side is not comfortable with the certs that come for free with my browser. see the ietf dane wg. randy
Re: Dear RIPE: Please don't encourage phishing
While still perfectly intelligible, most folks who use English as a second language don't speak in the same voice as, say, Wells Fargo corporate communications. yep. if it's intelligible, it can't really be from wells fargo corp comms. randy
Re: Dear RIPE: Please don't encourage phishing
On Fri, 10 Feb 2012 09:37:01 PST, Leo Bicknell said: We know how to sign and encrypt web sites. We know how to sign and encrypt e-mail. We even know how to compare keys between the web site and e-mail via a variety of mechanisms. We know how to sign DNS. Remind me again why we live in this sad word Randy (correcly) described? Obi-Wan Kenobi: (shocked) How could this have happened?? We're supposed to be smarter than this. Anakin Skywalker: Apparently not. pgp0ByzvhMKTR.pgp Description: PGP signature
Re: Dear RIPE: Please don't encourage phishing
- Original Message - From: William Herrin b...@herrin.us Big problem with clickable objects which lead to PII (personally identifiable information) or passwords. That's how phishing works -- a disguised url that you either see at all or whose incorrect nature slips right past your brain. The only known working solution is to train folks to *never* click security-related URLs in email. Copy and paste only, and only if they're readable and read right. And right there, Bill, is the part we so rarely understand, and it kills us: Even lots of *technical* people just don't understand what a security- related URL *is*, and there's almost always no way to teach them. So it's necessary to throw the baby out with the bathwater, and tell them never to click on a link... MUA's that support HTML at all, much less they fail to tell the user when a text URL doesn't match the actual link, are the underlying culprits here... Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: PGP, S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage phishing)
In a message written on Fri, Feb 10, 2012 at 06:46:43PM +0100, Jeroen Massar wrote: The problem still lies in the issue that most people, even on this very list, do not use PGP or S/MIME. (and that there are two standards does not help much there either ;) The problem space is still certificate management. I bet (nearly) everyone on the list uses an e-mail client that can decode S/MIME. mutt, pine, Outlook, OSX Mail, gmail, they all do it. We all have browsers that do SSL. OSX at least has a central certificate store (Keychain), although it's not up to the tasks of the world I wish to have. Other OS's provide no central store, so each application maintains their own key store. We have a very real problem of pre-loading the key store, for instance root certificate trust for X.509 certificates. We need a central certificate store on every platform, easy, secure ways to transfer/sync it (to say, moble devices), and a bit of UI goo. Imagine a capability as simple as being able to add a description to a cert in your key store. I should be able to download my bank's cert, verify it (call and check finger print, check a trusted third party, web of trust, probably multiple ways, automated, would be best) and then tag it Leo's Bank. When I get e-mail from it, or go to it with my web browser it should now say Leo's Bank in all of my software, telling me not only do I have the little padlock, but it's the certificate I personally validated. When I click on a link in e-mail it should pass the URL AND KEY to the next program (e.g. my browser). My browser can then silently load if they are the same, or give me a big pop up The person who sent this e-mail is different from the person who runs this web site. It's all UI. No new technology, protocols, encryption formats or other things are needed. It's making end user software act in a responsible way. Of course I'd also prefer my bank allowed me to provide my certificate to them, and they crypto authenticated me (perhaps in addition to passwords and pins). This should all be two-way. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpSWz9uFJWsW.pgp Description: PGP signature
Re: Dear RIPE: Please don't encourage phishing
Leo, This has nothing to do with the competency of the folks on the nanog list. It's a safe rule in general. Why? Because the stupid on the Internet outnumbers all of us. It's just easier to not send clickable links then it is to have the call center lit up because your users are getting hijacked. -Hammer- I was a normal American nerd -Jack Herer On 2/10/2012 11:51 AM, valdis.kletni...@vt.edu wrote: On Fri, 10 Feb 2012 09:37:01 PST, Leo Bicknell said: We know how to sign and encrypt web sites. We know how to sign and encrypt e-mail. We even know how to compare keys between the web site and e-mail via a variety of mechanisms. We know how to sign DNS. Remind me again why we live in this sad word Randy (correcly) described? Obi-Wan Kenobi: (shocked) How could this have happened?? We're supposed to be smarter than this. Anakin Skywalker: Apparently not.
Re: Dear RIPE: Please don't encourage phishing
We know how to sign and encrypt e-mail. there is a public key distribution and trust problem We know how to sign DNS. not very reliably yet randy
Re: Dear RIPE: Please don't encourage phishing
On Fri, Feb 10, 2012 at 1:00 PM, Jay Ashworth j...@baylink.com wrote: From: William Herrin b...@herrin.us Big problem with clickable objects which lead to PII (personally identifiable information) or passwords. That's how phishing works -- a disguised url that you either see at all or whose incorrect nature slips right past your brain. The only known working solution is to train folks to *never* click security-related URLs in email. Copy and paste only, and only if they're readable and read right. And right there, Bill, is the part we so rarely understand, and it kills us: Even lots of *technical* people just don't understand what a security- related URL *is*, and there's almost always no way to teach them. So it's necessary to throw the baby out with the bathwater, and tell them never to click on a link... Hi Jay, And if we could just train people to never send or accept email attachments, we could get rid of email-spread viruses. Not gonna happen -- the functionality is too useful. Security isn't just about what you can train someone to do... it's also about what you can convince them to do when you're not standing behind them watching -- the instructions that they're willing to internalize. You can't convince people never to click links in an email. It's too useful. You might, however, be able to convince the average person that if a link they clicked from an email asks for a password or asks for any personal information then the message was probably from an impersonator trying to steal the user's identity and they should report it immediately lest they be victimized. Regards, Bill -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Dear RIPE: Please don't encourage phishing
Original Message - From: William Herrin b...@herrin.us And if we could just train people to never send or accept email attachments, we could get rid of email-spread viruses. Not gonna happen -- the functionality is too useful. Security isn't just about what you can train someone to do... it's also about what you can convince them to do when you're not standing behind them watching -- the instructions that they're willing to internalize. You can't convince people never to click links in an email. It's too useful. I did admit that it was throwing the baby out with the bathwater. Being able to drive across someone's golf course to get to work is convenient for me as well, but I'm still forbidden to do it. This is a tragedy of the commons problem -- since the biggest target for zombies on PCs is probably spambots ... You might, however, be able to convince the average person that if a link they clicked from an email asks for a password or asks for any personal information then the message was probably from an impersonator trying to steal the user's identity and they should report it immediately lest they be victimized. Yup. Just like Steve just did in the posting that started this. Y'know: the thing that only looked like a phish. Cheers, -- jr 'and don't even get me started on e-cards' a -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: PGP, S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage phishing)
On Feb 10, 12:01 pm, Leo Bicknell bickn...@ufp.org wrote: OSX at least has a central certificate store (Keychain), although it's not up to the tasks of the world I wish to have. Other OS's provide no central store, so each application maintains their own key store. Windows has had its own centralized certificate store and APIs since NT 4.0's release in 1996. Firefox and Java are the only mainstream software can think of on Windows that insists on using their own certificate stores (really just a pile of world-readable files) instead of the built-in per- machine+per-user certificate store on Windows.
Re: Dear RIPE: Please don't encourage phishing
On 10/02/12 10:00 AM, Jay Ashworth wrote: Even lots of*technical* people just don't understand what a security- related URL*is*, and there's almost always no way to teach them. Freakonomics recently aired a story about the problem of getting Doctors to follow hand hygiene rules and wash their hands as frequently as they are supposed to (upon entering and leaving each patient's room) to avoid spreading disease. One of the biggest problems with changing behavior with doctors (and with technical people) is that the smarter people are, the more they chafe at being told they aren't doing things the correct way. The most effective step they took to counter-act the hand-washing problems was using a screen-saver on all the public terminals, showing the consequences of not-washing - an image of a petri dish showing the bacteria results from a hand-print of a doctor's hand. http://www.freakonomics.com/2012/01/24/how-to-get-doctors-to-wash-their-hands-visual-edition/ If you wanted to have a similar effect at $workplace, try a similar visual (e.g. a mockup of 2 screenshots, first clicking on a link in email then typing in a password on a webpage with a phishing URL (with a typo)) as the screen saver on all company computers; as the first slide in all in-house ppt presentations; on the wall at all card-lock entry doors, etc. jc
Re: Dear RIPE: Please don't encourage phishing
On Fri, Feb 10, 2012 at 12:28:22PM -0500, Steven Bellovin wrote: If they're intended as a path to log in with a typed password, that's correct. Sad, but correct. I agree. Training your customers/clients to click on URLs in email messages is precisely equivalent to training them to be phish victims. I teach people to (carefully!) bookmark the sites that they use which require passwords, and to always use those bookmarks -- that is, *never* to use the links in any mail message or on any web page. (Of course, an attacker in control of their browser could manipulate the bookmarks, but there is little reason for an attacker who's already gotten that far to do so.) ---rsk
Re: Dear RIPE: Please don't encourage phishing
- Original Message - From: JC Dill jcdill.li...@gmail.com If you wanted to have a similar effect at $workplace, try a similar visual (e.g. a mockup of 2 screenshots, first clicking on a link in email then typing in a password on a webpage with a phishing URL (with a typo)) as the screen saver on all company computers; as the first slide in all in-house ppt presentations; on the wall at all card-lock entry doors, etc. The problem is you need the 3rd visual... a picture of an abandoned factory, with the doors flapping in the wind, bceause the company went out of business because someone got spearphished. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: Dear RIPE: Please don't encourage phishing
On Fri, 10 Feb 2012 14:44:29 EST, Jay Ashworth said: a picture of an abandoned factory, with the doors flapping in the wind, bceause the company went out of business because someone got spearphished. Has this ever been spotted in the wild? Serious question - most of the well-publicized spearphishing attacks lately the victim company is still around. pgpIR7m8TZsHU.pgp Description: PGP signature
Re: Dear RIPE: Please don't encourage phishing
- Original Message - From: Valdis Kletnieks valdis.kletni...@vt.edu On Fri, 10 Feb 2012 14:44:29 EST, Jay Ashworth said: a picture of an abandoned factory, with the doors flapping in the wind, bceause the company went out of business because someone got spearphished. Has this ever been spotted in the wild? Serious question - most of the well-publicized spearphishing attacks lately the victim company is still around. I don't know that we would have any way to know that a demised company went down due to a spearphish... but yes, I was exaggerating. Cheers, -- jr 'hyperbole and a half!' a -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: PGP, S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage phishing)
In a message written on Fri, Feb 10, 2012 at 11:11:18AM -0800, Ryan Malayter wrote: Windows has had its own centralized certificate store and APIs since NT 4.0's release in 1996. You are correct that I maligned Windows in a way I shouldn't have done. Indeed, I've been very impressed with the software they make to manage certificates in the enterprise before, making it quite easy to roll out per user certificates for VPN's or E-Mail and dump it in the certificate store. I think my view was incorrectly colored by the fact that the API is not used by many programs (open source in particular) where as OSX has had some traction with the Keychain. It would be nice to get something approximating a cross platform API, even if all that means is the ability to do the same operations on all major platforms. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpdkCr8BT51C.pgp Description: PGP signature
Re: Dear RIPE: Please don't encourage phishing
On Feb 10, 2012, at 12:29 30PM, Randy Bush wrote: So because of phishing, nobody should send messages with URLs in them? more and more these days, i have taken to not clicking the update messages, but going to the web site manyually to get it. Yup -- I wrote about that a while back (https://www.cs.columbia.edu/~smb/blog/2011-10/2011-10-02.html) wy to much phishing, and it is getting subtle and good. What's the line -- I know I'm paranoid, but am I paranoid enough? --Steve Bellovin, https://www.cs.columbia.edu/~smb
Re: Dear RIPE: Please don't encourage phishing
On Feb 10, 2012, at 12:37 01PM, Leo Bicknell wrote: In a message written on Fri, Feb 10, 2012 at 09:29:30AM -0800, Randy Bush wrote: more and more these days, i have taken to not clicking the update messages, but going to the web site manyually to get it. wy to much phishing, and it is getting subtle and good. We know how to sign and encrypt web sites. We know how to sign and encrypt e-mail. We even know how to compare keys between the web site and e-mail via a variety of mechanisms. We know how to sign DNS. Remind me again why we live in this sad word Randy (correcly) described? There's no reason my mail client shouldn't validate the signed e-mail came from the same entity as the signed web site I'd previously logged into, and give me a green light that the link actually points to said same web site with the same key. It should be transparent, and secure for the user. The really hard parts are (a) getting the users to pay attention to the validation state (or, more precisely, the lack thereof on a phishing email, and (b) get them to do it *correctly*. Some of the browser password managers have protection against phishing as a very useful side-effect: if they don't recognize the URL, they won't pony up the correct login and password. That's much better than hoping that someone notices the absence of a little icon that means this was signed. The correctly part has to do with the PKI mess. --Steve Bellovin, https://www.cs.columbia.edu/~smb
Re: Dear RIPE: Please don't encourage phishing
- Original Message - From: Steven Bellovin s...@cs.columbia.edu What's the line -- I know I'm paranoid, but am I paranoid enough? Just because people say you're paranoid, that doesn't mean that there *aren't* people out to get you. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: PGP, S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage phishing)
On Fri, Feb 10, 2012 at 1:01 PM, Leo Bicknell bickn...@ufp.org wrote: In a message written on Fri, Feb 10, 2012 at 06:46:43PM +0100, Jeroen Massar wrote: The problem still lies in the issue that most people, even on this very list, do not use PGP or S/MIME. (and that there are two standards does not help much there either ;) The problem space is still certificate management. The problem space is that most folks won't catch the difference between an email and link from ripe.net, ripe.org and ripe.ca. The game is lost long before a purely technical version of validating the message source becomes an issue. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: PGP, S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage phishing)
In a message written on Fri, Feb 10, 2012 at 04:15:19PM -0500, William Herrin wrote: The problem space is that most folks won't catch the difference between an email and link from ripe.net, ripe.org and ripe.ca. The game is lost long before a purely technical version of validating the message source becomes an issue. You're reply is along the lines of what several other folks have told me privately, and I think they all miss the mark of where I am going with my suggestion. Hypothetically, I get an e-mail from ripe.ca, which uses some trick (perhaps as simple as HTML text and link that go to different places) to visually show me ripe.net and actually sends me to ripe.org. Let's also assume I have a ripe.net account and have been to that web site before. The software can do a pile of things that make life better for the user: 1) When I reach ripe.org (from the phish above), my browser can say: This is an SSL web site asking for a login and password, and yet, you've never been here before. Maybe you would prefer to register, or leave if you came here incorrectly. That's all client side UI, and would make even novice users stop and think about what happened. 2) Let's say the e-mail was signed, by ripe.ca, the original sender. When my e-mail client passes the URL to my browser, it can also pass the details of the ripe.ca key. My browser can then say You got an e-mail from Key ABC, but went to a web site run by XYZ, are you sure this is what you want to do? Of course if everything matches, it can be silent. Specifically I am NOT suggesting to ever trust a root-CA, or the details in a certificate. Indeed, browsers could ship with no certificates what so ever in my scheme. The key is comparing multiple sources of information. Most folks might not know the difference between ripe.ca and ripe.net. The existing CA scheme may allow both of them to get the common name Réseaux IP Européens, confusing even the technical who look close. But it's trivial for the software to say Cert in E-mail != Cert in Web, or even that they don't have a common branch in the tree (in a large org they may have the same parent, for instance). As I've also said, a good UI feature would be the ability to add a description to a cert locally. Once I'm sure my banks web site is legit I should be able to add Leo's Bank in the cert store locally. Now when my web browser or e-mail client use that cert to validate a message they can display Leo's Bank next to it. I can easily look for that and know I went back to the same place. I click on a link in my e-mail and see no description, I know something went wrong. Does my scheme stop all phishing. Heck no. If we wait for a perfect solution we'll never have any solution. Look at NANOG. Bandy Rush is here somewhere. It's why many years ago I set my mailer to PGP all e-mail to NANOG. See an e-mail from me not signed, don't trust it. Does that stop all impersonation on NANOG. Heck no, but if we all did it, and subscribed to the web of trust, it would all but stop it. Users hate encryption and ignore the warnings not because they don't want to be secure, or are idiots. They do it because the darn software is broken, confusing, and has the worst UI's ever invented. If the industry fixes it, encryption will be much more widespread. Small steps, like banks allowing users to upload an cert to their account profile, and then communicate via two-way authenticated e-mail would go a long way to traning the user community how this should work. End user ISP's (cable, DSL) issuing e-mail certs automatically and installing them as part of their install package would be a quantum leap forward. It's not hard, people just don't do it. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpUbeyXKuQ3e.pgp Description: PGP signature
Re: Dear RIPE: Please don't encourage phishing
On Fri, Feb 10, 2012 at 09:29:30AM -0800, Randy Bush wrote: So because of phishing, nobody should send messages with URLs in them? more and more these days, i have taken to not clicking the update messages, but going to the web site manyually to get it. Web site? With the RIPE db one communicates using PGP email for data in and port 43 queries for data out. The web site is for signing up to RIPE meetings. Yes, RIPE NCC, I think that you put a lot of resources into new fancy guish junk, and tend to forget how things should be done, and some things -- the horror! -- are only possible to accomplish using the web site and some forgotten password. To me, that is much more annoying than the side projects that people are griping over. /rant wy to much phishing, and it is getting subtle and good. Indeed. -- Måns
Re: Dear RIPE: Please don't encourage phishing
On Fri, Feb 10, 2012 at 09:37:01AM -0800, Leo Bicknell wrote: Remind me again why we live in this sad word Randy (correcly) described? Because banks and many other institutions have prioritized all-singing, all-dancing, bloated, horribly-badly-marked-up HTML email with stationary and logos and pictures and web bugs far, FAR ahead of security, privacy, accessability, portability and other -ilities that I'm too lazy to enumerate just now. Besides: it's not like it's *their* accounts that will get hosed or *their* money that will get lost. Things like that only happen to the little people. See also this related note: http://www.mail-archive.com/infowarrior%40attrition.org/msg08436.html ---rsk
Re: Dear RIPE: Please don't encourage phishing
So it's necessary to throw the baby out with the bathwater, and tell them never to click on a link... That baby was ugly anyway brandon
Re: Dear RIPE: Please don't encourage phishing
There used to be the old programming benchmark of how large a program (in lines, as well as compiled bytes) it took to say Hello, world. The 21st century benchmark might now well be the size of a Hello, world e-mail. Or a web page with a similar statement. Jeff On 2/10/2012 6:46 PM, Rich Kulawiec wrote: On Fri, Feb 10, 2012 at 09:37:01AM -0800, Leo Bicknell wrote: Remind me again why we live in this sad word Randy (correcly) described? Because banks and many other institutions have prioritized all-singing, all-dancing, bloated, horribly-badly-marked-up HTML email with stationary and logos and pictures and web bugs far, FAR ahead of security, privacy, accessability, portability and other -ilities that I'm too lazy to enumerate just now. Besides: it's not like it's *their* accounts that will get hosed or *their* money that will get lost. Things like that only happen to the little people. See also this related note: http://www.mail-archive.com/infowarrior%40attrition.org/msg08436.html ---rsk
Re: Dear RIPE: Please don't encourage phishing
On 10 February 2012 16:09, Brandon Butterworth bran...@rd.bbc.co.uk wrote: So it's necessary to throw the baby out with the bathwater, and tell them never to click on a link... That baby was ugly anyway HAHAHA. My $0.02 on this issue is if the message is rich text I hover over the link and see where it actually sends me. If I don't know what that link is then I don't click it. Not sure how long it's going to take, probably a generation, for people to use some sense before mindlessly clicking on stuff. Banks and businesses that keep sensitive information in a protected area on the web for you should start sending messages in PLAIN TEXT so you have to copy/paste the link if you don't already have it book marked or don't want to type it. Sure it's not all flashy and there's no nice pictures and junk but if you get an email from your bank that's not in plain text and contains hyperlinks then you'll know it's fake before you even read it. --- Landon Stewart lstew...@superb.net mailtolstew...@superb.net Manager of Systems and Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more Ahead of the Rest: www.superb.net
Re: Dear RIPE: Please don't encourage phishing
My $0.02 on this issue is if the message is rich text I hover over the link and see where it actually sends me. idn has made this unsafe randy
Re: Dear RIPE: Please don't encourage phishing
Randy Bush wrote: My $0.02 on this issue is if the message is rich text I hover over the link and see where it actually sends me. idn has made this unsafe I pointed it out at IETF Munich in 1997 that with an example of: MICROSOFT.COM where 'C' of MICROSOFT is actually a Cyrillic character. But, people insisted working on useless IDN. Masataka Ohta
Re: Dear RIPE: Please don't encourage phishing
On Friday 10 February 2012 17:24, Landon Stewart wrote: My $0.02 on this issue is if the message is rich text I hover over the link and see where it actually sends me. If I don't know what that link is then I don't click it. Oh really? How about trying this Go to Google and search is my url safe: http://www.google.com/search?q=is+my+url+safe Now hover over that second link reportedly to faq.ssl.com and look at what your browser reports: http://faq.ssl.com/article.aspx?id=10068 Now look at the page code or copy/paste the URL somewhere else... Where does that link really go? http://www.google.com/url?q=http://faq.ssl.com/article.aspx%3Fid%3D10068sa=Uei=JcI1T_DRKJDXiAKauoSvCgved=0CBgQFjABusg=AFQjCNHSmrhtgWQczEe1j0LhdMdUW5x4LA So much for looking at what mouse-over shows Adrian
Re: Dear RIPE: Please don't encourage phishing
On Fri, 10 Feb 2012 16:24:11 PST, Landon Stewart said: I don't click it. Not sure how long it's going to take, probably a generation, for people to use some sense before mindlessly clicking on stuff. Only if you find a way to keep more idiots from being born. :) I don't think anybody wants to go there. At least not on this list. pgpU0oDEN1whk.pgp Description: PGP signature
RE: Dear RIPE: Please don't encourage phishing
Unfortunately that's not under control of those businesses. This plain text email you sent comes across with clickable mailto and http links in your signature in most modern email clients despite you having sent it in plain text. Helpful email program defaults won't force people to copy and paste the URL. They just create the hyperlink for people based on the pattern in the plain text message. It seems anything beginning with www or http(s):// will be converted to a clickable link out of convenience to the user. It's always that endless struggle of security vs. convenience... -Vinny -Original Message- From: Landon Stewart [mailto:lstew...@superb.net] Sent: Friday, February 10, 2012 7:24 PM To: Brandon Butterworth Cc: nanog@nanog.org Subject: Re: Dear RIPE: Please don't encourage phishing On 10 February 2012 16:09, Brandon Butterworth bran...@rd.bbc.co.uk wrote: So it's necessary to throw the baby out with the bathwater, and tell them never to click on a link... That baby was ugly anyway HAHAHA. My $0.02 on this issue is if the message is rich text I hover over the link and see where it actually sends me. If I don't know what that link is then I don't click it. Not sure how long it's going to take, probably a generation, for people to use some sense before mindlessly clicking on stuff. Banks and businesses that keep sensitive information in a protected area on the web for you should start sending messages in PLAIN TEXT so you have to copy/paste the link if you don't already have it book marked or don't want to type it. Sure it's not all flashy and there's no nice pictures and junk but if you get an email from your bank that's not in plain text and contains hyperlinks then you'll know it's fake before you even read it. --- Landon Stewart lstew...@superb.net mailtolstew...@superb.net Manager of Systems and Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more Ahead of the Rest: www.superb.net
