[cabfpub] A few technical details about the case by TURKTRUST

mert.ozarar mert.ozarar at turktrust.com.tr
Sat Jan 5 11:55:42 MST 2013


  

Dear Rick,

 Thank you very much for your comments. In order to
clarify what controls have indeed been implemented, we have reworded the
relevant parts of the techincal details document on our web site
(http://turktrust.com.tr/en/kamuoyu-aciklamasi-en.html [5]).

 We
appreciate a lot.

 Best regards, 

Mert 

04.01.2013 21:40, Rick
Andrews yazmış: 

> Mert, 
> 
> Thank you for providing this detailed
information. 
> 
> I have one concern about the post process control
you've put into place. You say that it will check the basicContraints
value against the respective certificate policy. I'm worried that if
that test profile gets put on the production system again, and certs are
issued against it, your post process control will not alert you, because
the test policy would say "add basicConstrains cA=true" and that would
match the issued certificate. 
> 
> I think a safer approach would be to
have a separate system for generating roots and intermediate CAs that
need basicConstraints cA=true. Or, assuming you rarely create roots and
intermediates on the production system, you might consider changing your
post process control to alert you whenever a cert is issued with cA=true
(no matter what the cert profile says). It will warn you whenever you
legitimately create a root or intermediate (and you know you can safely
ignore those). But if it ever alerts you when you were not intentionally
creating a root or intermediate, you would know that the system must
immediately be checked. 
> 
> -Rick 
> 
> FROM:
public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] ON
BEHALF OF mert.ozarar
> SENT: Friday, January 04, 2013 7:33 AM
> TO:
public at cabforum.org
> SUBJECT: [cabfpub] A few technical details about
the case by TURKTRUST 
> 
> Dear All, 
> 
> 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
[1]) 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 [2]). 
> 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 [3]) 
> 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 [4] 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. 
> 
> Best Regards, 
> 
>
TURKTRUST Inc.

  

Links:
------
[1] http://google.com
[2]
http://google.com
[3] http://www.gilgil.net/communities/19714
[4]
http://google.com
[5]
http://turktrust.com.tr/en/kamuoyu-aciklamasi-en.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20130105/ab856b3f/attachment.html 


More information about the Public mailing list