HackDig : Dig high-quality web security articles

Questioning the chain of trust: investigations into the root certificates on mobile devices

2014-10-15 12:55

Questioning the chain of trust: investigations into the root certificates on mobile devices

A decade ago, I observed that commercial certificate authorities protect you from anyone from whom they are unwilling to take money. That turns out to be wrong; they don’t even do that much.”

- Matt Blaze, http://www.crypto.com/blog/spycerts/

Summary:
All SSL connections rely on a chain of trust. This chain of trust, a part of PKI, is established by certificate authorities (CAs), which serve as trust anchors to verify the validity of who a device thinks it is talking to. However, there are literally hundreds of CAs installed by default on your smartphone, some of which have cause for concern in their inclusion. In this report we do a deep dive from the perspective of Android, with comparisons drawn to iOS, to examine the CAs that come preloaded on these devices and the details about them.

Table of Contents:
Overview of Trusted Roots
Historical/Known Failures in Keeping Trust
Roots of Trust in Mobile: Android Analysis
Government-Based Roots of Trust
Cause for Concern: Entities that Need Consideration
Further Cause for Concern: Android Missing Artificial Constraints
Cryptographic Strength of the Roots of Trust
Controlling Interests in the Roots of Trust
Looking Forward: Entities In-Progress of Becoming Trusted
Addendum: Apple’s Extended Circle of Trust on IOS
Taking trust into your own hands
Appendix: Certificate Authority Subjects

Overview of Trusted Roots

Google and other(s) have renewed a push toward websites using HTTPS[1]. This is a great initiative since it increases the overall security posture. HTTPS utilizes SSL/TLS, which in turn involve a cryptographic certificate to validate the identity of a website or network service. For this to work, there needs to be a basis of trust, where central trusted entities attest to the proper identity of an SSL/TLS service. These central trust authorities will sign/issue a website’s identity certificate, on faith that the central authority’s signature is evidence that the certificate is genuine for the indicated identity. In order to make the trust chain work correctly, the certificate from the CA needs to be installed on the device attempting to make the secured connection. The certificate from the CA acts as a verification point that the site the device is talking to is indeed who it claims to be, which can be referred to as a trust anchor. Mobile devices and traditional computers alike are loaded with hundreds of root certificates that allow them to talk securely to the variety of sites that have paid these CAs to prove these sites are who they say they are.

For example, looking at the certificate used by the website “www.google.com”, in a web-browser we can see that the certificate is chained to and ultimately verified against a pre-installed root certificate for Equifax Secure Certificate Authority on this computer.

Root CA blog - 1

The www.google.com certificate chain of trust goes through two intermediate certificates: one from GeoTrust and another from Google’s own Internet Authority. Google does not operate their own root CA; instead, the operations and actions (relating to the signing/issuing of identity certificates) of Google’s Internet Authority G2 sub-CA are affirmed & trusted by the GeoTrust Global CA intermediate CA. In turn, GeoTrust’s operations and actions are affirmed & trusted by the Equifax Secure Certificate Authority root CA. By having a device trust Equifax, the device forms a transitive trust with everyone Equifax trusts (such as GeoTrust), and everyone that entity trusts, and so on.

On a mobile device, if the chain of trust cannot be verified to a known trusted root CA (because the certificate does not exist or has been disabled), then a web browser may show something like the images below. This occurs because the web browser cannot find any trusted certificates that are suitable to validate the identity claimed by the website/network service. That, in turn, implies the trust chain cannot be verified back to a known, trustable entity.

Root CA blog 2

Where do these central authorities come from, and how do they wind up in a device’s collection of trusted certificates? Typically the process requires review, verification, & approval by established entities or industry bodies that represent the interests of the Internet user base. Mozilla, the entity behind the very popular Firefox web browser, has established themselves as an industry leading committee that oversees the process of reviewing, verifying, and approving potential CAs for inclusion into the Mozilla common trust store. A recent overview of the latest process can be read here:
https://blog.mozilla.org/security/2014/05/13/checking-compliance-status-with-updated-ca-certificate-policy/

