Boulder: Proposal: localhost.letsencrypt.org dev certs

[coolaj86]

For continuing discussion from https://github.com/letsencrypt/acme-spec/issues/117

[coolaj86]

@jsha @jcjones, et al:

localhost is a poor choice to use a development domain. There are critical bugs it introduces into an application:

1) Depending on the browser and the context in which that browser is running (i.e. "app mode" vs "desktop mode" vs "kiosk mode", etc) localhost does not follow security policies in an identical manner to true domains.

2) Also, localhost will retain cookies, localStorage, etc that interferes with proper local development.

Providing a mechanism by which localhost.whatever.com or local.whatever.com - something to that effect is a better pattern for developing with various apis, apps, services, etc in a local environment (i.e. I need to test an oauth3 provider, an oauth3 consumer, and an SOA api simultaneously)

In the mindset of "moving the web forward", it would be more helpful to less experienced developers to encourage them to use a workflow that will have consistent security policies and not issue certs to localhost itself.

For the sake of lowering the barrier to entry for secure local development, there should ideally be a few publicly whitelisted domains such as localhost.letsencrypt-demo.org localhost.example.com and localhost.example.net.

I also like the idea that the domain owner would have a mechanism by which to whitelist domains ad-hoc, but... but maybe that gets complicated.

[jsha]

@coolaj86: Good point about developing on localhost.example.com vs just example.com. But I still think the correct development environment is to use a locally trusted self-signed cert for that. I think it's definitely worthwhile to make that easier. In large organizations there's often a dev env setup script that can include generating the self-signed cert and adding it to OS trust roots. It would be great if popular operating systems or web servers automated this process as well, so more developers would have a working https://localhost/, or https://localhost.example.com/.

[coolaj86]

Does the bolder server currently support issuing certs to localhost?

[lgarron]

Does the bolder server currently support issuing certs to localhost?

Note that a public CA must not issue valid certs to localhost (Baseline Requirements, section 7.1.4.2.1).

[coolaj86]

How does one appeal that?

And is there any reasoning stated? What is "Internal Name" defined anywhere?

Unfortunately the PDF was generated with a tool that treats each word as a different line, so it's not possible to search for "internal name" only "internal" or "name", at least not in Chrome.

I can't imagine why I shouldn't be able to purchase an HTTPS cert for a machine that is only used between peers on a VPN (and not on the internet at large). I don't want to have to go around trying to convince normal users to install a manufacturer issued root CA to their browsers to use and access such devices in their homes, cars, boats, etc.

[coolaj86]

Found it:

Internal        Name:           A   string  of  characters  (not    an  IP  address)    in  a   Common  Name    or  Subject Alternative Name    
field   of  a   Certificate that    cannot  be  verified    as  globally    unique  within  the public  DNS at  the time    of  certificate 
issuance    because it  does    not end with    a   Top Level   Domain  registered  in  IANA’s    Root    Zone    Database.   

Looks like it is intended to apply to *.local, *.home, etc.

I don't see why that should be applied to localhost.

[coolaj86]

Okay, I got some clarification on the matter and it makes sense:

https://cabforum.org/pipermail/public/2015-June/005673.html

Here's the gist of what's wrong:

Some devices are misconfigured such that some network requests for localhost actually hit the local DNS. Not just in theory, but in practice - it has been seen in the wild.

A router could have a DNS resolution for .localhost or localhost.homenetwork and depending on network settings of the router and device it could hijack the browser.

Most people have probably see this behavior at some time or other - where you start typing in something into an omnibar and for some strange reason it resolves to the router or to a device with the name of the search term instead of performing a google search.

Example: Carrie's iMac has been renamed to 'cookie', you join Carrie's home network and start to search for 'cookie' to get some recipes and instead it takes you to the Web Sharing service's Public folder on her iMac.

[prusnak]

Why is this closed? I read the email from the previous post and still think that pointing localhost.letsencrypt.org to 127.0.0.1 and creating SSL cert for localhost.letsencrypt.org (ideally generated by letsencrypt and downloadable somewhere) should be OK. Or am I wrong?

[jsha]

In order for an arbitrary developer to use the type of certificate you propose, the Subscriber who requested it would have to publish not only the certificate, but also the private key. That would be a violation of the Subscriber Agreement and we would be forced to revoke the certificate.

Besides the policy issues, it would be a bad idea to encourage developers to connect to an HTTPS origin for which the private key is publicly available.

As I said above, the issue of HTTPS-based localhost development is eminently fixable by using a locally-trusted certificate. The ecosystem does need better tooling to make generation and installation of such certificates easier (I wrote a script to do it at a past job), but that's out of scope for Boulder. So this is a Won't Fix.

[prusnak]

My point was rather that if the cert and the private key was generated and published by Let's Encrypt itself, there would be no Subscriber Agreement violation.

My usecase is the following:

• we have users that use specialized hardware which needs to communicate with our website
• users run daemon on their computers which communicates with the hardware and exposes https server - messages are translated from hardware layer to https requests in both directions
• one could use http server instead and be done with it, but then we could not distribute our website via https (embedded insecure content)
• we solve this usecase by issuing the cert for localhost.foo.com and bundling the private key with the daemon, which is not cool because of the reasoning you state above (basically we hope that our CA won't find out)

If you want to take the discussion elsewhere or you don't want to discuss this topic further, please let me know. I understand that this issue is a WontFix and I don't want to reopen it. I also hate offtopic posts on Github, but this seemed like a best place to me to discuss this issue and is still a little bit on-topic I guess.