Tag: ssllabs | Qualys Blog

SSL: Deceptively Simple, Yet Hard to Implement

Posted by Juan C. Perez in Qualys News, Qualys Technology, SSL Labs on December 12, 2016

An Interview with SSL Expert and SSL Labs Founder Ivan Ristić

Even though SSL/TLS is critical for the privacy, integrity, and security of internet communications, the protocol is implemented in an optimal way in only a small percentage of web servers, meaning that most websites and web apps aren’t as secure as they could be.

It doesn’t have to be that way, which is why Ivan Ristić, a security researcher, engineer, and author known for his expertise on various aspects of InfoSec, has spent years contributing to the field of SSL/TLS.

He launched SSLLabs.com in 2009 to provide SSL/TLS tools, research and documentation, brought it with him when he joined Qualys in 2010, and ran it until mid-2016, when he became an advisor. Under his leadership, SSLLabs.com became a de-facto standard for secure server assessment and the go-to site for organizations looking for help improving their SSL/TLS configurations.

Ristić also wrote an entire book about the topic titled “Bulletproof SSL and TLS: Understanding and Deploying SSL/TLS and PKI to Secure Servers and Web Applications.” We recently had a chance to catch up with Ivan and pick his brain about SSL/TLS challenges, best practices and trends. Here’s what he told us.

1 Comment
Permalink
Tags: cryptography, security, ssl, ssllabs, threats & worms, tls, vulnerabilities

OpenSSL CVE-2016-2107 Grading Update

Posted by Ivan Ristic in SSL Labs on May 9, 2016

We are releasing an update to the grading criteria, version 2009m, to respond to the discovery of the OpenSSL vulnerability CVE-2016-2107 announced in the OpenSSL Security Advisory [3rd May 2016]. This vulnerability can be exploited by MITM attacker using a padding Oracle attack to decrypt traffic when the connection uses an AES CBC cipher and the server supports AES-NI.

DROWN Grading Update

Posted by Ivan Ristic in SSL Labs on March 4, 2016

We are releasing an update to the grading criteria, version 2009l, to respond to the discovery of the DROWN attack. If a server is found to be vulnerable to DROWN it will be given an F, even though it might not support SSL v2 itself. (The nature of the DROWN vulnerability is such that servers that support SSL v2 can affect other servers, irrespective of supported protocol versions). You’ll find more information about our DROWN test here. Additionally, servers that support SSL v2 but don’t have any cipher suites configured are treated as if they had SSL v2 fully enabled.

This update also contains two fixes to our grading code, which we don’t consider to be changes to our grading criteria:

Servers that have invalid HPKP information are not awarded A+.
Servers that have an RSA key with exponent 1 are given an F.

Version 1.20.28 now running in production

Posted by Ivan Ristic in SSL Labs on November 6, 2015

SSL Labs v1.20.28 is now running in production. This version introduces a penalty for RC4-only servers, as previously announced.

New Penalty for RC4-Only Servers in October 2015

Posted by Ivan Ristic in SSL Labs on September 11, 2015

In October 2015, SSL Labs will start to fail (F) RC4-only servers. This change is a replacement for the second phase of our RC4 deprecation plan, which we announced in May 2015. We are adjusting our approach to avoid creating grading loopholes. (You can find out more about that here.)

The RC4 cipher is insecure and must be phased out. The IETF published RFC 7465 in February 2015 to formally deprecate RC4. In September 2015, Google, Microsoft and Mozilla announced that they will be removing RC4 from their browsers in early 2016. As a result of that change, RC4-only web sites will stop functioning in modern browsers. Our grading update will thus not only indicate the problems with RC4, but serve as an early warning system to help organisations migrate to better security in time.

No Change to RC4 Grading in September

Posted by Ivan Ristic in SSL Labs on August 24, 2015

Back in April we wrote about our plans for RC4 deprecation in SSL Labs. Our intention had been to deprecate RC4 in two steps, first in May and then again later in September. The initial change, which we carried out, was to cap site grades to C if they’re using RC4 with modern protocols (i.e., TLS 1.1 and TLS 1.2). The cap for those who use RC4 only with TLS 1.0 and earlier protocol versions (i.e., old clients) remained at B. Additionally, to ensure that the grading algorithm can’t be played, we changed the penalty for not supporting TLS 1.2 from B to C. This meant that those who were using RC4 with modern clients couldn’t improve their grade by disabling TLS 1.2.

For the second phase, the plan was to give F to those sites that use RC4 with modern protocols. However, when we started implementing this behaviour we realised that this would created another loophole: sites who got an F because of RC4 would be able to turn off TLS 1.2 to improve their grade (and get a C instead). This time we are not able to close the loophole by increasing the penalty for not supporting TLS 1.2.

As a result, there will be no change to the RC4 grading in September. We’ll determine how else we can encourage the removal of RC4 and make further grading changes later. As this week we will start a public discussion of the next-generation SSL Labs grading criteria, it’s likely that the RC4 changes will be considered as part of that discussion. To participate, please join the ssllabs-discuss mailing list.

Introducing TLS Maturity Model

Posted by Ivan Ristic in SSL Labs on June 8, 2015

As part of my job working on SSL Labs, I spend a lot of time helping others improve their TLS security, both directly and indirectly–by developing tools and writing documentation. Over time, I started to notice that deploying TLS securely is getting more complicated, rather than less. One possibility is that, with so much attention on TLS and many potential issues to consider, we’re losing sight of what’s really important.

That’s why I would like to introduce a TLS Maturity Model, a conceptual deployment model that describes a journey toward robust TLS security. The model has five maturity levels.

SSL Labs: Increased Penalty When TLS 1.2 Is Not Supported

Posted by Ivan Ristic in SSL Labs on May 22, 2015

Earlier this week we released SSL Labs 1.17.10, whose main purpose was to increase the penalty when RC4 is used with modern protocols (i.e., TLS 1.1 and TLS 1.2). We had announced this change some time ago, and then put in place on May 20. The same release introduced another change, which was to increase the penalty for servers that don’t support TLS 1.2 from B to C. And it seems that this second change is being somewhat controversial, with many asking us to better explain why we did that.

SSL Labs 1.17: RC4, Obsolete Crypto, and Logjam

Posted by Ivan Ristic in SSL Labs on May 21, 2015

Yesterday we released SSL Labs 1.17.10, whose main goal was to introduce grading adjustments we had talked about a month ago. We delivered the planned changes as well as a few additional tweaks. Our release coincided with an announcement of a new attack against TLS, called Logjam, and we had some time to work on that, too.

What’s New in SSL Labs 1.16.x

Posted by Ivan Ristic in SSL Labs on April 28, 2015

Yesterday (27 April), we released a new version of SSL Labs. In this blog post I’d like to quickly go over what was changed: there were a healthy number of improvements, a few fixes, and a large number of additions to the API.