PKI Consortium blog

Show posts by Author, Tag or Series

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.

Code Signing Baseline Requirements
October 20, 2014 by Jeremy Rowley CA/Browser Forum CASC Code Signing Malware Microsoft Vulnerability

Code signing certificates are used to sign software objects to authenticate that they originated from a verified source, allowing developers to avoid warnings commonly displayed by application software vendors such as Microsoft operating systems and Java. A fraudulent code signing certificate can wreak havoc on networks, spreading malware and adware without restraint. Certificate Authorities are tasked with ensuring that code signing applicants are legitimate entities and provide accountability for use of the certificate.

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.

Participate in our community discussions and/or join the consortium