New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Internationalized Domain Names #597

Closed
jcjones opened this Issue Aug 7, 2015 · 40 comments

Comments

Projects
None yet
@jcjones
Copy link
Contributor

jcjones commented Aug 7, 2015

(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

This comment has been minimized.

Copy link
Contributor

jsha commented Aug 7, 2015

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

This comment has been minimized.

Copy link
Member

rolandshoemaker commented Aug 7, 2015

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

@bifurcation

This comment has been minimized.

Copy link
Contributor

bifurcation commented Aug 10, 2015

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.

@bifurcation bifurcation changed the title Test Internationalized Domain Names Add support for Internationalized Domain Names Aug 10, 2015

@bdaehlie

This comment has been minimized.

Copy link

bdaehlie commented Aug 10, 2015

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

This comment has been minimized.

Copy link

haasn commented Dec 6, 2015

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

This comment has been minimized.

Copy link

stc074 commented Dec 24, 2015

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

This comment has been minimized.

Copy link

hildjj commented Jan 5, 2016

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

This comment has been minimized.

Copy link
Contributor

jmhodges commented Jan 8, 2016

Relevant Go issue for us to be aware of: golang/go#13835

@rolandshoemaker

This comment has been minimized.

Copy link
Member

rolandshoemaker commented Jan 8, 2016

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

This comment has been minimized.

Copy link
Contributor

hlandau commented Jan 13, 2016

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

This comment has been minimized.

Copy link

macuser913 commented Jan 28, 2016

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

@jehiah

This comment has been minimized.

Copy link

jehiah commented Feb 8, 2016

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

This comment has been minimized.

Copy link
Contributor

bifurcation commented Feb 8, 2016

@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

This comment has been minimized.

Copy link

haasn commented Feb 8, 2016

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

This comment has been minimized.

Copy link

rbu commented Feb 17, 2016

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

This comment has been minimized.

Copy link

madsobel commented Feb 21, 2016

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 😄

@Ascendor

This comment has been minimized.

Copy link

Ascendor commented Feb 22, 2016

+1

@ArtemZ

This comment has been minimized.

Copy link

ArtemZ commented Feb 29, 2016

+1

@Envek

This comment has been minimized.

Copy link

Envek commented Mar 2, 2016

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

This comment has been minimized.

Copy link

z0mt3c commented Mar 2, 2016

+1

@letsencrypt letsencrypt locked and limited conversation to collaborators Mar 17, 2016

@jsha

This comment has been minimized.

Copy link
Contributor

jsha commented Mar 17, 2016

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

This comment has been minimized.

Copy link

piru commented Apr 26, 2016

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

This comment has been minimized.

Copy link

haasn commented Apr 26, 2016

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

This comment has been minimized.

Copy link

piru commented Apr 26, 2016

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

This comment has been minimized.

Copy link

rbu commented Apr 27, 2016

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

This comment has been minimized.

Copy link

jarvelov commented Jul 20, 2016

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

@jsha

This comment has been minimized.

Copy link
Contributor

jsha commented Jul 20, 2016

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

@mariokorte

This comment has been minimized.

Copy link

mariokorte commented Aug 22, 2016

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

@deemytch

This comment has been minimized.

Copy link

deemytch commented Oct 5, 2016

+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 rolandshoemaker self-assigned this Oct 5, 2016

@cpu cpu closed this in #2215 Oct 6, 2016

cpu added a commit that referenced this issue Oct 6, 2016

Add IDN support (#2215)
Add feature flagged support for issuing for IDNs, fixes #597.

This patch expects that clients have performed valid IDN2008 encoding on any label that includes unicode characters. Invalid encodings (including non-compatible IDN2003 encoding) will be rejected. No script-mixing or script exclusion checks are performed as we assume that if a name is resolvable that it conforms to the registrar's policies on these matters and if it uses non-standard scripts in sub-domains etc that browsers should be the ones choosing how to display those names.

Required a full update of the golang.org/x/net tree to pull in golang.org/x/net/idna, all test suites pass.
@rolandshoemaker

This comment has been minimized.

Copy link
Member

rolandshoemaker commented Oct 6, 2016

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

This comment has been minimized.

Copy link

ArtemZ commented Oct 6, 2016

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
#597 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA3gqgCIYvVFWM4p3t9Ac3Nx4ExvfBwxks5qxTNagaJpZM4Fn4cc.

@trajano

This comment has been minimized.

Copy link

trajano commented Sep 17, 2018

It's almost 2 years now, any update?

@jsha

This comment has been minimized.

Copy link
Contributor

jsha commented Sep 18, 2018

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

@letsencrypt letsencrypt locked as resolved and limited conversation to collaborators Sep 18, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.