Since the Mozilla process for review and approval is well established and appropriate, many other parties in the industry simply clone the collection of CAs used by Mozilla into their own products. It is typical to find most collections of trusted root CAs are simply clones of the Mozilla maintained collection. We found this to be the case with many mobile operating systems, including Android in particular.

Root CA blog 3

Historical/Known Failures in Keeping Trust

The effectiveness of the global PKI trust infrastructure relies on keeping the designated roots of trust fully secure and operating correctly. Alas, there have been some publicly documented CA compromises that have disrupted the worldwide implicit trust system.

“Hacked” CAs:

Apple publicly maintains a list of certificates that are explicitly not trusted[2].

Apple Blocked Certificates:

  • Turktrust issued an inappropriate sub-CA cert
  • Entrust inappropriately issued a wildcard cert for Apple domains
    • Issued Date: 6/4/2013
  • GTE CyberTrust Solutions issued four sub-CA certs for DigiNotar
    • Now blocked as part of DigiNotar compromise
    • Issued Date: 9/20/2006, 9/20/2006, 9/27/2006, 10/4/2006
  • DigiNotar Issued itself another sub-CA cert
    • Now blocked as part of DigiNotar compromise
    • Issued Date: 2/6/2006
  • Entrust issued three sub-CA certs for DigiNotar
    • Now blocked as part of DigiNotar compromise
    • Issued Date: 4/26/2007, 7/26/2007, 7/26/2007
  • Entrust issued a sub-CA cert for Digicert Sdn. Bhd.
    • The (sub-)CA practices of Digicert Sdn. Bhd. in Malaysia were found to be in appropriate, including the use of weak 512-bit issued certificates, no EKU constraints, and no inclusion of CRL/revocation pointers. Further, there are confirmed cases of the weak 512-bit certificates being used to sign malware.
      https://bugzilla.mozilla.org/show_bug.cgi?id=698753
    • Issued Date: 7/16/2010
  • GTE issued a sub-CA cert for Digicert Sdn. Bhd.
    • The (sub-)CA practices of Digicert Sdn. Bhd. in Malaysia were found to be inappropriate, including the use of weak 512-bit issued certificates, no EKU constraints, and no inclusion of CRL/revocation pointers. Further, there are confirmed cases of the weak 512-bit certificates being used to sign malware.
      https://bugzilla.mozilla.org/show_bug.cgi?id=698753
    • Issued Date: 7/17/2011
  • Trustwave issued a sub-CA cert to Micros Systems
  • XRamp issued a sub-CA cert to Trustwave
    • Now blocked as part of the Trustwave/Micros Systems incident
    • Issued Date: 12/22/2008
  • TurkTrust inappropriately issued a sub-CA cert to KKTC Merkez Bankasi
    • Issued Date: 8/8/2011

Roots of Trust in Mobile: Android Analysis

Disclaimer:

Note that our intent is to provide this list as convenience for people to make informed decisions about who they trust. Unless noted later (under the “Cause for Concern” section), there is no specific identified concern by the entities listed below. However, we understand that individual preferences and motivations vary, and select individuals may wish to adjust their circle of trust according to their own geopolitical reasons.

The latest Android operating system, KitKat 4.4.4, ships with 156 pre-installed root CA certificates; since these certificates come pre-installed on the device, they are referred to as “system certificates”. Android also allows the user to install other additional trusted certificates for their own personal reasons; these are referred to as “user certificates”. In comparison, Apple’s iOS 8 ships with 223 system certificates.

One of the missions of Bluebox Labs is to understand, verify, and augment capabilities to make a mobile device safe and trustable for personal and corporate use. So we took the initiative to research all 156 certificates included in the Android system, to better understand their origin and how well they uphold a reasonable expectation of someone’s trust.

From our investigations we encountered a variety of certificate authorities. Some of the CAs are issued by well-known companies, others by government entities, a few by smaller lesser known CAs, and a few by research institutions acting as CAs. From the CAs we investigated, we found a few that can be considered cause for concern for a variety of reasons. We further investigated the origins and owners of the CAs and noticed several instances of CA consolidation, smaller companies being bought and acquired by larger companies thus consolidating the root of trust to fewer owning entities than indicated by the actual CA count.

