Add support for Internationalized Domain Names

[jcjones]

(from @bifurcation) We need to add specific tests to ensure the proper handling of internationalized domain names for validation, issuance, whitelist/blacklist, policy enforcement, etc.

[jsha]

Right now we reject all IDNs in policy.go: https://github.com/letsencrypt/boulder/blob/master/policy/policy-authority.go#L143. Which I think is correct for our immediate launch goals. We should revisit policy needs (in particular homoglyphs) post-launch.

[rolandshoemaker]

Note miekg/dns does seem to have punycode support, although I'll admit I haven't tested it at all.

[bifurcation]

I can agree that we don't need this right off the bat, but it seems like a serious failing to me for LE not to be able to serve IDNs. So I would propose that this be a GA bug. @bdaehlie, any objection?

It seems like the major risk to be addressed here is the risk of confusables for things on the PA's blacklist. Conveniently, @filosottile has made a golang library for identifying confusables, so this should actually be pretty straightforward to implement.

[bdaehlie]

We shouldn't consider IDN a GA feature right now. We need to be careful about what we put on our plate at the moment, we need to clear out the rest of our GA bugs before we work on this.

[haasn]

My most important domain is an IDN. Without IDN support, I might as well not use letsencrypt at all.

If LE wants to be a CA that is usable in the real world, it needs to support domains that are used in the real world. My 2 cents.

Keep up the great work!

[stc074]

Hello i have a punycode domains i hope it will be accepted in the future, however i want to know if there is another solution for me (free ssl certificate for commercial use). Thanks !

[hildjj]

Seeing that #1326 might fix this issue, and that the change is pretty trivial, is there a policy issue that is blocking this change? Or is a more comprehensive PR required? I could imagine, for example, that we might want to check punycoded names for validity before accepting them.

[jmhodges]

Relevant Go issue for us to be aware of: https://github.com/golang/go/issues/13835

[rolandshoemaker]

Since we do our own DNS lookups (and miekg/dns supports punycode conversion) I think we only have to worry about handling it for HTTP requests since I doubt we can do unicode Host/SNI headers?

