PKI Consortium blog

Secure Your Website with HSTS
October 8, 2014 by Bruce Morton (Entrust) Attack Chrome Encryption Firefox Google HSTS Policy SSL/TLS

Is your website secure? One thing to consider is securing your website with HTTP Strict Transport Security (HSTS).

Implementation of HSTS is an extension of the Always-On SSL policy. For each website you want to protect with HSTS, you must first deploy an SSL/TLS certificate (if you haven’t already), and configure that website to be accessible only via HTTPS, not via HTTP. Then you convey to HSTS-enabled browsers that your site is only available with HTTPS, by sending the HSTS header value. Supporting browsers will automatically change any HTTP query for your website into an HTTPS query. If there is no HTTPS version available, then the browser will provide a trust dialogue to the user.

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.

Google to Give Priority Ranking to SSL Enabled Sites
August 21, 2014 by Chris Bailey (Entrust) Announcement Google SSL/TLS

Google’s announcement that it will give priority ranking to SSL enabled sites is a key milestone for increased use of SSL on the Internet.

Google announced a change to its ranking algorithm to include use of SSL on the site as a “very lightweight [positive] signal”. Although, this might not have an immediate impact to website owners/operators that are not currently using SSL, this is still an important signal indicating everyone should be prepared to encrypt all their websites if they want to remain relevant.

Who Sets the Rules Governing Certification Authorities?
August 19, 2014 by Kirk Hall (Entrust) CA/Browser Forum Code Signing DV Encryption ETSI EV Google Hash Function Identity IETF Microsoft Mozilla OCSP Policy Revocation Root Program SSL/TLS WebTrust

Every time something positive is published about SSL and encryption,such as Google’s recent decision making use of https encryption a favorable rating factor for a website, or negative, such as the Heartbleed issue – bloggers and others always post questions about public Certification Authorities (CAs), including general questions on who sets the rules that govern CAs. Some bloggers seem to assume there are no rules or standards, and that CAs can operate without any requirements or limitations at all — that’s incorrect.

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

What To Do When You Rely on Internal Names in TLS/SSL Certificates
July 18, 2014 by Wayne Thayer Attack CA/Browser Forum Firefox IANA ICANN Microsoft MITM Qualified SSL/TLS

A deadline set by the CA/Browser Forum for the use of Internal Names is quickly approaching, and many system administrators need to understand how best to adapt to this change. At the same time, hundreds of new top-level domains are being launched, which redefines what constitutes an Internal Name. In this post we’ll explain what the changes are, why they’re being made, and how you can update your systems in response to the problem.

OCSP Must-Staple
June 18, 2014 by Bruce Morton (Entrust), Rick Andrews Announcement Revocation SSL/TLS

With the announcement of the Heartbleed bug and the resulting need to revoke large numbers of SSL certificates, the topic of certificate revocation has, once again, come to the fore.

There have been many issues with how revocation information is provided to the browsers. First let’s review how SSL certificate status may currently be obtained: How

| How | Definition | Pros | Cons | | signed list of the serial numbers of all revoked certificates that were signed by the CA’s certificate. | A single point of reference for the status of all certificates issued by the CA’s certificate. | Over time, CRLs might become very large, resulting in unacceptable latency. An attacker may be in a position to block the CRL delivery. | | Online Certificate Status Protocol (OCSP) | A signed response containing the status of one certificate. | An OCSP response is small and does not grow. As such, there is no latency due to size. | Browsers have to obtain an OCSP response for each certificate in the Web server’s certificate chain, requiring it to open additional connections, thereby impacting page load time. Privacy issues may be a concern as the CA can determine which websites a user is visiting. An attacker may be in a position to block the OCSP delivery. | | OCSP Stapling | A signed response, fetched by the Web server, with the status of its certificate. The OCSP response is then provided by the Web server to the browser. | No privacy issues, as the CA does not know which user has asked for the OCSP response. | Need Web servers and browsers that support OCSP Stapling. An attacker may be in a position to block the OCSP delivery. | | Blacklist (for example, CTLs or CRLSets) | A list of certificates that should not be trusted (whether or not they were revoked), distributed by the browser supplier. | The blacklist is distributed by the browser supplier as part of the browser executable. | Any certificate on the blacklist can be rejected without any additional checks. | For practical reasons, the list is incomplete. |

Benefits of Elliptic Curve Cryptography
June 10, 2014 by Wayne Thayer CA/Browser Forum ECC ECDH ECDSA Encryption RSA SSL/TLS

Elliptic Curve Cryptography (ECC) has existed since the mid-1980s, but it is still looked on as the newcomer in the world of SSL, and has only begun to gain adoption in the past few years. ECC is a fundamentally different mathematical approach to encryption than the venerable RSA algorithm. An elliptic curve is an algebraic function (y2 = x3 + ax + b) which looks like a symmetrical curve parallel to the x axis when plotted. (See figures below.) As with other forms of public key cryptography, ECC is based on a one-way property in which it is easy to perform a calculation but infeasible to reverse or invert the results of the calculation to find the original numbers. ECC uses different mathematical operations than RSA to achieve this property. The easiest way to explain this math is — for an elliptic curve, a line will only pass through three points along the curve (P, Q, and R), and that by knowing two of the points (P and Q), the other (R) can be calculated easily, but with just R, the other two, P and Q, cannot be derived.

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.