Government-Based Roots of Trust

These are known government certificate authorities, based on the involved entity names and/or evidence found as part of the inclusion process review paper trail. The list was started from data taken from a page Mozilla maintains on the topic: https://wiki.mozilla.org/CA:GovernmentCAs. Further research and collected evidence was used to augment the list.

In addition, there are entities that are suspected to be government-sponsored or acting on behalf of a government. There are many geographical regions where notable opinion exists to not favor a particular government; at times, other entities may appear to exist independent of the government, but in fact there is evidence or strong popular opinion that the entity is colluding with the government. Since the root CA inclusion review process involves a community feedback opportunity, we noted where there was a strong community belief or stance against an entity due to suspected government affiliation.

Root CA blog 4

Cause for Concern: Entities that Need Consideration

The general root CA inclusion process is open for anyone to be considered for inclusion — this allows any entity, no matter how small or narrow their practical authority scope is, to potentially be included as a trusted root CA for billions of systems world-wide. This includes private entities and entities that exist for purely academic or research purposes, where their operations are only intended for a small set of networks. In other cases, the community feedback or other industry evidence has indicated the CA entity may have exhibited a compromise to the integrity of their process, resulting in inappropriately issued certificates that shouldn’t be trusted or otherwise calling into question the trustability of the entity.

The following root CAs were noted due to various reasons such as:

  • Extended community discussion regarding certificate removal from the collection
  • The certificate is subject to recent expiration or the CA is deprecated
  • There was controversy as part of the inclusion review process
  • There was controversy in the actions/operations of the CA that undermine their trustability

For more details on each CA please see the appendix

Root CA blog 5

 

Root CA blog 6

Further Cause for Concern: Android Missing Artificial Constraints

Our research discovered two cases where an entity in control of a root CA certificate had a confirmed trust failure, and due to various undisclosed reasons, the principal industry leaders (Google, Mozilla) chose to retain the inclusion of the root CA certificate yet overlay artificial name constraints on the certificate. This is effectively identical to the certificate including an X509v3 Name Constraints extension to limit the TLDs the CA is allowed to represent, except the literal certificate doesn’t include the constraints — it’s the certificate processing code that overlays these extra constraints for specific certificates.

http://googleonlinesecurity.blogspot.com/2014/07/maintaining-digital-certificate-security.html

http://googleonlinesecurity.blogspot.com/2013/12/further-improving-digital-certificate.html

You can view the literal hard-coded overlaid name constraint logic in the Mozilla Firefox and Google Chromium codebase:

http://dxr.mozilla.org/mozilla-central/source/security/nss/lib/certdb/genname.c (starting at line 1559)

http://src.chromium.org/svn/trunk/src/net/cert/cert_verify_proc.cc (in HasNameConstraintsViolation())

Currently, only one of these two certificates is present in standard Android:

  • 2.840.113549.1.9.1=#161469676361407367646e2e706d2e676f75762e6672,CN=IGC/A,OU=DCSSI,O=PM/SGDN,L=Paris,ST=France,C=FR

This creates an interesting situation for Android devices, as it requires certificate processing logic to externally constrain the certificate. Unfortunately, not all avenues involving the use of the system root certificates properly add these artificial constraints. Our analysis currently reveals that:

  • Android 4.3 and prior use the WebKit engine for app WebView UIs; our analysis was unable to locate any artificial constraint logic, leading us to currently believe that apps running on Android prior to Android 4.4 are at risk of abuse by any inappropriately issued sub-CA entities chained to the suspect root CA certificate.
  • Beyond the framework WebView UIs, we were unable to locate any other artificial constraint logic in Android outside the specific uses of the WebView UI. This means all direct SSL/TLS uses of OpenSSL, BouncyCastle, JSSE, etc., whether directly at the network level or abstractly at a higher level (HttpClient, HttpsUrlConnection, etc.), are at risk of abuse by any inappropriately issued sub-CA entities chained to the suspect root CA certificate.

