[cabfpub] [cabfquest] Forwarding: Exception to Baseline Requirements, section 7.1.4.2.1

Ryan Sleevi sleevi at google.com
Tue Jun 16 08:54:58 UTC 2015


Responding with permission of the author on the public list. Response below

On Tue, Jun 16, 2015 at 12:27 AM, Ben Wilson <ben.wilson at digicert.com>
wrote:

> AJ ONeal writes:
>
>
>
> This section excludes the ability to grant a certificate to localhost.
>
>
>
> It makes sense that you don't want `whatever.local` and `foo.home` to have
>
> certificates, because any computer can claim those names on any network and
>
> the winner wins.
>
>
>
> However, localhost is consistently globally unique to the requesting
>
> computer, so it is not vulnerable to any kind of attack.
>
>
>
> We want more developers to develop with https and as such, there should be
>
> some sort of public, shareable, localhost certificate that any developer
>
> can use to start experimenting with HTTPS and experience the differences in
>
> browser security policy, etc, that are enforced when using it.
>
>
>
> We want them to be able to do so without big red scary browser warnings
>
> that make them feel that https is something complicated that they want to
>
> avoid.
>
>
>
> Also, I don't know if a localhost.example.com would fall into this
> category
>
> or not, but we definitely need a way for localhost apps and home server
>
> apps to communicate with each other and with web apps in the new wave of
>
> peer-web development.
>
>
>
> See also:
>
>
> http://stackoverflow.com/questions/6793174/third-party-signed-ssl-certificate-for-localhost-127-0-0-1
>
>
>
> AJ ONeal
>
>
So, the assumption that "localhost" is globally unique is wrong, and
demonstrably wrong on modern platforms.

RFC 6761, Section 6.3 ( https://tools.ietf.org/html/rfc6761#section-6.3 )
spells out the expectations for "localhost." (as a special-use domain name
and as a special-use TLD)

Within this section, there is only one MUST-level requirement (i.e. has to
be implemented and is not optional), which is that DNS registries and
registrars not allow attempts to register "localhost"

In particular, pay attention to bullet 3 - "Name resolution APIs" (what
modern browsers would use) are not required (MUST, SHALL) to address
locally. Instead, they merely SHOULD return the loopback and SHOULD NOT
send to the network.

In empirical testing, we've seen multiple resolvers (notably, OS X's) send
localhost queries to the network, either as part of DNS suffix searches
(localhost.my.suffix.search.example), as a single-label entry
("\09localhost\0" in DNS terms), or as part of multicast DNS.

As a result, accessing "https://localhost", say, on a hostile WiFi access
point (such as your coffee shops) can be intercepted by a network attacker
and redirected to a site (or a certificate) of their choosing.

On the browser side, we've (Chrome) been extremely supportive of the CA/B
Forum's efforts to deprecate internal names, and excluding "localhost" from
being exceptional is, from our POV, "working as intended". Such a
certificate will, in time, be outright rejected (as part of the sunset of
these certificates).

As to your follow-up, which is the rationale for why a localhost
certificate is needed in the first place, I'd suggest following up with the
browsers. This has been discussed in the W3C's WebAppSec WG both as part of
the "Secure Contexts" work (
https://w3c.github.io/webappsec/specs/powerfulfeatures/#is-origin-trustworthy
) and in the context of "Mixed Content" work (
https://w3c.github.io/webappsec/specs/mixedcontent/#should-block-fetch ).

Alternatively, if there are specific issues with browsers, then you'd
likely find this being discussed on Mozilla's mozilla.dev.platform
newsgroup/mailing list (
https://groups.google.com/forum/#!forum/mozilla.dev.platform ) or on
Chromium's security-dev mailing list (
https://groups.google.com/a/chromium.org/forum/#!forum/security-dev ). Both
of these places are appropriate for discussions about whether or not HTTPS
is required to use powerful new web platform features (e.g. for Chromium,
for localhost, it nearly universally isn't required, and if there are
features that still require it for localhost / loopback addrs, they're bugs
to be filed) and whether or not, say, https://foo.example should be
prevented from opening ws://localhost (e.g. for Chromium, for a publicly
routable domain such as foo.example talking to a local daemon such as
localhost, HTTPS is presently required, and that's working as intended; in
the future, such communication may be blocked and require a separate opt-in
from localhost to allow foo.example to talk to it)

Hopefully in the reply above I've properly addressed what seems to be the
root of your issue, and, if not, given suggestions on where follow-ups
might be useful and why, from a publicly trusted CA side, issuing a cert to
"localhost" is dangerous and with real risk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150616/924c766a/attachment-0002.html>


More information about the Public mailing list