User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20071022 Ubuntu/7.10 (gutsy) Firefox/220.127.116.11
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/20071022 Ubuntu/7.10 (gutsy) Firefox/22.214.171.124
Certificate authorities are willing to issue certificates for unqualified host names to anyone. For this reason, HTTPS connections to unqualified host names do not provide any protection against active network attackers and should not be decorated with a lock icon.
For example, suppose Alice navigates her browser to "https://www/". If Firefox receives a valid cert for www, it will display a lock icon even though an active network attacker could replace the real server's certificate with his own.
These server name certificates are useful in that they provide protection against passive network attackers, and certificates authorities are unlikely to stop issuing these certificates as they provide a profitable revenue stream.
The fix is simple: show a broken lock icon. This is analogous to the mixed content scenario where the user is protected against a passive network attacker (but not an active network attacker).
For reference, here is a certificate for 'www':
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
Steps to Reproduce:
1. Install the supplied certificate on a web server.
2. Modify your HOSTS file to point www to that web server.
3. Navigate to https://www/
Lock icon is displayed.
A broken lock icon should be displayed.
Created attachment 286355 [details] [diff] [review]
Causes a broken lock icon to be displayed for server name certificates
Here is a patch that fixes this issue.
This patch contains a comment that says:
> CAs are willing to issue certs for unqualified host names to anyone.
Please name CAs that are willing to do so.
The "www" certificate included in this bug was registered from Comodo (instantssl.com). The other certificate authorities I've tried are VeriSign (which allows server name certificates), completessl.com (which allows both server name certificates and private IP address certificates), and GeoTrust (which does not allow server name certificates).
> For this reason, HTTPS connections to unqualified host names
> do not provide any protection against active network attackers and should not
> be decorated with a lock icon.
I don't understand your statement.
If I understand correctly, you are worried about "active network attackers" in particular. I'm not sure what kind of attack you image, but I suspect you talk about DNS attacks, where an attacker is able to modify the responses of the DNS server and provide an IP address of his choice.
If an attacker is able to do that, why is a simple hostname any different from a fully qualified name? The hacker can exchange DNS information for both.
(In reply to comment #4)
> > For this reason, HTTPS connections to unqualified host names
> > do not provide any protection against active network attackers and should not
> > be decorated with a lock icon.
> I don't understand your statement.
> If I understand correctly, you are worried about "active network attackers" in
> particular. I'm not sure what kind of attack you image, but I suspect you talk
> about DNS attacks, where an attacker is able to modify the responses of the DNS
> server and provide an IP address of his choice.
> If an attacker is able to do that, why is a simple hostname any different from
> a fully qualified name? The hacker can exchange DNS information for both.
I think the argument is that in the typical MitM scenario, SSL protects the user because it is presumed "difficult" for the attacker to obtain a trusted DV cert for paypal.com. But in the case of attack against non-FQDNs, there is no similar difficulty - an attacker can obtain a trusted cert for "www" or "intranet." Therefore our traditional safeguards fail, and that sort of sucks.
I don't know if the solution is to change our security indicators, or get pretty grumpy at our issuing CAs. Maybe there's more nuance here than I understand, and I'm sure it's big business and all, but it's sort of crappy if certs from trusted authorities have precisely zero vetting.
Names like "www" are not globally unique. If I can get a cert
for "www", the cert and its private key can be used at any
company's intranet that has a server named "www".
Aren't you surprised that you can get a cert from a general-purpose
CA for a name that's not globally unique?
Allowing the connection to proceed but showing a broken lock
icon is a reasonable way to handle this.
The attached patch doesn't do anything to indicate the reason
why "STATE_IS_BROKEN". Adam, what do you see when you mouse
over the broken lock icon?
This patch doesn't work for two reasons:
1) The mouse-over text is unchanged.
2) The location bar still has a yellow background.
I'll figure out the right way to fix the issue and submit another patch.
(In reply to comment #2)
> This patch contains a comment that says:
> > CAs are willing to issue certs for unqualified host names to anyone.
> Please name CAs that are willing to do so.
Comodo - that's the one we most recently approved. There might be others.
You have a patch on this bug that is flagged for 'review?' and not assigned to any reviewer. If you want the patch to be reviewed please assign a reviewer. Thanks
Comment on attachment 286355 [details] [diff] [review]
Causes a broken lock icon to be displayed for server name certificates
(In reply to comment #9)
> You have a patch on this bug that is flagged for 'review?' and not assigned to
> any reviewer. If you want the patch to be reviewed please assign a reviewer.
In comment 7 the patch creator already stated that the patch doesn't work, therefore marking as obsolete.
A cert for "www" is a violation of our CA policy and grounds for removal of the CA. Certs may only be issued to parties in control of a domain. Given that you can't be in control of "www", given that it's not a domain, the cert must not be issued.
<http://www.mozilla.org/projects/security/certs/policy/>, section 7:
> verify that the entity submitting the certificate signing request
> has registered the domain(s) referenced in the certificate or
> has been authorized by the domain registrant to act on the registrant's behalf
Therefore, please "get pretty grumpy at our issuing CAs".
(In reply to comment #11)
> A cert for "www" is a violation of our CA policy and grounds for removal of the
> CA. Certs may only be issued to parties in control of a domain. Given that you
> can't be in control of "www", given that it's not a domain, the cert must not
> be issued.
I guess you'll have to remove all the CAs from your program then. You might want to start by removing VeriSign.
Some discussion on mozilla.dev.tech.crypto:
As per comment #11, this bug is invalid as stated and the CAs need to stop issuing certificates for internal host names. Did anyone pursue this with them? Should I enter a new bug against "CA Certificates"?
> As per comment #11, this bug is invalid as stated
This is my comment, and I said nothing to that effect.
In fact, I meant to state that this bug is valid and should be fixed.
wtc said more or less the same in comment 6.
Some more evangelicalism in this respect: https://blog.startcom.org/?p=221
Additionally a letter has been sent recently by Kathleen to all CAs, see thread http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/2fd03aec8af21eed
(In reply to comment #14)
> This is my comment, and I said nothing to that effect.
> In fact, I meant to state that this bug is valid and should be fixed.
> wtc said more or less the same in comment 6.
I meant that if the CAs followed the policy, the proposed change would be unneeded and would introduce a gratuitous special case. But if you want to make it anyway as an extra defense, that's fine.
If a hostname doesn't contain any dots (.), we can conclude it's "not qualified" => no security indicators. If that's all that's being asked for, we can use a straightforward patch to change security to broken. (Optionally update the user interface to explain this scenario, when we encounter it.)
Does this bug also request to correctly behave for hostnames like "abc.xy" ?
If yes, how can we reliably distinguish "fully qualified" from "unqualified" hostnames, without embedding (and maintaining) the full list of all known TLDs in the code?
(In reply to comment #17)
> If yes, how can we reliably distinguish "fully qualified" from "unqualified"
> hostnames, without embedding (and maintaining) the full list of all known TLDs
> in the code?
I agree there might be something useful/helpful to do regarding unqualified/internal DNS names, but this isn't it.