Cryptographic Strength of the Roots of Trust

The entire Public Key Infrastructure (PKI) is built on technology that heavily involves the use of cryptography. As time has marched on, the increase in computing power combined with new mathematical analysis techniques has caused a constant pressure to seek better cryptographic algorithms and bigger key sizes. For example, 1024-bit RSA keys may have been considered acceptable 10 years ago, but current standards prefer larger key sizes. In fact, NIST (US government body that established security recommendations for the industry) recommended 1024-bit based certificates start phasing out in 2010 and be disallowed starting in 2014[3]. In their advisement, NIST indicates that continuing to use 1024-bit certificates for digital verification after 2013 (i.e. within the “legacy-use” period),should do so knowing that the verification may be subject to various attacks.

We noticed the Mozilla CA review process was actively re-reviewing entities that were still issuing certificates with less than 2048 bits, per the NIST December 2013 deadline to deprecate the issuing of 1024-bit certificates. Google has publicly encouraged the use of 2048-bit keys as a minimum[4]. Since a CA may issue certificates that will be valid for many years to come, it is important that an appropriately strong level of encryption be chosen, so that the certificate will not be subject to attack in the future. Our research found there are still 15 root CA certificates on Android that are using a 1024-bit key as shown in a previous section.[5]

Public Key Size Distribution:

Root CA blog chart 1 v5

NIST has also made recommendations on the use of hashing functions in the generation of the certificates. The recommendations outline that MD5 is no longer a valid algorithm to be using, however there are 6 certificates still using it today.   Additionally, Google is pushing for the end of use of SHA-1 in the hashing algorithms for certificates[6]. Currently there are 115 certificates in Android using SHA-1.

Hash algorithm used for signature:

Root CA blog chart 2 v2

Controlling Interests in the Roots of Trust

Once a root CA establishes trust into the ecosystem, it can issue many millions of certificates with far reaching expiration dates — which means it’s usually around for quite a while. There are cases where CAs have gone out of business, or have been acquired and consolidated by larger corporations. Our review of the core 156 certificates yielded an interesting history of how these roots of trust were bought and sold.

Symantec has turned out to be the most prolific acquirer of discrete legacy root certificate authorities. Symantec directly or indirectly acquired six multi-entity root CA entities, and represents the controlling interest for 26 of the total 156 certificates installed on an Android device.

Root CA blog chart 3 v2

 

The figure below illustrates the relationships of CA ownership & consolidation amongst corporate entities. The blue colored circles indicate an active CA certificate in Android. The other circles indicate other corporate entities that have acquired or been acquired by a CA as indicated by the directional arrows.

Root CA blog 7

Looking Forward: Entities In-Progress of Becoming Trusted

The Mozilla CA verification process is publicly visible, which makes it possible to see which entities are currently undergoing the process for consideration of inclusion into the trusted roots collection.

As of August 2014, there are currently 66 new certificate additions (from 44 separate operating entities) in various states of the Mozilla review process.

Addendum: Apple’s Extended Circle of Trust on IOS

Through our research we noticed that IOS 7 contains significantly more trusted root entities than Android — 223 (iOS) vs 156 (Android).

We were concerned by the significant number of extra parties, so we further analyzed how the IOS collection of trusted roots varies from the Android collection. The raw list of trusted root entities is provided by Apple at http://support.apple.com/kb/ht5012.

We’ve identified 20 certificates included in IOS that are still in-progress of the Mozilla review process (see the “Looking Forward” section). We attribute this to differences (particularly the speed of the review) between the Apple vs. Mozilla vetting processes.

There’s a notable number of inclusions (37 total certificates) specifically from existing established commercial CA organizations: DigiCert, Equifax, Symantec, VeriSign, UserTrust.com, TC TrustCenter, and Thawte. An additional 10 certificates are new root certificates from entities that already have a presence in the certificate collection.

We did notice a bigger US federal government presence in the Apple certificate collection. One of the included US federal certificates is undergoing review by Mozilla, but the remainder seem exclusive to IOS.

