PKI Consortium blog

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.

Perfect Forward Secrecy
April 11, 2014 by Bruce Morton (Entrust), Rick Andrews 3DES DH ECC ECDH Forward Secrecy OpenSSL RC4 RSA SSL/TLS TLS 1.2

Recent revelations from Edward Snowden about pervasive government surveillance have led to many questions about the safety of communications using the SSL/TLS protocol. Such communications are generally safe from eavesdroppers, as long as certain precautions are observed. For example, configuring your web server to avoid using SSL2 and SSL3, favoring newer versions of TLS like TLS 1.2, selecting strong ciphersuites, etc.

But even if your server is configured properly, you still must secure the private key associated with your SSL certificate. In nearly all cases, the web site owner generates their key pair and sends only the public key to their Certification Authority (CA). The CA (and any eavesdropper) sees only the public key, and the private key cannot be derived from that. So the CA cannot reveal a web site owner’s private key to the government or an attacker, even if coerced to do so.

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.

Certificate Reputation
March 28, 2014 by Bruce Morton (Entrust) Microsoft MITM OCSP PKI SSL/TLS

One of the advantages of having multiple certification authorities (CAs) from which to choose an SSL certificate is that customers have flexibility to choose a CA that meets their specific needs, or even use a number of CAs for redundancy or to have access to a broader toolset. The disadvantage for end users, however, is that they often may not know if a particular CA was authorized to issue the certificate, and there could be a chance that the certificate was fraudulently obtained.

When to Choose an Extended Validation Certificate
March 25, 2014 by Wayne Thayer CA/Browser Forum EV SSL/TLS

In our last post, we made a case for using Organizationally Validated (OV) or Extended Validation (EV) certificates for e-commerce, but we didn’t go into detail about the differences between OV and EV. EV certificates provide the highest level of assurance about your business, and they visually indicate this to your site’s visitors.

The telltale sign that a business has obtained an EV certificate for their website is commonly referred to as the “green bar” displayed in the browser. The exact form of the indicator varies in different desktop and mobile browsers, but is generally a green background, green font color, or green lock icon in the browser’s address bar. The name of the business entity identified by the certificate is often displayed within the green area. These indicators are meant to convey a high level of assurance to a site’s visitors about the reliability of the information in the certificate.

CA Security Council Members Presentation at RSA 2014 Conference: New Ideas on CAA, CT, and Public Key Pinning for a Safer Internet
March 17, 2014 by Kirk Hall (Entrust) Attack CAA CASC Chrome EV Google IETF Microsoft Mis-issued OCSP Revocation RSA SSL/TLS Vulnerability

CA Security Council (CASC) members Trend Micro, Go Daddy, and Symantec participated in a discussion panel at the 2014 RSA Conference in San Francisco on February 24 entitled “New Ideas on CAA, CT, and Public Key Pinning for a Safer Internet.” Panel members included Kirk Hall of Trend Micro (Moderator), Wayne Thayer of GoDaddy (Panelist), and Rick Andrews of Symantec (Panelist).

Introduction to the Topic

Hall began by introducing the topic – all three alternative technologies (Certificate Transparency or CT, Certificate Authority Authorization or CAA, and Certificate Pinning) are intended to make the internet safer by dealing with mis-issued digital certificates, including so-called “rogue” certs like those obtained by a hacker from the now-defunct Diginotar Certification Authority (CA). Mis-issued certs generally present the greatest potential danger when they are for the most popular fraud target domains, such as mail.google.com, login.yahoo.com, login.live.com, etc.

Think Twice Before Using DV for E-Commerce
March 12, 2014 by Dean Coclin DV Encryption EV OV Phishing SSL/TLS

In a previous blog (What Are the Different Types of SSL Certificates?), we described the various types of SSL certificates available from publicly trusted Certificate Authorities (CAs).  CAs are often asked by their customers which certificate type should be used for websites conducting E-Commerce, rather than for just encryption of sensitive data. For the latter case, a Domain Validated (DV) certificate will work fine. A DV cert allows for encryption to take place between the browser and the server. However, because DV certificates do not contain any identification information, they SHOULD NOT BE USED for E-Commerce.  Why? Let’s look deeper at the differences between these certificates.

Pros and Cons of Single-Domain, Multi-Domain, and Wildcard Certificates
February 26, 2014 by Wayne Thayer Microsoft SSL/TLS

We have previously written about the different types of SSL certificates, but in that article we focused on validation levels. A recent post on LinkedIn highlighted the fact that there is another dimension that we haven’t yet explored.

SSL certificates come in three basic packages: “single-domain” certificates that can only be used on one specific website, “multi-domain” certificates that can be used on more than one website, and “wildcard” certificates that can be used on any website within a specific domain name. Multi-domain certificates are often called “unified communications” or “UC” certificates. This is a reference to one common use of these certificates, which is to secure Microsoft messaging products such as Exchange and Lync. The table below shows examples of the number and types of websites that each of these packages can protect:

Bogus SSL Certificates
February 20, 2014 by Bruce Morton (Entrust) Attack Google MITM SSL/TLS

Netcraft has published an article stating they have found many bogus SSL certificates. In this case, a bogus certificate is self-signed (i.e., not issued from a legitimate certification authority) and replicates an SSL certificate of a large, popular website.

This type of bogus SSL certificate could be used for a man-in-the-middle (MITM) attack. In this scenario, the attacker needs to gain a position that will allow them to intercept traffic and make you to go to their site instead of the real site. This is more likely for public Wi-Fi networks that allow connectivity in airports, cafes and hotels.