401317 - https connections to unqualified DNS names should show broken lock icon

Status: RESOLVED WONTFIX

(Core :: Security: PSM, defect)

Description

[Adam Barth]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071022 Ubuntu/7.10 (gutsy) Firefox/2.0.0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071022 Ubuntu/7.10 (gutsy) Firefox/2.0.0.8

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.

Comment 1

[Adam Barth]

Attachment: Causes a broken lock icon to be displayed for server name certificates

Here is a patch that fixes this issue.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

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.  

Comment 3

[Collin Jackson]

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).

Comment 4

[Kai Engert (:KaiE:)]

> 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.

Comment 5

[Johnathan Nightingale [:johnath]]

(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.

Comment 6

[Wan-Teh Chang]

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?

Comment 7

[Adam Barth]

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.

Comment 8

[Eddy Nigg (StartCom)]

(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.

Comment 9

[Murali Nandigama [:murali]]

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 10

[Kai Engert (:KaiE:)]

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.

Comment 11

[Ben Bucksch (:BenB)]

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".

Comment 12

[Adam Barth]

(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.

Comment 13

[Matt McCutchen]

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"?

Comment 14

[Ben Bucksch (:BenB)]

> 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.

Comment 15

[Eddy Nigg (StartCom)]

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

Comment 16

[Matt McCutchen]

(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.

Comment 17

[Kai Engert (:KaiE:)]

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?

Comment 18

[Collin Jackson]

(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

Comment 19

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

I agree there might be something useful/helpful to do regarding unqualified/internal DNS names, but this isn't it.