US Federal Certificates:

  • C=US, O=U.S. Government, OU=FPKI, CN=Federal Common Policy CA
    • Currently undergoing Mozilla review for inclusion
  • C=US, O=U.S. Government, OU=DoD, OU=PKI, CN=DoD CLASS 3 Root CA
  • C=US, O=U.S. Government, OU=DoD, OU=PKI, CN=DoD Root CA 2
  • C=US, O=U.S. Government, OU=ECA, CN=ECA Root CA
  • C=us, O=U.S. Government, OU=FBCA, CN=Common Policy
    • Not present on Android

Entities Present on IOS, Requested For Removal on Mozilla/Android:

Other Entities added by Apple:

  • C=US, O=Apple Computer, Inc., OU=Apple Computer Certificate Authority, CN=Apple Root Certificate Authority
  • C=US, O=Apple Inc., OU=Apple Certification Authority, CN=Apple Root CA
  • CN=Apple Root CA – G2, OU=Apple Certification Authority, O=Apple Inc., C=US
  • CN=Apple Root CA – G3, OU=Apple Certification Authority, O=Apple Inc., C=US
  • CN=Developer ID Certification Authority, OU=Apple Certification Authority, O=Apple Inc., C=US
    • Apple’s own CAs
  • C=BE, CN=Belgium Root CA
  • C=BE, CN=Belgium Root CA2
  • C=CA, ST=Ontario, L=Toronto, O=Echoworx Corporation, OU=Certification Services, CN=Echoworx Root CA
  • C=CZ, CN=I.CA – Qualified Certification Authority, 09/2009, O=První certifikační autorita, a.s., OU=I.CA – Accredited Provider of Certification Services
  • C=DK, O=KMD, OU=KMD-CA, CN=KMD-CA Kvalificeret Person
  • C=DK, O=KMD, OU=KMD-CA, CN=KMD-CA Server/mail=infoca@kmd-ca.dk
  • C=DK, O=TRUST2408, CN=TRUST2408 OCES Primary CA

CAs in iOS 7.1.2 that were removed in iOS 8:

  • Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting, OU=Certification Services Division, CN=Thawte Personal Basic CA/emailAddress=personal-basic@thawte.com
  • Subject: C=US, O=Entrust.net, OU=www.entrust.net/CPS incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Secure Server Certification Authority
  • Subject: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert Class 2 Policy Validation Authority, CN=http://www.valicert.com//emailAddress=info@valicert.com
  • Subject: C=JP, O=Japan Certification Services, Inc., CN=SecureSign RootCA11
  • Subject: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert Class 1 Policy Validation Authority, CN=http://www.valicert.com//emailAddress=info@valicert.com
  • Subject: C=US, O=AOL Time Warner Inc., OU=America Online Inc., CN=AOL Time Warner Root Certification Authority 1
  • Subject: C=US, O=AOL Time Warner Inc., OU=America Online Inc., CN=AOL Time Warner Root Certification Authority 2
  • Subject: C=US, O=Equifax Secure, OU=Equifax Secure eBusiness CA-2
  • Subject: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert Class 3 Policy Validation Authority, CN=http://www.valicert.com//emailAddress=info@valicert.com
  • Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting, OU=Certification Services Division, CN=Thawte Personal Premium CA/emailAddress=personal-premium@thawte.com

Taking trust into your own hands

Generally speaking, the industry standard collection of 150+ trusted root CAs represents the aggregate trusted authorities for all possible users worldwide. It’s a collection that tries to be everything to everyone.

However, on an individual level, that amount of trust is significantly expansive and crosses the threshold of being too trusting. When you compound the matter with the confirmed or speculated operational failures or hidden agendas of these root CAs, the choice to trust a non-essential root CA can leave your mobile device open to unnecessary potential risk.

Fortunately, there is an opportunity to reduce your circle of trust: disable unnecessary root CAs, alleviating you from any transitive risk caused by that trusted entity. We strongly encourage everyone to at least start with the entities listed in the “Cause for Concern” section, and consider disabling those certificates if you personally feel the circumstances regarding that entity are questionable for your personal trust needs.

