Information Security News
Researchers have some good and bad news about the availability of secure e-mail. Use of STARTTLS and three other security extensions has surged in recent months, but their failure rate remains high, in large part because of active attacks that downgrade encrypted connections to unencrypted ones.
That conclusion, reached in a recently published research paper, means that a significant chunk of e-mail continues to be transmitted in plaintext and with no mechanism for verifying that a message hasn't been tampered with while it travels from sender to receiver. The downgrades are largely made possible by the simple mail transfer protocol used by many e-mail services. Because it wasn't originally designed to provide message confidentiality or integrity, it relies on later-developed extensions including STARTTLS, domainkeys Identified Mail, sender policy framework, and domain-based message authentication that often don't work as intended.
The researchers wrote:
Recently, I managed to register the domain name comindex.jp. This domain name uses thejapanese character, which looks somewhat like aslash typically used at the end of the domain name. As a result, an unsuspecting user may mistake the host name example.comindex.jp for the index.jp page at example.com.
International domain names and lookalikesare nothing new. As a result, registrars as well as browsers implemented various safeguards. But even with these safeguards, it is still possible to come up with creative domain names. Even without international characters, we do see typo squatting domains like rnicrosoft (this is r and n instead of m). There are a number of tools available that are trying to find all look alike domains. For example,Domaintoolsprovides a simple online tool . Some companies attempt to register all look-alike domains. But a domain like comindex.jpcould be used to impersonate arbitrary .com domain names.
The DNS protocol does not understand anything but plain ASCII. To encodeIDNs, punycode is used.Punycodeencoded domain names start with xn--, followed by all the ASCII letters in the domain name, followed by a dash and the international letters in an encoded format. For example, my domain encodes toxn--comindex-634g.jp. To mitigate the risks ofIDNs, some browsers usepunycodeto display the domain name if they consider it invalid.
Punycodeand other related standards are described in a document commonly referred to asIDNA2008(International Domain Names for Applications, 2008) and this document is reflected in RFC 5890-5895. You may still find references to an earlier version inRFCs3490-3492. TheRFCsmention some of the character confusion issues, but for the most part, refer to registrars to apply appropriate policies.
Similarly, there is no clear standard for browsers. Different browsers implementIDNsdifferently.
Safari: Safarirednersmost international characters with few exceptions. For examplecyrillicandgreekcharacters are excluded as they are particularly easily confused with English characters
Firefox: Firefox maintains awhitelistof top level domains for which it will render international characters. See about:config for details. .com is not on thewhitelistby default, but .org is. Country levelTLDsare on thewhitelist.
Chrome: Chromes policy is a bit more granular .
Internet Explorer: Similar to chrome. Also, international characters are only supported if the respective language support is enabled in Windows . The document on Microsofts MSDN website was written for Internet Explorer 7, but still appears to remain valid.
Microsoft Edge: I couldnt find any details about Microsoft Edge, but it appears to follow Internet Explorers policy.
And finally here is a quick matrix what I found users reporting with my test URL:
Firefox: displays Unicode
Safari: displays Unicode (users of Safari on OS X 10.10 report seeingpunycode)
Opera: only a small number of Opera users participated, most reporting Unicode.
Internet Explorer: displayspunycode
Mobile browsers behave just like the desktop version. E.g. Google Chrome on Android does not display Unicode, but Safari on iOS does.
For summaries of Unicode security issues, also seehttp://unicode.org/faq/security.html andhttps://www.owasp.org/index.php/Canonicalization,_locale_and_Unicode(among other OWASP documents)
NB: Sorry for any RSS feeds that the title may break.