PKI Consortium blog

CA Security Council Report: Consumers Don’t Know Much About Security, But They Trust the Padlock and Green Bar When Shopping Online
April 13, 2015 by CA Security Council CASC EV Google Identity SSL/TLS

San Francisco – April 13, 2015 – The CA Security Council (CASC), an advocacy group committed to the advancement of the security of websites and online transactions, today released its 2015 Consumer Trust Survey which found that validation matters.  While consumers are confused about some aspects of security, they recognize and trust the security that SSL brings to e-commerce sites.  Fifty-three percent of respondents identify the padlock as adding confidence in an e-commerce site, with 42 percent associating the green bar and organization name in the URL with greater safety.

Fighting the Good Fight for Online Trust
April 2, 2015 by CA Security Council Apple CAA CASC Google HSM Mis-issued MITM Mozilla Policy Root Program SSL/TLS WebTrust

Once again Browsers and Certificate Authorities are in the news over the reported mis-issuance of an SSL server certificate to a google.com domain. Discovered by Google most likely via technology known as key pinning and discussed by Google’s Adam Langley in this blog, a Chinese certificate authority, CNNIC (Chinese Internet Network Information Center), apparently issued an intermediate certificate to an Egyptian company called MCS Holdings. Because the CNNIC root certificate is included in the root store of most major browsers, users would not see any warnings on sites that have certificates issued by CNNIC or MCS Holdings. When MCS installed their intermediate into a Man in the Middle (MITM) proxy device, that device could then issue certificates for sites which users connected to that proxy would visit. (MITM is described in more detail in our previous blog here: https://casecurity.org/2015/01/08/gogo-found-spoofing-google-ssl-certificates/)

Code Signing Baseline Requirements
October 20, 2014 by Jeremy Rowley CA/Browser Forum CASC Code Signing Malware Microsoft Vulnerability

Code signing certificates are used to sign software objects to authenticate that they originated from a verified source, allowing developers to avoid warnings commonly displayed by application software vendors such as Microsoft operating systems and Java. A fraudulent code signing certificate can wreak havoc on networks, spreading malware and adware without restraint. Certificate Authorities are tasked with ensuring that code signing applicants are legitimate entities and provide accountability for use of the certificate.

Google Plans to Deprecate SHA-1 Certificates – Updated
September 24, 2014 by CA Security Council Announcement Attack CASC Chrome Code Signing Google Microsoft Policy SHA1 SSL/TLS

UPDATED September 23, 2014: The following blog post has been updated with action taken in recent weeks, as well as to reflect helpful user comments left on our August 28 blog post on this topic.

On August 19, Google announced a new policy that accelerates the deprecation of SHA-1 certificates, potentially causing websites using SHA-1 certificates to display warnings in the near future. While keeping with an earlier Microsoft announcement to accept SHA-1 certificates with an expiration date before Jan. 1, 2017, the Google policy will provide new “untrusted” warnings in regards to such certificates as early as this November.

Google Plans to Deprecate SHA-1 Certificates
August 28, 2014 by CA Security Council Attack CASC Chrome Code Signing Google Microsoft Policy SSL/TLS

On August 19, Google announced a new policy that accelerates the deprecation of SHA-1 certificates, potentially causing websites using SHA-1 certificates to display warnings in the near future. With the change, Chrome 39 will show a warning for sites that have a SHA-1 certificate expiring in 2016 and require a click through warning for sites with a SHA-1 certificate expiring in 2017 or later. This proposal is scheduled for Chrome 39, which could be released as early as 12 weeks from now.

In the Wake of Unauthorized Certificate Issuance by the Indian CA NIC, can Government CAs Still be Considered “Trusted Third Parties”?
July 24, 2014 by Ben Wilson CA/Browser Forum CAA CASC Chrome ETSI Firefox Google Microsoft Mis-issued Mozilla OCSP PKI Policy Revocation SSL/TLS Trust List WebTrust

Short answer: Government CAs can still be considered “trusted third parties,” provided that they follow the rules applicable to commercial CAs.

Introduction

On July 8 Google announced that it had discovered several unauthorized Google certificates issued by the National Informatics Centre of India. It noted that the Indian government CA’s certificates were in the Microsoft Root Store and used by programs on the Windows platform. The Firefox browser on Windows uses its own root store and didn’t have these CA certificates. Other platforms, such as Chrome OS, Android, iOS, and OS X, were not affected. See http://googleonlinesecurity.blogspot.com/2014/07/maintaining-digital-certificate-security.html

CASC Heartbleed Response
May 8, 2014 by CA Security Council CASC Chrome CRL Google Malware OCSP Revocation SSL/TLS

The recent Heartbleed issue has reawakened interest in SSL certificate revocation (see Adam Langley’s blog, Larry Seltzer’s articles here and here, and Steve Gibson’s web pages)

Several years ago, the CA Browser Forum convened a special Revocation Working Group to explore issues and solutions. Leading CAs were actively involved in that group, and many of them invested in moving their OCSP responders to high-performance, high-availability Content Delivery Networks (CDNs) to respond to browser vendors’ requests for increased performance and reliability.

Revocation – A Cure For the Common Heartbleed
April 28, 2014 by Jeremy Rowley Attack CASC Chrome CRL Google Identity OCSP Revocation SSL/TLS

The Heartbleed bug spurred server administrators worldwide to work closely with Certification Authorities (CAs) in rekeying and reissuing potentially vulnerable SSL certificates. Part of this effort included revoking existing certificates used on vulnerable servers to ensure obtained private keys are not later used in a man-in-the-middle attack against the website. Unfortunately, in recent days, certain news reports and blogs addressing certificate revocation and checking for revoked certificates online have failed to discuss the benefits of revocation, instead focusing on the minority of circumstances where widely deployed revocation is not perfect. In the interest of providing balanced information to the public, we, as members of the CA community and as individuals generally interested in a high level of Internet security, would like to help clarify some of the issues confused by these reports and blogs.

Heartbleed Bug Vulnerability: Discovery, Impact and Solution
April 9, 2014 by Jeremy Rowley Attack BEAST CASC CSR DTLS Encryption Google OpenSSL SSL/TLS TLS 1.0 TLS 1.1 Vulnerability

On April 7, 2014, a vulnerability in the OpenSSL cryptographic library was announced to the Internet community. Aptly labeled as the Heartbleed bug, this vulnerability affects OpenSSL versions 1.0.1 through 1.0.1f (inclusive). The Heartbleed bug is not a flaw in the SSL or TLS protocols; rather, it is a flaw in the OpenSSL implementation of the TLS/DTLS heartbeat functionality. The flaw is not related or introduced by publicly trusted certificates and is instead a problem with server software.

Reducing the Impact of Government Spying
April 4, 2014 by Jeremy Rowley CASC Encryption Forward Secrecy Malware PKI RC4 RSA SHA2 SSL/TLS TLS 1.1 Vulnerability

Last year, Edward Snowden, an American computer-specialist working as a contractor for the National Security Agency (“NSA”), shocked web-users around the world by publicizing documents showing that the NSA was gathering intelligence on Internet users. The realization that the US government was gathering sensitive information has led to a worldwide demand for better protection of online communication and data and a general worry about the effectiveness of existing infrastructures. Specifically, some entities have asked whether PKI is still a robust way to protect online information.