Next you should further consider disabling the various entities that are trust authorities for distant geographic regions you don’t participate in. You can limit your trust to the entities that provide CA services to the geographic regions that are relevant to you.

Android users:

You can manually disable individual root CA certificates by navigating to Settings -> Security -> Trusted credentials -> System, then choosing an entity from the list and scrolling to the bottom of the screen to find the ‘Disable’ button. Unfortunately, this process to select an entity then scroll to the Disable button must be repeated for every certificate you wish to disable.

You can safely disable as many certificates as you wish. Later, if you find that you get security errors or are unable to access a network service, you can re-enable selective certificates to locate the one that may be essential for that specific service. It may take a little bit of trial and error to find the perfect minimal set of necessary certificates for your needs, but it’s a safe process that won’t cause any permanent damage to your device.

IOS users:

Unfortunately, IOS offers no method to disable the certificates in the Apple-provided trust store. There may be an opportunity to edit the certificate trust store on jailbroken devices, where a user is willing and capable of performing the jailbreak process.

Appendix: Certificate Authority Subjects

Government CAs:

  • Government of France
    • 2.840.113549.1.9.1=#161469676361407367646e2e706d2e676f75762e6672,CN=IGC/A,OU=DCSSI,O=PM/SGDN,L=Paris,ST=France,C=FR
  • Government of Hong Kong
    • CN=Hongkong Post Root CA 1,O=Hongkong Post,C=HK
  • Government of Japan
    • OU=ApplicationCA,O=Japanese Government,C=JP
  • Government of Spain (ACCV)
    • C=ES,O=ACCV,OU=PKIACCV,CN=ACCVRAIZ1
  • Government of The Netherlands (PKloverheid)
    • CN=Staat der Nederlanden Root CA,O=Staat der Nederlanden,C=NL
    • CN=Staat der Nederlanden Root CA – G2,O=Staat der Nederlanden,C=NL
  • Government of Taiwan (GRCA)
    • O=Government Root Certification Authority,C=TW
  • Government of Turkey (Kamu SM)
    • CN=TÜBİTAK UEKAE Kök Sertifika Hizmet Sağlayıcısı – Sürüm 3,OU=Kamu Sertifikasyon Merkezi,OU=Ulusal Elektronik ve Kriptoloji Araştırma Enstitüsü – UEKAE,O=Türkiye Bilimsel ve Teknolojik Araştırma Kurumu – TÜBİTAK,L=Gebze – Kocaeli,C=TR
  • KISA, Government of Korea
    • C=KR, O=KISA, OU=Korea Certification Authority Central, CN=KISA RootCA 3
    • C=KR, O=KISA, OU=Korea Certification Authority Central, CN=KISA RootCA 1
  • Spanish FNMT
    • C=ES, O=FNMT, OU=FNMT Clase 2 CA
  • Government of Spain (CAV), Izenpe S.A.
    • C=ES, O=IZENPE S.A., CN=Izenpe.com

