PKI Consortium blog

Lenovo Enables Man-in-the-Middle Attacks Via Superfish Adware
February 20, 2015 by Doug Beattie (GlobalSign) Attack Code Signing Firefox Malware Microsoft MITM Mixed Content SSL/TLS Vulnerability
Lenovo is selling computers that contain the Superfish application which “supplements” the user’s SSL sessions to enable their adware application to deliver content transparently; however, due to poor security design this leaves users vulnerable to man-in-the-middle attacks. How it was supposed to work Superfish uses the program “Visual Discovery” to process images in browser content and then displays ads for similar goods and services. This sounds like any other adware application, but in order to maintain SSL sessions and not alert users with security warnings, Superfish is serving up these images over https.

2015 – Looking Back, Moving Forward
January 6, 2015 by Bruce Morton (Entrust) Apple Attack CA/Browser Forum CAA Chrome Code Signing EV Firefox Forward Secrecy Google IETF Malware Microsoft MITM Mozilla OpenSSL PKI Policy RSA SHA1 SSL 3.0 SSL/TLS TLS 1.0 TLS 1.2 TLS 1.3 Vulnerability
Looking Back at 2014 End of 1024-Bit Security In 2014, the SSL industry moved to issuing a minimum security of 2048-bit RSA certificates. Keys smaller than 2048 are no longer allowed in server certificates. In addition, Microsoft and Mozilla started to remove 1024-bit roots from their certificate stores. Hopefully, the key size change will support users through to 2030. Push to Perfect Forward Secrecy Following the Edward Snowden revelations of pervasive surveillance, there was a big push to configure web servers to support Perfect Forward Secrecy.

POODLE for TLS
December 16, 2014 by Bruce Morton (Entrust) Attack SSL 3.0 SSL/TLS Vulnerability
The POODLE attack on SSL 3.0 has now been extended to some implementations of TLS. POODLE for TLS can be tracked through CVE-2014-8730. POODLE is not a flaw with the certificate authority (CA), SSL certificates or certificate management system. POODLE is a TLS implementation bug. Adam Langley states that “TLS’s padding is a subset of SSLv3’s padding so, technically, you could use an SSLv3 decoding function with TLS and it would still work fine.

A Follow-up on POODLE and SSL 3.0
November 21, 2014 by Bruce Morton (Entrust) Attack Encryption Google IETF Mozilla OpenSSL SSL 3.0 SSL/TLS TLS 1.0 TLS 1.1 TLS 1.3 Vulnerability
In October 2014, Google announced POODLE, an SSL 3.0 protocol attack. To bring you up to speed, the SSL/TLS protocol is the most important and popular security protocol on the Internet. The Secure Sockets Layer (SSL) protocol was developed by Netscape. They quickly moved from SSL 1.0 to 2.0 and finalized with SSL 3.0 in 1996. This protocol was then picked up by the IETF, who released it under the name of Transport Layer Security (TLS).

The Cost of Creating Collisions Using SHA-1
November 18, 2014 by Rick Andrews Attack SSL/TLS
SHA-1 is a cryptographic hash algorithm that is most commonly used today in TLS/SSL certificates on the Internet. It has almost completely replaced older algorithms like MD2, MD4 and MD5, which were phased out when practical attacks against those algorithms became widely known. If you do a simple web search, you’ll find a number of online services that claim to “crack” SHA-1 and other hash functions. These generally use a computer’s CPU to build and search through a rainbow table, which contains the hash value that results from a number of expected inputs, and allows you to “reverse” the hash algorithm.

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.

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.

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.

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.

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.