PKI Consortium blog

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.

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.

Ten Steps to Take If Your Website Is Compromised
February 12, 2014 by Wayne Thayer CSR Encryption Google Malware SSH SSL/TLS Vulnerability

After the news broke that 40 million credit card numbers were stolen from Target in a data breach of epic proportions, many of their customers went to work checking their accounts for fraudulent purchases and replacing cards we’d used recently at Target. These have become standard responses to news of this sort. In much the same way, there are some common actions that you should be aware of if your website becomes compromised.

Intermediate CA Certificates and Their Potential For Misuse For Man-In-The-Middle Attacks
January 9, 2014 by Robin Alden (Sectigo) Attack Firefox Google MITM Policy Root Program SSL/TLS Vulnerability

We have seen recently that Google detected that publicly trusted TLS/(SSL) certificates had been created for Google domains without having been requested by Google themselves.

The existence of such certificates might usually be taken as an indication of misissuance by the issuing CA (i.e. a failure or mistake by the CA which allowed the issuance of an end-entity certificate otherwise than in accordance with their policy) or as an indication of compromise of the issuing CA.

ICANN’s Accelerated gTLD Delegation Process and How This Impacts Your Organization
December 18, 2013 by Jeremy Rowley Announcement CA/Browser Forum CASC ICANN MITM Mozilla PKI Policy Qualified Revocation SSL/TLS Vulnerability

After the CASC’s previous letter addressing ICANN’s proposal to delegate nearly 2000 new gTLDs for use on the public Internet, ICANN identified and initiated an extensive study on two significant security issues. Now, based on the conclusions of the studies, ICANN is moving forward quickly with the delegation process, delegating more than 30 in the last two months alone. With ICANN ramping up the delegation process, nearly all 2000 will be delegated under the new rules, with only .corp and .home reserved as high risk gTLDs. This post serves as an advisory for interested network administrator on how the newest ICANN decisions may affect their networks and certificates.

IETF 88 – Pervasive Surveillance
November 26, 2013 by Bruce Morton (Entrust) Attack CRL Encryption Forward Secrecy HSTS IETF PKI Revocation SSL/TLS Vulnerability Web PKI

Internet Surveillance

The big news at IETF 88 in Vancouver was the technical plenary on Hardening the Internet which discussed the issue of pervasive surveillance. Pervasive surveillance is a mass surveillance of an entire or a substantial fraction of a population. The surveillance is usually carried out by government, is not targeted and its occurrence may not be overt. It was noted that pervasive surveillance, of the kind revealed in the Snowden-sourced documents, constitutes a misguided and damaging attack on civic society in general and the Internet in particular.

The (Soon to Be) Not-So Common Name
October 8, 2013 by Ryan Hurst CA/Browser Forum CRL Encryption Identity IETF Revocation SSL/TLS Vulnerability

If you are reading this post you are probably already familiar with the use of digital certificates and SSL even if you may not be familiar with the history. Before exploring the history of SSL, let’s review at its core what a digital certificate actually is. Fundamentally, a digital certificate is the binding of entitlements and constraints to a key, in other words a digital certificate would dictate the following, “The holder of the private key associated with this certificate can rightfully use the name John Smith when signing emails.”

It’s Time for TLS 1.2
September 19, 2013 by Wayne Thayer Attack BEAST Chrome Firefox OCSP RC4 SHA2 SSL 3.0 SSL/TLS TLS 1.0 TLS 1.1 TLS 1.2 Vulnerability

In a previous post titled Getting the Most Out of SSL Part 2, we touched on the recommendation that Web servers be configured to prefer Transport Layer Security (TLS) version 1.2. With the planned release of Firefox 24 and recent release of Chrome 29 adding support for TLS 1.2, now is a great time for website administrators to make the switch.

Transport Layer Security was formerly called Secure Sockets Layer (SSL) and is the protocol that enables secure “https://” connections to websites. TLS 1.2 was defined 5 years ago in RFC 5246, and TLS 1.1 dates all the way back to RFC 4346 in 2006. Both of these versions are updates to the original standard that fix bugs and problems including vulnerability to cipher block chaining (CBC) such as the BEAST attack that made news in 2011. The authors also added newer cipher suites including a replacement for RC4, a popular cipher that has been shown to be susceptible to attack. In short, enabling TLS 1.2 is like a Windows software update – it fixes potential problems and makes your website more secure.

Encryption Still Works – It’s About How You Implement It
September 13, 2013 by Ben Wilson ECC Encryption Malware RSA SHA1 SHA2 SSL/TLS TLS 1.1 Vulnerability

The September 5th joint article by the New York Times and Guardian newspapers on NSA’s and GCHQ’s efforts to circumvent encryption implementation have left many people speculating on the security of the data they are transmitting over the Internet. Hopefully, this blog post will provide some guidance and help understand SSL in light of these recent articles. Importantly, the articles point out that the primary means of attacking SSL/TLS do not exploit a vulnerability in the protocol itself but instead aim to exploit poor implementations of the protocol, insecure servers, and weak cryptography.