Suspected of being affiliated with a government entity:

  • China Internet Network Information Center (CNNIC) [China]
    • CN=CNNIC ROOT,O=CNNIC,C=CN
  • HARICA (Hellenic Academic and Research Institutions) [Greece]
    • CN=Hellenic Academic and Research Institutions RootCA 2011,O=Hellenic Academic and Research Institutions Cert. Authority,C=GR
  • Japan Certification Services, Inc. (JCSI) — public corporation [Japan]
    • CN=SecureSign RootCA11,O=Japan Certification Services, Inc.,C=JP
  • Camerfirma — commercial CA, digital CA for Chambers of Commerce in Spain [Spain]
    • C=EU, O=AC Camerfirma SA CIF A82743287, OU=http://www.chambersign.org, CN=Global Chambersign Root
    • C=EU, L=Madrid (see current address at www.camerfirma.com/address)/serialNumber=A82743287, O=AC Camerfirma S.A., CN=Chambers of Commerce Root – 2008
  • CATCert — Catalan Agency of Certification provides signatures within Catalan government [Spain]
    • C=ES, O=Agencia Catalana de Certificacio (NIF Q-0801176-I), OU=Serveis Publics de Certificacio, OU=Vegeu https://www.catcert.net/verarrel (c)03, OU=Jerarquia Entitats de Certificacio Catalanes, CN=EC-ACC
  • Certicámara S.A. — public corporation [Columbia]
    • Subject: C=CO, O=Sociedad Cameral de CertificacixC3xB3n Digital – CerticxC3xA1mara S.A., CN=AC RaxC3xADz CerticxC3xA1mara S.A.
  • Chunghwa Telecom Corporation — public corporation, integrated telecom operator in Taiwan [Taiwan]
    • C=TW, O=Chunghwa Telecom Co., Ltd., OU=ePKI Root Certification Authority
  • TurkTrust — public corporation [Turkey]
    • O=TÜRKTRUST Bilgi İletişim ve Bilişim Güvenliği Hizmetleri A.Ş. (c) Kasım 2005,L=Ankara,C=TR,CN=TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı
    • O=TÜRKTRUST Bilgi İletişim ve Bilişim Güvenliği Hizmetleri A.Ş. (c) Aralık 2007,L=Ankara,C=TR,CN=TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı
    • O=TÜRKTRUST Bilgi İletişim ve Bilişim Güvenliği Hizmetleri A.Ş. (c) Kasım 2005,L=Ankara,C=TR,CN=TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı
  • e-tugra — privately held organization [Turkey]
    • Subject: C=TR, L=Ankara, O=E-TuxC4x9Fra EBG BilixC5x9Fim Teknolojileri ve Hizmetleri A.xC5x9E., OU=E-Tugra Sertifikasyon Merkezi, CN=E-Tugra Certification Authority
  • e-Guven Elektronik Bilgi Guvenligi A.S. — private corporation, customers include government [Turkey]
    • C=TR, O=Elektronik Bilgi Guvenligi A.S., CN=e-Guven Kok Elektronik Sertifika Hizmet Saglayicisi
  • Autoridad Certificadora Raíz Nacional de Uruguay (ACRN)- the root of the chain of trust of the Uruguayan National PKI [Spain]
    • C=ES, CN=Autoridad de Certificacion Firmaprofesional CIF A62634068

Other nationally-operating entities:

  • French Postal Service:
    • CN=Certinomis – Autorité Racine,OU=0002 433998903,O=Certinomis,C=FR
  • Switzerland Post Office:
    • CN=SwissSign Gold CA – G2,O=SwissSign AG,C=CH
    • CN=SwissSign Silver CA – G2,O=SwissSign AG,C=CH

