Certs bearing simple host names and public IP addresses OK?
Nelson B Bolyard
I recently encountered a web site with a certificate that chained through
two intermediate CAs to one of Mozilla's trusted roots.
This cert's Subject Alt Name (SAN) extension included:
- 43 wildcard domain names (e.g. of the form *.something.tld)
- 1 non-wildcard DNS name (of the form something.tld)
- 4 binary IP addresses (all fully routable and accessible on the Internet)
- 4 DNS name strings that were the ASCII dotted decimal form of those 8 IP
addresses
- 12 simple host names (e.g. such as home, test, www01, www02, ... etc.)
The cert's subject name included 60 Common Name (CN=) attributes whose
attribute string values matched the 60 name strings in the SAN extension (as
if multiple CN attributes each containing a DNS name was conformant).
One of the cert's subject name OU attributes contained a string claiming
the cert was domain validated.
The 44 DNS names don't bother me any. I'm quite willing to believe that
the issuer verified that all those domains had the same registrant.
But the 12 simple host names and the 4 routable IP addresses (each of
which appears twice) bother me.
If I go to a url such as https://12.34.56.78/ and get a page with a lock
icon claiming to be a bank or financial institution, or even a well known
merchant, what assurances has that cert actually offered me?
Likewise, if I go to https://home/ and get a "home" page for some
enterprise, what assurances have I really been offered?
Does this bother any one else ?
Should Mozilla's policy speak to any of these issues?
/Nelson
Michael Ströder
>
> Likewise, if I go to https://home/ and get a "home" page for some
> enterprise, what assurances have I really been offered?
None, since your browser cannot check whether home is a fully-qualified
domain name.
> Does this bother any one else ?
Yes.
> Should Mozilla's policy speak to any of these issues?
Yes.
RFC 2818 (only INFORMATIONAL) references RFC 2459 concerning matching
rules which was obsoleted by RFC 3280 which was recently obsoleted by
RFC 5280. RFC 5280 references "Preferred name syntax" in RFC 1034.
Glancing over these documents I found no provision that the dNSName in
subjectAltName MUST specify a fully-qualified domain name. But maybe
this issue should raised on the ietf-pkix mailing list.
Ciao, Michael.
Jean-Marc Desperrier
> [...]
> RFC 2818 (only INFORMATIONAL) references RFC 2459 concerning matching
> rules which was obsoleted by RFC 3280 which was recently obsoleted by
> RFC 5280. RFC 5280 references "Preferred name syntax" in RFC 1034.
>
> Glancing over these documents I found no provision that the dNSName in
> subjectAltName MUST specify a fully-qualified domain name. But maybe
> this issue should raised on the ietf-pkix mailing list.
There's no reason to forbid at that level issuance of certificates that
are intended to be used only on an intranet.
It should be more the policy of the CA that should either refuse to
issue such certificates, or require a written agreement that they are
intended only for intranet use.
Michael Ströder
> Michael Ströder wrote:
>> [...]
>> RFC 2818 (only INFORMATIONAL) references RFC 2459 concerning matching
>> rules which was obsoleted by RFC 3280 which was recently obsoleted by
>> RFC 5280. RFC 5280 references "Preferred name syntax" in RFC 1034.
>>
>> Glancing over these documents I found no provision that the dNSName in
>> subjectAltName MUST specify a fully-qualified domain name. But maybe
>> this issue should raised on the ietf-pkix mailing list.
>
> There's no reason to forbid at that level issuance of certificates that
> are intended to be used only on an intranet.
Well, if there are doubts whether https://de/ points to a A/CNAME record
in the .de top-level domain or resolves to a local server (by DNS adding
search suffix) and is therefore treated as equivalent to
https://de.example.test/ then the TLS standard should say something
about this. Also matching rules for dNSName are affected.
> It should be more the policy of the CA that should either refuse to
> issue such certificates, or require a written agreement that they are
> intended only for intranet use.
Nelson was asking for adding an additional provision to Mozilla's policy.
Ciao, Michael.
Eddy Nigg (StartCom Ltd.)
The 44 DNS names don't bother me any. I'm quite willing to believe that the issuer verified that all those domains had the same registrant. But the 12 simple host names and the 4 routable IP addresses (each of which appears twice) bother me. If I go to a url such as https://12.34.56.78/
and get a page with a lock icon claiming to be a bank or financial institution, or even a well known merchant, what assurances has that cert actually offered me? Likewise, if I go to https://home/ and get a "home" page for some enterprise, what assurances have I really been offered? Does this bother any one else ? Should Mozilla's policy speak to any of these issues?
Host name based certificates can provide an easy attack vector for internal networks once the host names are known to the attacker. Here we are talking mostly about networks of organizations and seldom for public networks. An unattended PC might be easy to manipulate and MITM. Use of host names should be discouraged from using.
IP addresses make sense for IP block owners and usage should be discouraged for general certificates as with the case you stated. IP addresses can get changed frequently - specially dynamic dial up assigned, but also in hosting environments. Therefore it's very hard to guaranty that the specific address is still valid even days after issuance. Block owners are somewhat different because it involves usually longer term assignments (and contract) of the block. It also makes sense for router equipment.
IP addresses can be validated the same way as domain names (for example sending of email ping to postmaster@[123.123.123.123]) however as stated above, because of dial up users additional verifications should be performed.
For internal networks, internally assigned domain names should be used, like NETWORK = intern.domain.com with the HOST resulting in pc.intern.domain.com where the NETWORK represents the Class C 10.0.0.0 IP and the HOST something like 10.0.0.5. Yes, this despite that MS telling is us otherwise and use non-existing TLDs (security by obscurity). Certificates can be legitimately issued to pc.intern.domain.com.
It bothers me not more than having domain validated certs with a lifetime for 10 years or as you mentioned also, wild cards which are domain validated. It all belongs to the same category of irresponsible CA practices. And yes, I believe that Mozilla should strengthen its policy requirements.
| Regards | |
| Signer: | Eddy Nigg, StartCom Ltd. |
| Jabber: | star...@startcom.org |
| Blog: | Join the Revolution! |
| Phone: | +1.213.341.0390 |
Michael Ströder
> For internal networks, internally assigned domain names should be used,
> like NETWORK = intern.domain.com
Thinking further about this whole stuff:
I consider the hostname checking to be a very important validation of
whether the browser really connects to a host to which the user really
wanted to connect to. The user cannot distinguish whether the hostname
in https://com is a fully-qualified domain name or not. If DNS resolving
with automagic suffix search is conducted then some disambiguation has
to be made.
So I'd recommend either one of these two solutions:
1. If the user enters https://hostname (hostname without dots) then the
DNS resolver should in case of SSL/TLS connects not apply any DNS suffix
search list when resolving hostname.
2. If the user enters https://hostname (hostname without dots) and DNS
suffix search is conducted the fully-qualified domain name used to
connect to the host must be displayed to the user and must be verified
to be in the cert.
I'd prefer 1. For both solutions only fully-qualified domain names are
needed in the certs.
Ciao, Michael.
Wan-Teh Chang
>
> I recently encountered a web site with a certificate that chained through
> two intermediate CAs to one of Mozilla's trusted roots.
>
> This cert's Subject Alt Name (SAN) extension included:
>
> - 43 wildcard domain names (e.g. of the form *.something.tld)
> - 1 non-wildcard DNS name (of the form something.tld)
> - 4 binary IP addresses (all fully routable and accessible on the Internet)
> - 4 DNS name strings that were the ASCII dotted decimal form of those 8 IP
> addresses
> - 12 simple host names (e.g. such as home, test, www01, www02, ... etc.)
>
> The cert's subject name included 60 Common Name (CN=) attributes whose
> attribute string values matched the 60 name strings in the SAN extension (as
> if multiple CN attributes each containing a DNS name was conformant).
>
> One of the cert's subject name OU attributes contained a string claiming
> the cert was domain validated.
>
> the issuer verified that all those domains had the same registrant.
>
> But the 12 simple host names and the 4 routable IP addresses (each of
> which appears twice) bother me.
>
> If I go to a url such as https://12.34.56.78/ and get a page with a lock
> icon claiming to be a bank or financial institution, or even a well known
> merchant, what assurances has that cert actually offered me?
>
> Likewise, if I go to https://home/ and get a "home" page for some
> enterprise, what assurances have I really been offered?
>
> Does this bother any one else ?
There is a bug on certs containing unqualified host names:
https://bugzilla.mozilla.org/show_bug.cgi?id=401317
Wan-Teh
Michael Ströder
> There is a bug on certs containing unqualified host names:
> https://bugzilla.mozilla.org/show_bug.cgi?id=401317
I really wonder what makes a host name an "unqualified hostname"?
No doubt that https://www/ looks like a valid example to us humans. But
how about https://com/ (top-level domain)? As I noted in a previous
posting technically you can't tell without actually trying to lookup a
hostname in DNS (without search suffix automagic).
Ciao, Michael.
hk9...@gmail.com
> I really wonder what makes a host name an "unqualified hostname"?
One workable definition is a host name without a dot "." (ignoring any
trailing dots).
For example:
example.com is qualified
foo is unqualified
com is unqualified
foo. is unqualified
foo....... is unqualified
> No doubt that https://www/looks like a valid example to us humans. But
> how about https://com/(top-level domain)?
It doesn't really matter what looks like a valid host name to humans.
What matters is the policy under which certificates are issued. If a
CA is willing to issue certs for "com" or "www" to anyone, then the
certificate does not guarantee who you're talking to. (Examining the
certificate in the browser is also useless in the presence of <script
src="lib.js">, which might use a different cert.)
> As I noted in a previous
> posting technically you can't tell without actually trying to lookup a
> hostname in DNS (without search suffix automagic).
It doesn't matter what DNS tells you. In this threat model, DNS is
under the control of the attacker. What matters is what the browser
can deduce from the CA's signature on the certificate.
Adam
Michael Ströder
> On Jun 9, 2:55 pm, Michael Ströder <mich...@stroeder.com> wrote:
>> I really wonder what makes a host name an "unqualified hostname"?
>
> One workable definition is a host name without a dot "." (ignoring any
> trailing dots).
This would exclude issuing certs for a top-level hostname. This could be
a valid assumption though.
>> No doubt that https://www/looks like a valid example to us humans. But
>> how about https://com/(top-level domain)?
>
> It doesn't really matter what looks like a valid host name to humans.
That's exactly what I meant. ;-)
> What matters is the policy under which certificates are issued. If a
> CA is willing to issue certs for "com" or "www" to anyone, then the
> certificate does not guarantee who you're talking to.
It depends: If the CA states that the hostname MUST be a fully-qualified
domain name then even a hostname without a dot has a well-defined
meaning without extra magic.
>> As I noted in a previous
>> posting technically you can't tell without actually trying to lookup a
>> hostname in DNS (without search suffix automagic).
>
> It doesn't matter what DNS tells you.
But it does matter what the browser asks for.
> In this threat model, DNS is under the control of the attacker.
Yes.
> What matters is what the browser
> can deduce from the CA's signature on the certificate.
But the browser does the connect based on DNS resolving.
Ciao, Michael.
hk9...@gmail.com
> hk9...@gmail.com wrote:
> > One workable definition is a host name without a dot "." (ignoring any
> > trailing dots).
>
> This would exclude issuing certs for a top-level hostname. This could be
> a valid assumption though.
CAs are willing to issue certificate for "com" to anyone, making those
certificates useless. Here is a certificate for com signed by a
trusted CA:
-----BEGIN CERTIFICATE-----
MIIERDCCAyygAwIBAgIQPHHf2KeR2ULc7AuV4q6afDANBgkqhkiG9w0BAQUFADBy
MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD
VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDEYMBYGA1UE
AxMPRXNzZW50aWFsU1NMIENBMB4XDTA4MDYxMDAwMDAwMFoXDTA4MDkwODIzNTk1
OVowRDEhMB8GA1UECxMYRG9tYWluIENvbnRyb2wgVmFsaWRhdGVkMREwDwYDVQQL
EwhGcmVlIFNTTDEMMAoGA1UEAxMDY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQC/4kkG00zYalrW3yHrnKk3BbOiCVHFifS2ty3IOHr5zgmdIc8sIj73E0q/
+A94j85nv0uJsAt6wVyQu62lyuUqXKri/FsGrKnTyQ7xzzgaHPtvom3ooWkIBIEa
GeD6Q2EYaZ+YRln+ruWEO8unjcKFJNFwIwoOSCZw+Oi7xGLifwIDAQABo4IBhjCC
AYIwHwYDVR0jBBgwFoAU2svqrVsIXcz//CZUzknlVcY49PgwHQYDVR0OBBYEFALk
5BKgTKADQn9KsRlhPVyT+D6dMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAA
MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjARBglghkgBhvhCAQEEBAMC
BsAwRQYDVR0gBD4wPDA6BgsrBgEEAbIxAQICBzArMCkGCCsGAQUFBwIBFh1odHRw
czovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzA7BgNVHR8ENDAyMDCgLqAshipodHRw
Oi8vY3JsLmNvbW9kb2NhLmNvbS9Fc3NlbnRpYWxTU0xDQS5jcmwwbAYIKwYBBQUH
AQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9Fc3Nl
bnRpYWxTU0xDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2Nh
LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAYDu38LK/xi+y8rA18zlxGk62cmkOvmCw
XCsoUdw6ZrVuaHXHj+dmM3Bs+TnIkned+fhWNwlur/UODLTP4CmKW8KJ+1fPxnNy
I5qKLl1C1PfMBNHfvYK2SicBnFptlQs6wN2wv701qb6YJjF+vr/Cbe+0G04XrdWN
/ni/lGq2ZX3T0WVgB3zMNMJqweXW6xE+zi8p0lwrBvCq8Im6V63a369sHYt81CTl
CDl8DdvHYQ3W1+3DFmzk6Xh/7U5Ot8HPq5lKh+m4Xh4g+sJ65Xpn+sfjlbwsf2eO
pCCGkxzEW7/0mn1ubcLsX18GyYd7RChBfUJuVmUzq46NyJZmu1SNBA==
-----END CERTIFICATE-----
> It depends: If the CA states that the hostname MUST be a fully-qualified
> domain name then even a hostname without a dot has a well-defined
> meaning without extra magic.
If CAs restricted their issuing of certificates without dots to fully-
qualified host names, then those certificate would be useful in
preventing active network attacks. As it stands, CAs are willing to
issue these certificates to anyone, including active network
attackers. That makes the certificates useful for defending against
passive network attackers, but not against active network attackers.
>>> As I noted in a previous
>>> posting technically you can't tell without actually trying to lookup a
>>> hostname in DNS (without search suffix automagic).
>
> > It doesn't matter what DNS tells you.
>
> But it does matter what the browser asks for.
Why does it matter? In an attack senario, if the browser asks for
"foo", the attacker will supply a DNS response for "foo" and the
browser will think that it is a fully qualified host name.
> > What matters is what the browser
> > can deduce from the CA's signature on the certificate.
>
> But the browser does the connect based on DNS resolving.
I don't understand. Suppose I am under an active network attack. I
type https://www/ into my browser (perhaps expecting to get my
intranet portal). The browser resolves www and gets back 66.66.66.66,
the attacker's IP address. The browser connects to 66.66.66.66 and
receives a certificate for "www" signed by a trusted CA. The browser
displays the content, the lock icon, Larry, etc, but I'm talking to
the attacker and not my intranet portal.
Adam