1614217 - Do not consider publicly trusted certificates valid for localhost

Status: RESOLVED WONTFIX

(Core :: Security: PSM, enhancement)

Description

[demiobenour]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

Try to figure out if publicly trusted certificates are valid for localhost

Actual results:

I cannot find if publicly trusted certificates are valid for localhost. However, a publicly trusted certificate valid for localhost makes no sense, so it should be rejected.

Expected results:

All publicly trusted certificates are considered to have an implicit name constraint that excludes localhost, ::1, fe80::/10, and 127.0.0.1/8.

Comment 1

[Dana Keeler (she/her) [:keeler]]

This is prohibited at the policy layer (and enforced via certificate transparency). I don't think it's useful to enforce this in code because anyone who wanted to do this could just as easily get a certificate for example.com (provided they own the domain) and then modify the DNS records for example.com to redirect to 127.0.0.1, which is not something we could necessarily prohibit.

Comment 2

[demiobenour]

I was referring to the literal TLD localhost. DNS rebinding is a different problem.

The idea is that if someone connects to localhost, then they should be guaranteed that they are connected to a site with a certificate that was installed manually. Usually, this is a self-generated certificate used for local development, but it could also be a certificate installed by the system administrator for something like CUPS. This is only really relevant on multiuser systems, but those are still quite common in university and corporate settings.

Comment 3

[demiobenour]

In the context of CUPS, a user is often requested to enter their password to authenticate. The same password could be used to execute code with their privileges. Granted, port 631 is a privileged port, but Jupyter notebooks are a similar situation where a high-numbered port is used, and where anyone knowing the credentials needed can execute code with full user rights. Compromise of a CA, while very bad, should not result in arbitrary code execution, except perhaps via forged code-signing certificates.

Comment 4

[Dana Keeler (she/her) [:keeler]]

If you don't trust the system you're running on, you probably shouldn't give your credentials to a server run by another user on an unprivileged port.