PKI Consortium blog

Is Your SSL Server Vulnerable to a FREAK Attack?
March 11, 2015 by Bruce Morton (Entrust) Android Attack Encryption Forward Secrecy Microsoft MITM RSA SSL/TLS Vulnerability

FREAK is a new man-in-the-middle (MITM) vulnerability discovered by a group of cryptographers at INRIA, Microsoft Research and IMDEA. FREAK stands for “Factoring RSA-EXPORT Keys.”

The vulnerability dates back to the 1990s, when the US government banned selling crypto software overseas, unless it used export cipher suites which involved encryption keys no longer than 512-bits.

The issue is there are still some clients who let crypto be degraded from “strong RSA” to “export grade RSA”. These clients use OpenSSL, Apple’s Secure Transport and Windows Secure Channel. As such, users of Android mobiles, Apple Macs, iPhones and iPads, and Windows platforms will be impacted.

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. They were able to do this by creating SSL certificates on the fly that imitate the certificates on the “real” websites they have intercepted and using them in a local SSL proxy to deliver content from the Visual Discovery server over the same apparent domain, without clearly revealing what they have done.  This is a classic “man in the middle” or MITM process.

SSL Certificate Validity Periods Limited to 39 Months Starting in April
February 19, 2015 by Jeremy Rowley CA/Browser Forum ETSI Policy SSL/TLS Vulnerability WebTrust

In accordance with the CA/Browser Forum Baseline Requirements, effective April 1, 2015, Certificate Authorities (CAs) will no longer be able to issue SSL Certificates with a validity period longer than 39 months.

Shortening the validity period to 39 months is the result of much consideration within the CA/Browser Forum to arrive at a duration that allows optimal usability while maintaining the tightest network security. A shortened validity period will significantly improve Internet security by requiring administrators to renew and verify their certificates more often. It will also make it easier for users to keep up-to-date on new advances in security and remain aware of their control over private keys.

Gogo Found Spoofing Google SSL Certificates
January 8, 2015 by Rick Andrews Google Malware MITM SSL/TLS

It was recently disclosed that Gogo, a provider of Wi-Fi Internet services on commercial aircraft, has been issuing spoofed SSL certificates for Google sites that were viewed by customers of Gogo’s service. It appears that Gogo Inflight Internet was acting as an SSL Man-in-the-middle (MITM), a technique used within some enterprises to allow themselves to inspect and control all web traffic, even traffic to secure web sites.  To understand what this means, let me explain MITM in a bit more detail.

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.

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. It wouldn’t check the padding bytes but that wouldn’t cause any problems in normal operation. However, if an SSLv3 decoding function was used with TLS, then the POODLE attack would work, even against TLS connections.”

’Tis the Season for Online Safety
November 30, 2014 by CA Security Council SSL/TLS Vulnerability

The holidays are approaching as quickly as a sleigh pulled by magic reindeer, and every year it seems like the shopping season starts earlier and earlier. In many places, Christmas decorations are now put up before Halloween, ensuring a long and profitable season for merchants. And while most of us have had the experience of opening a disappointing gift on Christmas morning, one thing that can ruin your holiday faster than a homemade sweater is finding out that someone has obtained your credit card number, or compromised your account on your favorite shopping website.

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 IETF released TLS 1.0, 1.1 and 1.2. They are currently working on TLS 1.3.

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. Give them a hash value and they will look in their table to see if they have the input that resulted in that hash value. If they haven’t pre-computed the hash value for the data you’re looking for, they won’t find anything. They’re intended as password recovery services, since many user authentication systems store the hash values of passwords rather than the passwords themselves. Many years ago, we thought this was safe since good hash functions were considered irreversible (if someone has the hash value without the corresponding input, they can’t reverse the algorithm to recover the input), and computers didn’t have enough memory or storage to save and process large rainbow tables. Today, rainbow tables are commonly used to associate hash values with passwords and vice versa.

Extra Trips are for Frequent Flyers, Not SSL/TLS Performance
October 30, 2014 by Wayne Thayer Firefox Forward Secrecy Google HSTS OCSP Revocation RSA SSL/TLS

TLS is quickly becoming a de facto requirement for every website due to increased concerns about spying and Google’s recent move to use HTTPS as a factor in search engine ranking. In a recent article we explained how HSTS helps website operators to ensure that their site is always using TLS, but now we want to ensure that your performance isn’t sacrificed in the name of enhanced security. While the myth that TLS slows down a website has been debunked, some basic settings can make a site using TLS even faster.