User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20071022 Ubuntu/7.10 (gutsy) Firefox/126.96.36.199 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20071022 Ubuntu/7.10 (gutsy) Firefox/184.108.40.206 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 CERTIFICATE----- MIIEHjCCAwagAwIBAgIQMAb6HjdFPy8wj0xWzcp0WzANBgkqhkiG9w0BAQUFADBy MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDEYMBYGA1UE AxMPRXNzZW50aWFsU1NMIENBMB4XDTA3MTAxNjAwMDAwMFoXDTA4MDExNDIzNTk1 OVowRDEhMB8GA1UECxMYRG9tYWluIENvbnRyb2wgVmFsaWRhdGVkMREwDwYDVQQL EwhGcmVlIFNTTDEMMAoGA1UEAxMDd3d3MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDE4u1rBCpNsWpbONuTA1yPGdLuyBPdcuoQ7kTMKoILY61LsmKPvpvew5cI CMlvgrH7ZbwpBoVLic/2Kei1Gse3cJIoz/ouJu3SVO6sU0D1wlvorTnMJ1NJwaJY 7t/JzGYgVpWFeS6idvgXegj+QYJ2y3Wd171I0Q0u/TMUZSwHBwIDAQABo4IBYDCC AVwwHwYDVR0jBBgwFoAU2svqrVsIXcz//CZUzknlVcY49PgwHQYDVR0OBBYEFL49 5NsbJ2WHuamc1z+pnnf85/lSMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAA MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjARBglghkgBhvhCAQEEBAMC BsAwRQYDVR0gBD4wPDA6BgsrBgEEAbIxAQICBzArMCkGCCsGAQUFBwIBFh1odHRw czovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzA7BgNVHR8ENDAyMDCgLqAshipodHRw Oi8vY3JsLmNvbW9kb2NhLmNvbS9Fc3NlbnRpYWxTU0xDQS5jcmwwRgYIKwYBBQUH AQEEOjA4MDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9Fc3Nl bnRpYWxTU0xDQS5jcnQwDQYJKoZIhvcNAQEFBQADggEBAK11p5uUlu6UH1+l6uPf R5UNHO8dHDjTkB80Id70KgcByprN2RytbgjuW6SMEzM2HyFVSAicbmBQRDKU2xxr tWb/Qwrq68KZ5CRAaCscM9tAsRc8uCyKlGNGE0Mu6lmgDlwDXSAZzo//ifzKPGVA AGWvvYcnBys9h+bhchHtwgwRqExTUEHnblSl+UVBfAhuF6o7wBVUAAIx+Dw4xHbl pnO/aOUb9THJeTc8YALDjNiuWa5hkxHXKa/3wtGk1Hd/mhRHH6uuSYe/dNyQu8HR hPzsuns7vHStbYRdXiQsuQGgfaO+3kkD0hHcSmybNomtmSvDRoPnTrnPfFamVeCH o8c= -----END CERTIFICATE----- -----BEGIN RSA PRIVATE KEY----- MIICXgIBAAKBgQDE4u1rBCpNsWpbONuTA1yPGdLuyBPdcuoQ7kTMKoILY61LsmKP vpvew5cICMlvgrH7ZbwpBoVLic/2Kei1Gse3cJIoz/ouJu3SVO6sU0D1wlvorTnM J1NJwaJY7t/JzGYgVpWFeS6idvgXegj+QYJ2y3Wd171I0Q0u/TMUZSwHBwIDAQAB AoGBAKT2uhSDfepw73sVTayFEYV5DqoxC6vtP78F1LD4INPoJWgaQ8jK3RCt8pqx ug1rhTLtj9UT+JVNF+jaPneXw6MuswTKGULLHKgzlUqaUqdw/N0rNAsmEQayebME LzlkWneJMg3px6QdhYjK9vYQpJOyC+U9ZTSlwrFiaooK5LqBAkEA9dn6GY+TWxr2 3S4ysKY11O2cI4M+SrA+kGSFyxEIORLsDrySue+noR1wzo1CgxwTkHFgnNF4FuRS wjrTVESeQQJBAM0Dg9BVLtDXtrclB+fBjarKHjvXWt9AYrwXNgcq1GmMdurfkWFN ZT8ugbAWAaYirIGgNULkKPUXbGLlb5KxY0cCQQDwa2aZgn9Os7LAH0Jw30l7XZW4 YMsUzP+RwsvYBmLtNWTlEGHINOXPt/Ot+hQWFOnI8ibRlEKE2GlaCZ7KJIRBAkAm xWVmPtXNtR3e4Ofv0lDiXbr+AiozUk/Z1mHnVRg6pc/Pd1xdFG/zVO49yMujCaeq FAw+jDuarkVXJqDFEzr9AkEAq/xLmSJoPAgGjfpDWm/Dr9e0n5RQafGekjRJogz/ iPrGLNOXZTJk1oGekljImlt/QEKJPjb/8WC4Kjx91/8NhA== -----END RSA PRIVATE KEY----- Reproducible: Always 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/ Actual Results: Lock icon is displayed. Expected Results: 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. > Thanks 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: https://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/31a930dd9a2b740a 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? https://developer.mozilla.org/en/nsIEffectiveTLDService
I agree there might be something useful/helpful to do regarding unqualified/internal DNS names, but this isn't it.