• SecurityNotes

CAcert notes on security events

This chapter will highlight some of the security events which are related to certificates.

It is good to reread a statement of Bruce Schneier: "Any person can invent a security system so clever that she or he can't think to break it". This is not only meant for the encryption algorithm, the random key used in encryption, but also for the checksum used in certificate signatures.

What is CAcert doing on this? In 2007 CAcert started a restructure and opening up of the technology used, organisation, assurance policy. The pitfall is that lots of possible events will surface and slow down the goal and its mission: affordable and free tools for X.509 certificates and application: a free and open CA. With this the assurance process has increased considerable in quality (Web of Trust on assurance checks) and new CA Root Key (based on SHA-1 algorithm) is generated and will be used for signing certificates in 2009. This Root Key will also be the Key used in the so called "browser CA inclusion list" in 2009.

Conclusion: CAcert is planning improvements which do not need readjustments to these reports but CAcert needs to get the decisions implemented soon and the CAcert Community needs to cooperate on this. CAcert needs all hands on deck....

December 2008: MD5 checksum algorithm usage in issued certificates

A rogue certificate can be made when signature is based on MD5 checksum signing algorithm. This was reported and shown in detail on the computer hacking CCC conference event in December 2008 in Berlin, Germany.

CAcert "Root CA"class 1 serial 00 self signed on 03/30/2003. The later class 3 serial 01 issued on 10/14/2005 is an intermediate certificate and has signature based on MD5.

CAcert signs issued certificates based on SHA-1 checksum from more as 2 years ago (max expiration date is 2 years for issued certificates). So if CAcert has signed in the very past any certificate based on MD5 algorithm the certificate has been expired by now.

A certificate holder is advised to check with which algorithm his certificate is checked: it should be with at least the SHA-1 algorithm. Except if it is a self-signed certificate, in that case the MD5 algorithm usage does not matter. On the other end one should be aware of the experts system tools used to show the manufacturing of such signed information...

There is no certificate expiration relieve : once the certificate is MD5 hashed, RSA signed by the class 1 root cert, you can change any data in the certificate, so upto now an expert can make an old expired certificate looking brand new (AFAIK).

SHA-2: The strength against collision attacks against SHA-1 has been proofed in 2005. SHA-1 is scheduled to be decertified in 2010. The stronger SHA-2 algorithm is argued to be better but is not commonly available (OpenSSL has no full support in 2008 for SHA-2) or wildly supported (Mozilla claims to be ready) yet. But the pressure is high to disseminate the SHA-2 now. In 2010 CAcert will need to replace the Root Key certificates as soon as OpenSSL, Mozilla and Microsoft have added SHA-2 in the main stream.

The CAcert Root certificates have been created before the MD5 collision report in 2004. At that time it was reported already that it should be possible to create information with an MD5 checksum that would be similar to a previous defined MD5 checksum. In the end of 2008 a report showed a that this (certificates were used in this exercise) could be practically be done.

Conclusion: issued certificates signed with the MD5 checksum algorithm can eventually be forged and so can be considered harmful.

More information on these issues:

• Boffins bust web authentication with game consoles http://www.theregister.co.uk/2008/12/30/ssl_spoofing/

• Experts uncover weakness in Internet security http://www.eurekalert.org/pub_releases/2008-12/epfd-euw123008.php

• comment about PKIs, Certification Authorities, etc http://www.garlic.com/~lynn/2008s.html#76

• MD5 considered harmful today http://www.win.tue.nl/hashclash/rogue-ca/

• Researchers' Web Certificate Hack Highlights Big Internet Flaw http://www.crn.com/security/212700246

• Certificate Flaw May Threaten Secure Web Sites http://www.internetnews.com/security/article.php/3793816/Certificate+Flaw+May+Threaten+Secure+Web+Sites.htm

• Exploits & Vulnerabilities: Security Wonks Find Gaping Hole in Trusted Site System http://www.ecommercetimes.com/story/65684.html

• Researchers Show How to Forge Site Certificates Freedom to Tinker http://www.freedom-to-tinker.com/blog/felten/researchers-show-how-forge-site-certificates

