Globalsign EV-signed RFC 1918 local address
Daniel Veditz
interesting data, http://www.eff.org/observatory
Jesse Burns forwarded this gem to me: https://www.designboard.com/
-- a valid EV cert that includes 192.168.100.1 as a DNS Name in the
Subject Alt Name extension.
There is no way GlobalSign could have performed the validation
specified in the EV guidelines section 10.6 on that "name". I hope
to see that cert replaced and revoked pronto, along with an
explanation of 1) how this cert got through their validation step,
and 2) what Globalsign is now doing differently to prevent this in
the future.
The NSS team had recently proposed not honoring IP addresses as DNS
names in certs, on the grounds that legit CAs wouldn't issue such
certs and they were a MITM hazard. That statement turns out to be
only half true, but I'd still like to unsupport them in the browser.
They would essentially be treated like self-signed certs, and users
would be allowed to set up an exception tying that cert to that site.
-Dan Veditz
Gen Kanai
On 8/10/10 3:46 PM, Daniel Veditz wrote:
> The EFF SSL Observatory project seems to have found all sorts of
> interesting data, http://www.eff.org/observatory
>
> Jesse Burns forwarded this gem to me: https://www.designboard.com/
> -- a valid EV cert that includes 192.168.100.1 as a DNS Name in the
> Subject Alt Name extension.
>
> There is no way GlobalSign could have performed the validation
> specified in the EV guidelines section 10.6 on that "name". I hope
> to see that cert replaced and revoked pronto, along with an
> explanation of 1) how this cert got through their validation step,
> and 2) what Globalsign is now doing differently to prevent this in
> the future.
Dan,
Is there a bug filed we can track?
Gen
--
Gen Kanai
Johan Sys
The CA/B guidelines are maturing and addressing use-cases not thought
of before. The cert in question was issued in Feb 2009 against EV
Guidelines 1.1. The RFC1918 issue was discussed in the CA/B forum in
April that year (referencing the MITM hazard) resulting in an update
of section 10.6 for version 1.2 released in Oct 2009 (http://
www.cabforum.org/Errata1.2.pdf). Incidentally GlobalSign itself
updated its systems and policies to disallow RFC1918 IP's in April
last year.
Hope this answers your questions, Johan
On Aug 10, 3:46 pm, Daniel Veditz <dved...@mozilla.com> wrote:
> The EFF SSL Observatory project seems to have found all sorts of
> interesting data,http://www.eff.org/observatory
Kyle Hamilton
-Kyle H
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Kyle Hamilton
On Mon, Aug 9, 2010 at 11:46 PM, Daniel Veditz <dve...@mozilla.com> wrote:
> The NSS team had recently proposed not honoring IP addresses as DNS
> names in certs, on the grounds that legit CAs wouldn't issue such
> certs and they were a MITM hazard. That statement turns out to be
> only half true, but I'd still like to unsupport them in the browser.
> They would essentially be treated like self-signed certs, and users
> would be allowed to set up an exception tying that cert to that site.
I was under the impression that there was an internetProtocolAddress type, identified by a different OID. IP addresses should NEVER have been accepted as dNSName.
-Kyle H
Daniel Veditz
> The CA/B guidelines are maturing and addressing use-cases not thought
> of before. The cert in question was issued in Feb 2009 against EV
> Guidelines 1.1. The RFC1918 issue was discussed in the CA/B forum in
> April that year (referencing the MITM hazard) resulting in an update
> of section 10.6 for version 1.2 released in Oct 2009 (http://
> www.cabforum.org/Errata1.2.pdf). Incidentally GlobalSign itself
> updated its systems and policies to disallow RFC1918 IP's in April
> last year.
IP addresses in general would seem to have been problematic from the
start for a program that is trying to validate the identity of a
site owner, but I really don't see why someone would have to
explicitly point out the additional problems with rfc 1918 addresses
if the guidelines were being followed as written. The language in
the 1.1 version of the guidelines is not much different. From section 18
"...the CA MUST verify that each such domain name satisfies
the following requirements:" (note "each" domain, not just
the main one)
(1) Domain is registered with an ICANN-approved registry. (nope)
(2) Domain WHOIS SHOULD ... (for an rfc 1918 address, nope)
(3) Applicant is
(A) register holder of the domain (nope) or
(B) has been granted exclusive right to use the domain
name by the registered holder (exclusive right to
rfc 1918 addresses? nope).
Am I misinterpreting this section? The meaning seems pretty plain
and shouldn't have required clarification. I'm happy you have now
disallowed RFC 1918 addresses (for all certs, or just EV?), but what
was the rationale behind allowing them in the first place? Or was
there none, you perhaps just continued on with your normal SSL
practice and tweaked a few things here and there for EV-ness?
OK, so you've fixed that procedural problem. We still have had this
EV cert in active use for sixteen months since you decided those
names were problematic. It's a two-year cert so unless something is
done is will continue to be valid for an RFC 1918 address for
another six months. Are there any plans to fix this (e.g. revoke the
cert and work with the customer to deploy a replacement)? Sure,
that's a PITA, maybe you can offer the customer a six month
extension on the replacement.
How many other still-valid EV certs have you issued with such
addresses? Do you still allow these addresses in non-EV certs? How
many of those do you have?
-Dan
Paul Tiemann
> Why are we not seeing updated OIDs for CAs that update their policies to reflect new changes? If there's only a single EV policy OID in each PKI for *all* revisions/reversions of the EV spec, we have no idea which version it was issued against, and thus no way to determine (since things *are* evolving, I must expect that new things will be accepted and old things will be discarded) what exactly is being recorded and certified.
I never heard of any plans to encourage separate OIDs for each revision of the EV guidelines. Additionally, I think some browsers have their allowed EV OIDs hard coded into their EV-detectors. I've never detected any interest from the browser vendors or CAs on the CA/B forum in holding onto a past version of the guidelines and calling that EV over the current guidelines, or saying that version X is good enough for them to show EV while version Y is no longer good enough.
Things are evolving (slow, deliberate pace), not revolutionizing (no radical changes from 1.0 to 1.1 to 1.2)
Paul Tiemann
CTO, DigiCert
Kaspar Brand
> I never heard of any plans to encourage separate OIDs for each
> revision of the EV guidelines.
In theory, the version number of the guidelines is/was part of the
businessCategory RDN in the subject: through 20 October of this year,
this field is populated with "V1.0, Clause 5.(...)". The version was
never updated to "V1.1, ..." or "V1.2, ..." with later revisions of the
guidelines, though. It will be replaced by one of the terms "Private
Organization"/"Government Entity"/"Business Entity"/"Non-Commercial
Entity" in October, anyway (see section 6 of the 1.2 Errata).
> Additionally, I think some browsers have their allowed EV OIDs hard
> coded into their EV-detectors.
The certificatePolicies extension could have multiple OIDs, one of them
referring to the version of the EV Guidelines under which the
certificate was issued.
Kaspar
Kai Engert
>
> Is there a bug filed we can track?
I've filed
https://bugzilla.mozilla.org/show_bug.cgi?id=586414
Kai
Kathleen Wilson
Is this a common issue that other CAs will share?
Do all such certs need to be re-issued right away?
If the answer to both is yes, then I should send out a communication to
all of the CAs with roots included in NSS to ask them to check for this
problem, and to re-issue all certs found with this problem.
While we're at it... If I do send out a communication, are there other
things in the EFF report that I should include? e.g. specific things to
ask the CAs to look for and fix. If yes, please provide the details that
I should include in the communication.
Thanks,
Kathleen
Eddy Nigg
On 08/12/2010 03:11 AM, From Kathleen Wilson:
>
> Is this a common issue that other CAs will share?
I'm not sure about that. As long as no evidence to the contrary is
provided I want to believe that this is an isolate case of a specific
CA. At least what EV certificates concerns.
>
> Do all such certs need to be re-issued right away?
Yes, the don't conform to any version of the EV guidelines. It never did.
>
> If the answer to both is yes, then I should send out a communication
> to all of the CAs with roots included in NSS to ask them to check for
> this problem, and to re-issue all certs found with this problem.
Perhaps the issue is far more sever than just EV certificates. The
Mozilla CA Policy defines under section #7 very clearly:
"for a certificate to be used for SSL-enabled servers, the CA takes
reasonable measures to 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"
I don't see here anything about IP addresses nor about non-registrable
TLDs anywhere. The fact however is, that scores of CAs (but not all)
issue certificates for meaningless Class C/B IP addresses, host names
without any TLDs and host names which are based on
non-existing/non-registrable TLDs.
If Mozilla respect its own policy, it should either start to enforce it
or modify the policy accordingly. Besides that, anything that can't be
verified in some way to be under the control of a specific entity can't
provide any security whatsoever. With today's WiFi access points, this
issue has become a real problem as compared to just about a few years ago.
I hope this makes it clearer about what the real issues at hand are.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Eddy Nigg
Hi Kathleen,
On 08/12/2010 03:11 AM, From Kathleen Wilson:
>
> Is this a common issue that other CAs will share?
I'm not sure about that. As long as no evidence to the contrary is
provided I want to believe that this is an isolate case of a specific
CA. At least what EV certificates concerns.
>
> Do all such certs need to be re-issued right away?
Yes, the don't conform to any version of the EV guidelines. It never did.
>
> If the answer to both is yes, then I should send out a communication
> to all of the CAs with roots included in NSS to ask them to check for
> this problem, and to re-issue all certs found with this problem.
Perhaps the issue is far more sever than just EV certificates. The
Jean-Marc Desperrier
> On 08/12/2010 03:11 AM, From Kathleen Wilson:
>>
>> Is this a common issue that other CAs will share?
>
> I'm not sure about that. As long as no evidence to the contrary is
> provided I want to believe that this is an isolate case of a specific
> CA. At least what EV certificates concerns.
This is a mix of two issues already referenced in the problematic
practices :
- Certificates referencing hostnames or private IP addresses : it is
also possible to include in a certificate a hostname not resolvable
through the public DNS (e.g., "home") or a private IP address (e.g.,
192.168.1.101); We consider this a problematic practice [...] It is also
a problematic practice to issue a certificate with non resolvable DNS or
private IP and resolvable DNS adresses together. [...]
- Validate all Data included in Certificates : [...] For example, for
SSL certificates, alternative names need to be validated just as well as
the subject.
I think at least the first should be upgraded to policy.
Actually given the existing text in problematic practice, I'm surprised
Kathleen seems to be discovering the problem. The only real news here
was that it also affects EV certificates.
But I'm happy if it means it will be more strongly objected from now.
Nelson Bolyard
> The EFF SSL Observatory project seems to have found all sorts of
> interesting data, http://www.eff.org/observatory
>
> Jesse Burns forwarded this gem to me: https://www.designboard.com/ -- a
> valid EV cert that includes 192.168.100.1 as a DNS Name in the Subject
> Alt Name extension.
That's no vulnerability in Mozilla products. NSS does not honor IP
addresses represented as strings in SAN DNS names. SANs have separate
forms for DNS names and IP addresses. NSS honors IP addresses only in
the IP address form, and honors DNS names only in the DNS name form.
This applies ONLY to SANs, where the two forms are separate, not to
subject CNs, where there is only one form, the string form, used for
both IP addresses and DNS Names.
> The NSS team had recently proposed not honoring IP addresses as DNS names
> in certs,
More precisely, not honoring IP addresses in subject Common Names in certs.
NSS already does not honor them in SAN DNS names, and has not for a very
long time. We now propose to close up the remaining "hole" which is
subject Common Names.
> on the grounds that legit CAs wouldn't issue such certs and they were a
> MITM hazard.
Just so.
> That statement turns out to be only half true,
Oh? Which half? :)
> but I'd still like to unsupport them in the browser. They would
> essentially be treated like self-signed certs, and users would be allowed
> to set up an exception tying that cert to that site.
>
> -Dan Veditz
--
/Nelson Bolyard <b> </b>
12345678901234567890123456789012345678901234567890123456789012345678901234567890
00000000011111111112222222222333333333344444444445555555555666666666677777777778
Nelson Bolyard
>
> On Mon, Aug 9, 2010 at 11:46 PM, Daniel Veditz <dve...@mozilla.com>
> wrote:
>> The NSS team had recently proposed not honoring IP addresses as DNS
> I was under the impression that there was an internetProtocolAddress
> type, identified by a different OID.
Inside of SANs, that's correct.
> IP addresses should NEVER have been accepted as dNSName.
I think you mean that CAs should never have issued certs with IP addresses
inside of dNSName strings. I absolutely agree. But regardless, NSS will
never look for an IP address in a dNSName string, so is not vulnerable.
--
/Nelson Bolyard