(note this is still a policy decision for Let's Encrypt no matter what we do in Boulder.)

[hlandau]

Not sure that this is an issue that should concern LE. LE merely need issue certificates for domains with xn-- labels. It doesn't seem like a CA's responsibility to handle homoglyph issues, just as it isn't to vet the trustworthiness of the sites they issue certificates for, only their identity.

[macuser913]

I'd like to second the posts from @haasn and @hlandau . I hope that full IDN compatibility is resolved.

[jehiah]

I'll third @hlandau's comment that I think LetsEncrypt should reject IDN domains, and allow punycoded domains.

That sidesteps golang/go#13835 and I think keeps things easier to reason about. It then becomes the clients responsibility to handle punycode, which I think is correct as that's what a cert should actually be generated for (to the best of my knowledge), and it better avoids the homograph issue.

[bifurcation]

@jehiah I'm totally on board with the "yes punycode/A-labels, no U-labels" approach.

Unfortunately, I don't think that resolves the homograph issue. It may be that the A-label / punycode value isn't confusable, but ISTM that boulder should also be looking after whether the corresponding Unicode value is confusable.

[haasn]

Correct me if I'm wrong, but I wasn't aware of there being any form of actual unicode domain support.

IDN means “punycoded” in every context. So the only question here is whether to support punycoded domains or not.

[rbu]

I'm really hoping this issue is resolved soon, being a German who actually uses IDN domains. There's a long discussion about the policy backgrounds for this decision over at the forums: https://community.letsencrypt.org/t/internationalized-domain-names/94

[madsobel]

Support should definitely be added in as punycode, we (people that uses IDN domains) are used to referring to our domains in punycode format all the time anyway.

+1 for Punycode support and getting this resolved soon :smile:

[Ascendor]

+1

[ArtemZ]

+1

[Envek]

I think that Let's Encrypt should not care about gomoglyphs and et cetera. Because domain registrars have restrictions about domain names that they allow to register. If such IDN-domain (in Punycode) does exist and it's resolving to the address of machine, that runs the letsencrypt client (so checks can be passed), then everything should be fine. Am I missing something?

+1 for enabling support for Punycoded domains (so LE may not deal with different encoding/decoding standards).

Only absense of IDN support stops me from dropping my own CA for securing my projects web interfaces and switching to Let's Encrypt.

[z0mt3c]

+1

[kotborealis]

+1

[tisayama]

+1

[jberkel]

to all potential future +1 / :+1: comment posters: please consider using the new reaction feature to keep the noise down for everyone who is already subscribed to this thread, thanks.

https://github.com/blog/2119-pull-request-and-issue-reactions

[Ascendor]

Me personally, being subscribed to the thread, I want to hear the noise. It shouldn't get silent until it is solved or at least there is an official statement about it. In these terms: +1 (again ;))

[ruebenacker]

Also here +1

[ge0rg]

Seriously. Use the reactions. It is okay if you want to hear the noise, but these notifications go to everybody subscribed, and there are people out there who have real work to be done.

[jsha]

Agreed. It's very helpful to everyone if you just :+1: the issue rather than post a new comment. Locking the thread for now to decrease noise.

Thanks, Jacob

[jsha]

Alright, it looks like you can't add reactions on a locked thread, so I'm unlocking again. But please, everyone, use the reactions feature. That's what it's there for.

[piru]

I think that Let's Encrypt should not care about gomoglyphs and et cetera. Because domain registrars have restrictions about domain names that they allow to register. If such IDN-domain (in Punycode) does exist and it's resolving to the address of machine, that runs the letsencrypt client (so checks can be passed), then everything should be fine. Am I missing something?

Yes you are. In specific the IDN can be used in the leaf domain part of the host name, and domain registrars have no way of limiting that. This could be used in spoofing attacks when certain unicode "confusables" are used in the host name. For example:

www.google.com⁄search.evildomain.com

The unicode character ⁄ (0x2044, "FRACTION SLASH") is used in this example.

[haasn]

There's something I'm trying to figure out: If I am a black hat operator of a phishing site that relies on homoglyph attacks, what exact benefit am I gaining from using lets encrypt?

If I rely on my users falling for phishing attacks, I could probably just turn off HTTPS and see little to no difference in success.

If I think some portion of my users will be informed enough to notice the presence or absence of a padlock in the address bar, but fail to notice the phishing domain, I could get a free X.509 certificate for my base domain from one of the other companies that offer them.

(Also, it's not going to replace EV certs, it's not going to bypass HPKP and it's not going to fool SSL Observatory etc.)

Keep in mind evaluating this precise difference is important because it's what we're weighing against “Lets Encrypt availability for every user of an IDN”.

[piru]

If I am a black hat operator of a phishing site that relies on homoglyph attacks, what exact benefit am I gaining from using lets encrypt?

(HTTPS in general - not just LE - ) Better hit ratio for example bank users. Banks and CERTs are telling people to look for the padlock and check for https, even to extent that it is actually building a false sense of security... As we well know just because a site is using https doesn't mean it's legit. You're just accessing the phishing site over secure connection...

The attacker gains extra credibility by using SSL certificate. IMHO with automated CA systems like LE great care should be taken to make obtaining a certificate for phishing host as hard as possible. I'm not sure if LE already implements blacklists for certain keywords in the hostname (such as "google", "ebay", "paypal" etc), but if not, that certainly should be done, too.

If I think some portion of my users will be informed enough to notice the presence or absence of a padlock in the address bar, but fail to notice the phishing domain, I could get a free X.509 certificate for my base domain from one of the other companies that offer them.

CAs try to avoid this issue by blacklists and even manual checks if the domain is newly registered or scores high enough on "phish-score" (heuristic value calculated from the host name). IDN enables some new tricks, and thus this needs to be taken into consideration if/when adding IDN support to LE. Making sure the unicode confusables are blacklisted is one of the checks required for LE IDN support.

[rbu]

If you haven't seen, LE's roadmap now notes IDN support as "Before August 1, 2016".

Have you guys worked out a strategy on what to and what not to support yet?

[jarvelov]

The roadmap now states "ETA: Before November 30, 2016" for IDN support. No official comment on progress?

[jsha]

Progress has been slow, but we're still working on it. Sorry for the delays!

[mariokorte]

Any news on this? Is end of November still accurate? After all the delays and reschedules...

[deemytch]

+1 Error: Domain failed. Please start back at Step 1. { "type": "urn:acme:error:unsupportedIdentifier", "detail": "Internationalized domain names (starting with xn--) not yet supported", "status": 400 }

[rolandshoemaker]

Note for users following along: for Let's Encrypt to adopt this feature the CP/CPS legal documents need to be updated explaining how we handle IDN names before we can enable this feature, that will most likely take a little longer as it requires review by lawyers etc.

An announcement here and in the Let's Encrypt community forum will be made when we finally flip the switch.

[ArtemZ]

Thank you very much for your work

On 06.10.2016 20:43, Roland Bracewell Shoemaker wrote:

Note for users following along: for Let's Encrypt to adopt this feature the CP/CPS legal documents need to be updated explaining how we handle IDN names before we can enable this feature, that will most likely take a little longer as it requires review by lawyers etc.

An announcement here and in the Let's Encrypt community forum will be made when we finally flip the switch.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/letsencrypt/boulder/issues/597#issuecomment-252036300, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3gqgCIYvVFWM4p3t9Ac3Nx4ExvfBwxks5qxTNagaJpZM4Fn4cc.

[trajano]

It's almost 2 years now, any update?

[jsha]

IDN names have been supported since October 2016: https://community.letsencrypt.org/t/idn-support-enabled/21469.