4 ms·

> The Internet is often described as a global network of networks, but if this network is truly global, why is it nearly impossible to have an email address in

> The Internet is often described as a global network of networks, but if this network is truly global, why is it nearly impossible to have an email address in a non-Latin script like Chinese, Arabic, or Hindi? This is not just true for applications, but also for the protocols, programming languages, routers, and pretty much every part of the Internet’s foundation. My big compliant about different languages in UTF-8 is homglyph attacks are easy-peasy to do. And the way non-ASCII (7 bit) character sets were done makes it nigh impossible to tell the difference between in-character set and outside of. There are hacky ways to show some homoglyph attacks, like punycode. Browsers do this... However using homoglyphs in Outlook works as intended and shows the look-alike characters without expansion - *but* the Outlook web access does expand the utf-8 chars to punycode. My recommendation being an infosec professional is to determine if you have a need for allowing punycode usernames or domainnames. If you don't, I suggest to ban them at your gateways. I also recognize the non-english centrism in doing this block. But when hese ranges of attacks are possible, I see this as yet another layer of defense against a really obnoxious attack type that is tremendously hard to discern.

josephcsible 5y ago
> If you don't, I suggest to ban them at your gateways. Can't you get the same security benefit, but without the drawback of being totally unable to reach such sites, just by disabling network.IDN_show_punycode in about:config (or some equivalent if you're not using Firefox)?
- noasaservice 5y ago
  If the browsers were the only thing affected, you'd be completely right. But the truth is that browsers are only a part of the issue here. We have to deal with: WWW browsers (firefox, chrome, edge, ie, brave, "browser" etc) email clients (LOTS) Signal Twitter Discord Google hangouts Telegram FB messenger And many more. And most of those don't have disambiguation settings like your example with firefox does. And all of them should be guarded against, as they have the same failure modes of "being sent link to log into $fake_service and looking completely real and getting hacked". I still maintain, since unicode provides no protections against homoglyphs, that the only real answer here is to firstly expand them to punycode, and secondarily to remove all homoglyph text.
- thaumasiotes 5y ago
  Well, there are two common attack types based on punycode. Type 1 is that you stick a homograph in there and hope it gets rendered and the victim never notices the difference. Type 2 is that you create a punycode URL which makes no sense by any standard, but which looks like xn--something-microsoft.com, and then you hope the punycode doesn't get rendered and your victim only notices the part where it ends with microsoft.com .
  - josephcsible 5y ago
    For type 2, doesn't that attack work just as well even if it doesn't start with xn--?
    - thaumasiotes 5y ago
      Yes. But the fact that people try to do this with punycode URLs is relevant when you're deciding whether or not to block all punycode URLs. It adds a minor benefit to the "block" column.
ben_w 5y ago
> There are hacky ways to show some homoglyph attacks, like punycode. Been thinking about this recently. Is there a risk when?: • User has a preferred character set determined by preferred language (many people will have only one preferred character set even with multiple languages). • Display all domain names, which are written in that character set, using that character set. For example, Αθήνα.ελ for monolingual Greek speakers. • Display all other domain names — if even one character is outside that character set — in whatever other fallback mechanism you’re already using. My preference here would be to invert the colour scheme (background colour becomes foreground and vice versa) for each out-of-charset character, partly to draw explicit attention to homoglyphs, partly because it’s least invasive for most likely domains, but mainly because the fallback part is what I’ve put least mental effort into. This way, for monolingual Greek speakers Αθήνα.ελ looks normal and Google.com is inverted, for monolingual English speakers it’s the other way around, and both will spot something strange with gοοgle.com (the ‘ο’s being Greek omicrons rather than the 15th letter of the Latin alphabet).

josephcsible 5y ago

> If you don't, I suggest to ban them at your gateways. Can't you get the same security benefit, but without the drawback of being totally unable to reach such sites, just by disabling network.IDN_show_punycode in about:config (or some equivalent if you're not using Firefox)?

noasaservice 5y ago
If the browsers were the only thing affected, you'd be completely right. But the truth is that browsers are only a part of the issue here. We have to deal with: WWW browsers (firefox, chrome, edge, ie, brave, "browser" etc) email clients (LOTS) Signal Twitter Discord Google hangouts Telegram FB messenger And many more. And most of those don't have disambiguation settings like your example with firefox does. And all of them should be guarded against, as they have the same failure modes of "being sent link to log into $fake_service and looking completely real and getting hacked". I still maintain, since unicode provides no protections against homoglyphs, that the only real answer here is to firstly expand them to punycode, and secondarily to remove all homoglyph text.
thaumasiotes 5y ago
Well, there are two common attack types based on punycode. Type 1 is that you stick a homograph in there and hope it gets rendered and the victim never notices the difference. Type 2 is that you create a punycode URL which makes no sense by any standard, but which looks like xn--something-microsoft.com, and then you hope the punycode doesn't get rendered and your victim only notices the part where it ends with microsoft.com .
- josephcsible 5y ago
  For type 2, doesn't that attack work just as well even if it doesn't start with xn--?
  - thaumasiotes 5y ago
    Yes. But the fact that people try to do this with punycode URLs is relevant when you're deciding whether or not to block all punycode URLs. It adds a minor benefit to the "block" column.

ben_w 5y ago

> There are hacky ways to show some homoglyph attacks, like punycode. Been thinking about this recently. Is there a risk when?: • User has a preferred character set determined by preferred language (many people will have only one preferred character set even with multiple languages). • Display all domain names, which are written in that character set, using that character set. For example, Αθήνα.ελ for monolingual Greek speakers. • Display all other domain names — if even one character is outside that character set — in whatever other fallback mechanism you’re already using. My preference here would be to invert the colour scheme (background colour becomes foreground and vice versa) for each out-of-charset character, partly to draw explicit attention to homoglyphs, partly because it’s least invasive for most likely domains, but mainly because the fallback part is what I’ve put least mental effort into. This way, for monolingual Greek speakers Αθήνα.ελ looks normal and Google.com is inverted, for monolingual English speakers it’s the other way around, and both will spot something strange with gοοgle.com (the ‘ο’s being Greek omicrons rather than the 15th letter of the Latin alphabet).