• 25C3: MD5 considered harmful today http://events.ccc.de/congress/2008/Fahrplan/events/3023.en.html

• Researchers Use PlayStation Cluster to Forge a Web Skeleton Key http://blog.wired.com/27bstroke6/2008/12/berlin.html

• SMBlog -- exploited the collision weakness in MD5 http://www.cs.columbia.edu/~smb/blog//2008-12/2008-12-30.html

• Security Scene Errata - Charlatans http://attrition.org/errata/charlatan.html

• MD5 Hack Is Not a Threat, Microsoft Says http://www.pcworld.com/businesscenter/article/156191/md5_hack_is_not_a_threat_microsoft_says.html

• Microsoft: MD5 hack poses no major threats to users http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9124564

• Microsoft: MD5 hack poses no major threats to users http://www.infoworld.com/article/08/12/31/Microsoft_MD5_hack_poses_no_major_threats_to_users_1.html

• Microsoft: Regarding MD5 collision and Microsoft released a security advisory (961509) http://blogs.technet.com/swi/archive/2008/12/30/information-regarding-md5-collisions-problem.aspx

• Researchers devise undetectable phishing attack http://www.infoworld.com/article/08/12/30/Researchers_devise_undetectable_phishing_attack_1.html

• Research on SHA-1 collisions: NIST http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html , RSA Laboratories http://www.rsa.com/rsalabs/node.asp?id=2927 and Graz University of Technology http://boinc.iaik.tugraz.at/sha1_coll_search/

December 2008: domain validation control on website bypassed

The domain validation controls on the website of a CA were bypassed by changing the paramaters after the checking was done. This is a basic programming error; controlled state should not be changeable.

This looks basically the same as the CAcert exploit discovered by a Member some months back. In that case, the results of prior checking were changeable using register_globals.

Conclusion: more care needed in the website PHP programming. The level of security programming that is needed is higher than in ordinary website design.

References:

• https://blog.startcom.org/?p=161

December 2008: a server certificate on any domain name could be obtained without verification

A reseller was selling certificates on domains without completing the required checking on whether the domain was controlled or not. This enabled the purchase of a domain under any name.

Although the checks were in place or available, they had failed somehow (details have not been released). It is not clear whether the checks should be done at the CA or the reseller. This is highly distinct to CAcert which does not have "resellers" although it does pass the Assurance function to its Assurers.

Conclusions.

1. A single check may fail. CAcert has a policy decision p20090105.1 of requiring at least these checks:

   • one point at least from an Assurance, ensuring a signed CAP form
   • two checks from the list: email ping to Whois or RFC addresses, DNS or HTTP cookie, statement of 2 assurers
2. Note that these are not implemented as yet.
   • only one check is required technically at the moment,
   • new subroot for unassured Members will not be usable until fixed.
3. The difference between the reseller and the CA is somewhat irrelevant for CAcert, as it has no resellers or sub-CAs. Assurance process is distinct and is diversified from single points of failure.
4. Aggressive and unbecoming behaviour of one CA to another CA has overshadowed the value of this exploit. Written reports are unreliable and commercially biased.

References:

• Untrusted certificates post from Eddy Nigg on December 23, 2008 https://blog.startcom.org/?p=145

December 2008: Questionable practices in selling certs

The same CA as above complained about the practice of other CA/resellers emailing certificate subscribers offering them "renewals".

Conclusion: a commercial issue, outside likely scope of CAcert.

• Questionable business practices of an SSL Certificate reseller http://www.sslshopper.com/article-ssl-certificate-for-mozilla.com-issued-without-validation.html

14th August 2008 false cert possibility

The CAcert issuance of certificates had a vulnerability that permitted an attacker to add arbitrary email addresses without verification. Read more...

Conclusion: more care needed in the website PHP programming. The level of security programming that is needed is higher than in ordinary website design.

Other refs

• Principles says "We commit to full disclosure of security breaches" amongst other things.

• the blog is the place for reports.

• CategoryCustom