Concerning Entities:

  • CN=Secure Global CA,O=SecureTrust Corporation,C=US
  • CN=SecureTrust CA,O=SecureTrust Corporation,C=US
    • The CA issued at least one global wildcard sub-CA cert to an organization, effectively allowing that organization to perform arbitrary MitM data interception or otherwise masquerade as any legitimate HTTPS website. https://bugzilla.mozilla.org/show_bug.cgi?id=724929
    • “After much discussion in security-group and mozilla.dev.security.policy it was decided that only the offending subordinate CA certificate would be distrusted. The Trustwave root certificates were not removed.”
      https://bugzilla.mozilla.org/show_bug.cgi?id=724929#c93
  • CN=AC Raíz Certicámara S.A.,O=Sociedad Cameral de Certificación Digital – Certicámara S.A.,C=CO
  • CN=Staat der Nederlanden Root CA,O=Staat der Nederlanden,C=NL
  • CN=Staat der Nederlanden Root CA – G2,O=Staat der Nederlanden,C=NL
  • CN=StartCom Certification Authority,OU=Secure Digital Certificate Signing,O=StartCom Ltd.,C=IL
  • CN=StartCom Certification Authority G2,O=StartCom Ltd.,C=IL
  • CN=StartCom Certification Authority,OU=Secure Digital Certificate Signing,O=StartCom Ltd.,C=IL
    • There is community controversy caused by the wake of Heartbleed attacks; namely, due to Heartbleed, it may be necessary for many sites to have re-issued SSL certificates. However, StartCom’s policies are to pay a fee for revocation, which impacts the choice to recover from potentially compromised certificates. This is leaving a large part of the ecosystem in a position to keep using the potentially compromised certificates.
      https://bugzilla.mozilla.org/show_bug.cgi?id=994033
    • Note: there are two certs with same Subject but different SHA1’s & serial numbers
  • OU=TDC Internet Root CA,O=TDC Internet,C=DK
  • O=TÜRKTRUST Bilgi İletişim ve Bilişim Güvenliği Hizmetleri A.Ş. (c) Aralık 2007,L=Ankara,C=TR,CN=TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı
  • CN=Hellenic Academic and Research Institutions RootCA 2011,O=Hellenic Academic and Research Institutions Cert. Authority,C=GR
    • This is an academic and research entity that issues certificates for a small private collection of university systems. Unless you are a part of that network, there is no benefit to including this CA, but it does open one to the risks if there is a failure in the trust operations or actions of this entity. This certificate includes name constraints that will limit it’s use to *.gr, *.eu, *.edu, and *.org domains — but that can still represent significant exposure.
    • “Certificate must only be used for academic, research or educational purposes”
      https://bugzilla.mozilla.org/show_bug.cgi?id=581901
    • There was Mozilla controversy in the review & inclusion process:
      https://bugzilla.mozilla.org/show_bug.cgi?id=711594
  • 2.840.113549.1.9.1=#161469676361407367646e2e706d2e676f75762e6672,CN=IGC/A,OU=DCSSI,O=PM/SGDN,L=Paris,ST=France,C=FR
  • CN=CNNIC ROOT,O=CNNIC,C=CN
  • CAs that are using a 1024 bit key:
    • Subject: C=ES, O=FNMT, OU=FNMT Clase 2 CA
    • Subject: C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root
    • Subject: C=US, O=Equifax, OU=Equifax Secure Certificate Authority
    • Subject: C=US, O=Equifax Secure Inc., CN=Equifax Secure Global eBusiness CA-1
    • Subject: C=US, O=Equifax Secure Inc., CN=Equifax Secure eBusiness CA-1
    • Subject: C=HU, L=Budapest, O=NetLock Halozatbiztonsagi Kft., OU=Tanusitvanykiadok, CN=NetLock Uzleti (Class B) Tanusitvanykiado
    • Subject: C=HU, L=Budapest, O=NetLock Halozatbiztonsagi Kft., OU=Tanusitvanykiadok, CN=NetLock Expressz (Class C) Tanusitvanykiado
    • Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority – G2, OU=(c) 1998 VeriSign, Inc. – For authorized use only, OU=VeriSign Trust Network
    • Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
    • Subject: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert Class 3 Policy Validation Authority, CN=http://www.valicert.com//emailAddress=info@valicert.com
    • Subject: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert Class 2 Policy Validation Authority, CN=http://www.valicert.com//emailAddress=info@valicert.com
    • Subject: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert Class 1 Policy Validation Authority, CN=http://www.valicert.com//emailAddress=info@valicert.com
    • Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
    • Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Server CA/emailAddress=server-certs@thawte.com
    • Subject: C=US, O=Entrust.net, OU=www.entrust.net/CPS incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Secure Server Certification Authority
[1] http://www.googlewebmastercentral.blogspot.ch/2014/08/https-as-ranking-signal.html
[2] http://support.apple.com/kb/HT5012
[3] http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf
[4] http://www.googlewebmastercentral.blogspot.ch/2014/08/https-as-ranking-signal.html
[5] http://beta.slashdot.org/story/191445
[6]https://konklone.com/post/why-google-is-hurrying-the-web-to-kill-sha-1


Source: itrec-toor-eht-otni-snoitagitsevni-tsurt-fo-niahc-eht-gninoitseuq/lacinhcet/golb/moc.xobeulb

Read:78256 | Comments:0 | Tags:No Tag

“Questioning the chain of trust: investigations into the root certificates on mobile devices”0 Comments

Submit A Comment

Name:

Email:

Blog :

Verification Code:

Announce

Share high-quality web security related articles with you:)
Tell me why you support me <3