well according to the IDN standards the characters will iirc be normalized meaning that the 2-part chars get into 1…
Any news on this? We will be very happy to add (almost) complete IDN support to obtain SSL certificates for Airee cloud.
I think that LE shouldn’t enforce any weird restrictions on domains. If domain is exists, resolvable by DNS and LE client can prove that it’s running on machine that accessible on that DNS name — everything should be fine. Registrars itself will not allow to register weird name (they even doesn’t allow to mix latin and national characters in single part of domain).
Hope that IDN support will be added soon. Thanks.
Seriously, this is ridiculous. For you the letter å may look like the letter a, but it sure as diddly-doo doesn’t for us. Why shouldn’t the people of the countries who are aware of the letter å be able to use it in their respective ccTLDs? Imagine if LE was based in a country not using the Latin script (e. g. Japan or Georgia), and they banned all domains containing the letter l just because it happens to look a bit like t. That’s the level of silliness we’re talking about here.
Personally, I think you shouldn’t have any restrictions at all concerning IDNs, as it’s not your place. But if you insist, why not at least allow the alphabet of any given country in its respective ccTLD?
Everyone is entitled to their view. Persοnally I wouldn’t spot the difference between these two …
One of which uses an omicron instead of an ‘o’. You may well have much better perception than the average user of the web. In my view though, I think not allowing certificates for the fake one of the two in the image above is a good thing, as it protects my website from someone who may try and have a domain name that looks remarkably similar (to me ).
If someone can register a homoglyph domain, they can already do that. So the premise of restricting the issuance of certificates is that ‘https://paypa1.com/’ is somehow a disaster whereas ‘http://paypa1.com/’ isn’t. I don’t see that that’s the case; indeed, I think it’s been implicitly rejected when Let’s Encrypt politely pointed out that it isn’t the role of DV CAs to verify trustworthiness or legal identity, only domain control (and then adopted the Google Safe Browsing list anyway).
According to Wikipedia: “Some internationalized country code top-level domains are restricted in a way that hinders homographic attacks. For example, the Russian TLD .рф only accepts Cyrillic names, forbidding a mix with Latin or Greek characters. However the problem in .com and other gTLDs remains open.”
- Firefox: Display as punycode unless TLD whitelisted as having anti-homoglyph rules OR labels do not mix scripts for different languages. It is implied by those pages that the algorithm is now preferred, though the whitelist is still supported.
- IE7+: Display as punycode unless labels do not mix scripts for different languages and the script is on a user-defined list of allowed languages. There are some exceptions for scripts which are commonly mixed with ASCII.
- Safari renders “problematic character sets” in punycode.
- Chrome’s policy.
So there are two main strategies available: a TLD whitelist based on TLDs known to have anti-homoglyph policies, and a script consistency algorithm. Either or both of those strategies could be used, or it could be decided to just trust browsers to do the same and issue for any punycode label.
my Idea would be that LE does certain checks (e.g. all chars are in same script, like latin, greek, cyrillic and cjk) and if that is true than give cert, else not,but it’s not that easy.
I don’t see the problem in enabling IDN certificates.
First, most TLDs already restrict the possible characters. You just cannot register gőőgle.de. Only the generic ones like com remain.
But even more important is that, most browsers already have a prevention against this forgery. If the language to which the characters belong is not listed in the language settings of the browser, it will only display Punycode. See http://www.chromium.org/developers/design-documents/idn-in-google-chrome
So even if there is a homoglyph attack, if the users browser does not signal that the user can read the script, it will only display Punicode.
By the way, the one Unicode block only does not work. Chinese uses, only for characters, at least three or four blocks, Japanese as well, other languages surely as well.
Forget all tricky ones and follow http://www.ietf.org/rfc/rfc3492.txt. If domain registry authorities can support it, so can you? I ask this in the name of Motörhead (https://fi.wikipedia.org/wiki/Motörhead). UK rock band has come over the fear of Ö-letter, and so you should too. ÅÄÖ and those funny danish letters.
When will this restriction be lifted? I need that letter Ö badly, my name contains it.
So the only reason we cannot use the awesomeness of IDNs is because of those crazy Cyrillic letters? Everyone knows real IDNs should be something like 龘.香港, which doesn’t have this problem. Apparently my joke domain is so awesome that it not only gets rejected by Israeli CAs with terrible websites but by Let’s Encrypt as well!
In all seriousness, I quite appreciate the work that has been put into Let’s Encrypt and would like to see it support IDNs even though I don’t need it quite as badly as some of the posters above. I am in favor of leaving it up to the browsers to detect and deal with potential homoglyph attacks.
If the reason for not supporting IDN domains is fraud prevention, you guys should also reject domains containing the letters l and i.
See, it is impossible to tell the difference between:
No, serious, please get over it and enable IDN, there are people out there using this and they also deserve HTTPS etc.
but a browser always enforces lowercase so…
Okay, my sarcastic comment was not about fonts, lowercase or if there are other ways to use the internets than just browsers.
What I wanted to point out is, that LE can not guarantee anything with the certificates they give out. There is no check if I’m google or not. LE does not protect anyone from fraud. LE is not handing out trust.
What LE does is handing out certificates for secure communication. The only thing you can verify is that that the entity you are communicating with is the one you have called and has not changed meanwhile.
Please leave the fraud detection to the people who are in charge for that.
Good news, https://letsencrypt.org/upcoming-features/ give an ETA Before July 1, 2016 for IDN support. So this is coming soon.
Wohoo! Thats really good news
It writes “[…]Before August 1, 2016[…]” now.
It’s August 30th now.
It’s November 30th now.