*.google.com certificate issued by DigiNotar and used by Iran government?
Paul van Brouwershaven
Google help forum:
http://www.google.co.uk/support/forum/p/gmail/thread?tid=2da6158b094b225a&hl=en
This mentions a certificate for *.google.com (serial
05:e2:e6:a4:cd:09:ea:54:d6:65:b0:75:fe:22:a2:56) issued by DigiNotar and
used by Iran government?
More details:
http://pastebin.com/ff7Yg663
I created a bugzilla issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=682956
Kind regards,
Paul van Brouwershaven
Networking4all
Kathleen Wilson
This is being urgently worked through according to Mozilla's Security
Bugs Policy:
http://www.mozilla.org/projects/security/security-bugs-policy.html
Mozilla will be providing more information soon. I'll post an update
here when available.
Kathleen
Kathleen Wilson
Please see:
http://blog.mozilla.com/security/2011/08/29/fraudulent-google-com-certificate/
More info and updates to Mozilla products coming soon.
Ian G
>>
>> http://www.google.co.uk/support/forum/p/gmail/thread?tid=2da6158b094b225a&hl=en
>>
>>
>> This mentions a certificate for *.google.com (serial
>> 05:e2:e6:a4:cd:09:ea:54:d6:65:b0:75:fe:22:a2:56) issued by DigiNotar and
>> used by Iran government?
>>
>> More details:
>> http://pastebin.com/ff7Yg663
>>
>> I created a bugzilla issue:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=682956
>>
>> Kind regards,
>>
>> Paul van Brouwershaven
>> Networking4all
>>
>
>
> http://www.mozilla.org/projects/security/security-bugs-policy.html
>
> Mozilla will be providing more information soon. I'll post an update here when available.
The public interest turns on what level of threat this portends. Several questions:
- did the CA get tricked? Did the CA issue under local laws?
- has the usage of the cert led to an actual aggressive attack? As opposed to a demo?
- who was the aggressor?
- what is the damage?
- how indicative these events are?
- how well, if at all, did the immediate defences work? Why did chrome complain? Other browsers say what?
- how well did the remedial defences work? CRLs? OCSP? source-level revocation?
Previous events have been ho-hum. This one looks serious. We know that typically corporations seek to bury their embarrassment, but this doesn't work for the at-risk stakeholders. Each time one if these snafus is buried, credibility for the entire architecture/sector/model goes down.
What do we have to do to get * full * disclosure?
Iang.
Kathleen Wilson
hearsay.
> - did the CA get tricked? Did the CA issue under local laws?
The CA was not tricked into issuing the cert. The CA was hacked.
> - has the usage of the cert led to an actual aggressive attack? As opposed to a demo?
http://www.google.co.uk/support/forum/p/gmail/thread?tid=2da6158b094b225a&hl=en
> - who was the aggressor?
I heard Iran, but I don't recall the source.
> - what is the damage?
TBD
> - how indicative these events are?
In my opinion, I think that CAs should expect to have hackers attempt to
breach their barriers, and precautions should be taken. However, I think
even the best can probably get hacked or compromised in some way, so all
CAs should have plenty of checks and barriers in place. Mal-issuance
should not be able to happen by one hacker. If, for some reason
mal-issuance does happen, it should be caught by the CA very quickly and
appropriate damage control immediately implemented (especially for
high-profile sites where significant, wide-spread damage can be done).
> - how well, if at all, did the immediate defences work? Why did chrome complain? Other browsers say what?
To my knowledge the CA did not contact Mozilla when they learned of the
issue, we were informed by others. I do not know when the CA became
aware of the issue, but I do know that the *.google.com cert was valid
(not revoked) for a significant amount of time (weeks).
> - how well did the remedial defences work? CRLs? OCSP? source-level revocation?
The *.google.com cert was revoked, so presumably the CRL/OCSP defenses
did work for it. However, I do not know if other bad certs were issued
under the DigiNotar Root CA or under their other intermediate CAs. The
current patches to Mozilla products will blacklist all DigiNotar-issued
certificates based on "CN=DigiNotar " in the certificate issuer. Users
will be able to add a certificate override for DigiNotar-issued
certificates that have a notBefore date prior to July 1, 2011. Users
will not be able to add a certificate override for any DigiNotar-issued
certificates with a notBefore date after July 1, 2011, which would
include the *.google.com certificate.
>
> Previous events have been ho-hum. This one looks serious. We know that typically corporations seek to bury their embarrassment, but this doesn't work for the at-risk stakeholders. Each time one if these snafus is buried, credibility for the entire architecture/sector/model goes down.
>
Previous similar events were caught within hours, and if bad certs were
issued they were revoked within hours. Additionally the CA's immediately
contacted Mozilla via Mozilla's Security Bugs policy and informed us of
the exact extent of the issue.
http://www.mozilla.org/projects/security/security-bugs-policy.html
Kathleen
Peter Gutmann
>Please see:
>http://blog.mozilla.com/security/2011/08/29/fraudulent-google-com-certificate/
Quoting:
that will revoke trust in the DigiNotar root
Wow. We've finally found out what it takes to get a browser vendor to pull a
CA root cert.
Peter.
Peter Gutmann
>To my knowledge the CA did not contact Mozilla when they learned of the
>issue, we were informed by others.
Can Ian, and I, and others, now do the "I toldja so" thing? This (requiring
mandatory breach notification from CAs, and measures to deal with various
other things you mention) are exactly the problems we were pushing to get
fixed after Comodogate. They weren't addressed, and now they've bitten the
entire browser-using world again (and in particular a very vulnerable portion
of the browser-using world, subjects of a very repressive government). And
they'll keep coming back again, and again, and again, no matter how hard
Mozilla (and other browser vendors) try to ignore them.
Peter.
Kyle Hamilton
On Mon, Aug 29, 2011 at 8:05 PM, Peter Gutmann <pgu...@cs.auckland.ac.nz> wrote:
> Can Ian, and I, and others, now do the "I toldja so" thing? This (requiring
> mandatory breach notification from CAs, and measures to deal with various
> other things you mention)
First, we have obtained evidence that Iran doesn't currently have the capacity to factor an RSA key.
Second, we have apparently de facto accomplished the "mandatory breach notification from CAs" goal. Mozilla didn't hear about it from DigiNotar, and Mozilla is cutting DigiNotar off.
I hope that I correctly characterize Mozilla's response, as this is the kind of response that we-the-participants-on-this-list have been begging Mozilla to be willing to do.
The problem now is to figure out how to ensure that DigiNotar cannot issue any more certificates that Mozilla will trust. (The notBefore field is untrustworthy, as it comes from the organization that has now been cut off from the gravy train.)
-Kyle H
Jean-Marc Desperrier
> This mentions a certificate for *.google.com (serial
> 05:e2:e6:a4:cd:09:ea:54:d6:65:b0:75:fe:22:a2:56) issued by DigiNotar and
> used by Iran government?
>
> More details:
> http://pastebin.com/ff7Yg663
>
> I created a bugzilla issue:
> https://bugzilla.mozilla.org/show_bug.cgi?id=682956
From what I see, this certificat was not intended to be used as a SSL
server certificate. It does not have the correct extended key usage (but
as it has no extended key usage at all, it's still valid as a SSL server
certificate) and it's certificate policy 2.16.528.1.1001.1.1.1.2.4.1.2.2
is the one for "Person-specific Organisation/Compagny Certificate" in
P12 format.
Cf
http://www.diginotar.com/Portals/0/General%20terms/DigiNotar_CPS_3.5_-_EN.pdf
This identifier is different from the one for SSL server certificate
2.16.528.1.1001.1.1.1.7.6.1.1/2.2, or the policy for EV certs
2.16.528.1.1001.1.1.1.12.6.1.1.1.
It's likely that the issuance procedure/verification were different/more
lax for this kind of certificate than for SSL server certs (Maybe that's
why there has been no check against a list of high value domain name
before issuance, opposite to what's recommended in the latest policy)
As the CPS describes :
3.4.1 Functions and applications of Certificates
The Person-specific Organisation Certificate, also called the
Person-specific Company Certificate, is a Certificate used to identify a
natural person as an employee of an organisation and to guarantee the
integrity and/or confidentiality of the electronic data exchanged by the
User. The Client and User are responsible for the actual existence of
the employee relationship demonstrated by the Certificate.
4.3.2.2 Verification of Person-specific Organisation
Certificate/Person-specific Company Certificate
For an application for a Person-specific Organisation
Certificate/Person-specific Company Certificate, the control measures
described in section 4.3.1 sub 2 are performed for the intended User of
the Certificate.
4.3.1 sub 2 is a verification of the identity of the requester of the
certificate. No domain ownership verification is include as this kind of
certificate is not intended to be used for SSL.
In a normal issuance procedure, I hope the fact the CN of the
certificate looks like a domain name would rise an alarm.
In the current policy, it's required that no information that has not
been verified be put in the certificate, so the requester of such a
Person-specific certificate ought be requested to prove his name is
*.google.com (and fail at this point :-) )
Some remarks at the moment :
- The CA failed to ensure the certificate profile for Person-specific
certificate would only also allow their use in another usage
- The review process here also failed to put this issue in light
=> It would be very useful to make sure we verify this before
authorising any future CA
- If tentative SSL server certificates that do not contain a DNS entry
in the Subject Alternative Name extension were rejected, this
certificate would not be accepted as a server certificate, and it would
go a long way into helping CAs not to do a similar error. We are moving
in this direction since a long time but very slowly.
Peter Gutmann
>It's likely that the issuance procedure/verification were different/more lax
>for this kind of certificate than for SSL server certs (Maybe that's why
>there has been no check against a list of high value domain name before
>issuance, opposite to what's recommended in the latest policy)
They seem to have done no checking whatsoever, since the contact address given
in the cert:
988 27: SEQUENCE {
990 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
995 20: OCTET STRING, encapsulates {
997 18: SEQUENCE {
999 16: [1] 'ad...@google.com'
: }
: }
: }
is unlikely to have approved it being issued to unnamed parties in Iran.
Do we know yet how it was done? Was it a process-level compromise ("Hi, I'd
like a cert for Google, here's my credit card number") or a CA compromise (the
attackers took control of the cert-vending-machine and minted themselves
whatever certs they wanted)?
Peter.
Eddy Nigg
> From what I see, this certificat was not intended to be used as a SSL
> server certificate. It does not have the correct extended key usage
> (but as it has no extended key usage at all, it's still valid as a SSL
> server certificate) and it's certificate policy
> 2.16.528.1.1001.1.1.1.2.4.1.2.2 is the one for "Person-specific
> Organisation/Compagny Certificate" in P12 format.
> Cf
> http://www.diginotar.com/Portals/0/General%20terms/DigiNotar_CPS_3.5_-_EN.pdf
This is an interesting finding, because various claims were made that
those certificates were not affected, e.g. Dutch government business.
Also interesting that they knew about the issuance of the fraudulent
certificates since the 19th of July (a whooping nice days after
issuance), but haven't said a thing:
http://www.vasco.com/company/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg