[liberationtech] Another CA Compromise: TurkTrust

Thu Jan 3 17:22:29 PST 2013

TURKTRUST posted more details on Mozilla's security dev group. I'll also
copy my comment on Google's announcement here:

The conclusion of the post notes that Google "may also decide to take
additional action after further discussion and careful consideration,"
which to me hints that the Chrome team, as others, are likely considering
whether to continue including TURKTRUST root. While I fully appreciate the
ramifications of the breach, I would inveigh upon the community to take
time to consider subsequent actions. Unfortunately, due to banking
embargoes against sanctioned states, there are very few CAs that accept
customers from Iran and Syria. TRUSTTRUST and ipsCA (not trusted) are
likely the primary CAs for these audiences. Unfortunately if this CA is
removed, it is likely that the decision will push many sites into the
national, not-trusted and completely compromised CA ParsSign.

https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/aqn0Zm-KxQ0/x1hfTMGwE2AJ

Please find some critical points below about the root cause of the
instance:

•        The case occurred in August 2011 during a software migration
operation, before the first successful ETSI TS 102 042 audit which took
place in November 2011. The sequence of events that led to the mistaken
issuance of two certificates can be best summarized as follows:
•        Prior to June 2011, the certificate profiles on the production
system were exported to the test system, containing a particular number of
certificate profiles.
•        For the sake of testing purposes, 2 more profiles were added that
contain CA extensions.
•        In the meantime, the production system was also updated to meet
the need of demand to contain 3 more SSL certificate profiles. Hence the
production system and the test system appeared to have different number of
profiles by one, and the two sets matched only in the profiles at the date
of the first data migration.
•        The tests were completed before June 30, 2011. It was the
unfortunate event that the production system was patched with the profiles
in the test system, which had happened to contain 2 wrong profiles and
lacked 3 correct profiles.
•        The wrong profiles were only used on August 8, 2011 to issue those
two faulty certificates which were certainly not intended to be sub-CA
certificates.
•        A certificate request on the 10th of August had called the use of
one of the missing profiles, which was drawn to attention by a thrown
exception. In order to fix this the whole set of certificate profiles was
this time replaced to contain all correct profiles. Therefore the problem
had been fixed once and for all although the unfortunate event that the
certificates were mistakenly issued remained hidden.
It is assured that, this clearly identifies the root cause that led to the
generation of faulty certificates. All related data resides in archives,
and the sequence was all traced back to understand what really had
happened. The system had been finally updated on October 17, 2011 and went
through a successful ETSI TS 102 042 audit by KPMG on November 2011.
Although the system is now immune to any such kind of errors, further
preemptive measures are implemented as described below:
One is a post process control for the certificates issued; the other is a
run time control checking the certificate profile for end users.
Via the post process control, the validity period, basic constraints, CRL
distribution point, Authority Info Access (AIA) and the other profile
details are checked after certificate generation according to the
certificate requirements coming from respective certificate policies before
the certificate is delivered to the end customer. The post process control
is planned as a separate and independent service from the certificate
generation module of the CA software.
Via the run time control, the basic constraints are restricted to the end
user certificates.
Both controls have already been implemented.
All OCSP requests and CRL data have already been analyzed to detect any
anomaly during the entire period. The data revealed no anomaly at all.

The following issues are also worth considering at the moment:
1)        One of the mistakenly issued certificates has been revoked before
putting into use upon the request of the customer.
2)        The other certificate was reported to sign a fraudulent
certificate (*.google.com) on December 6, 2012.
3)        Before the December 6, 2012, the certificate was installed on an
IIS as a web mail server.
4)        On December 6, 2012, the cert (and the key) was exported to a
Checkpoint firewall. It was the same day as the issuance of the fraudulent
certificate (*.google.com).
5)        The Checkpoint firewall was said to be configured as MITM. It
appears that the Checkpoint automatically generates MITM certificates once
a CA cert was installed (http://www.gilgil.net/communities/19714)
6)        The second certificate was immediately revoked as soon as it was
brought to TURKTRUST’s attention by Google on December 26, 2012.
7)        The available data strongly suggests that the *.google.com cert
was not issued for dishonest purposes or has not been used for such a
purpose.
8)        There is certainly not a bit of data to show an evidence of a
security breach on TURKTRUST systems.

On Thu, Jan 3, 2013 at 5:09 PM, Nadim Kobeissi <nadim at nadim.cc> wrote:

> Another CA has been found issuing SSL certificates for Google services.
> Mozilla has acted on the issue:
> https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates/
>
> The weird thing is that it's starting to appear less and less crazy to
> just get rid of the CA system and replace it with… nothing. What do you
> guys think?
>
> NK
>
> --
> Unsubscribe, change to digest, or change password at:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>

-- 
*Collin David Anderson*
averysmallbird.com | @cda | Washington, D.C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130103/75c73ab1/attachment.html>