Black Hat 2010: Study tests SSL protocol use, finds SSL errors

Ivan Ristic of Qualys Inc.'s SSL Labs, is studying thousands of SSL implementations to document configuration errors and protocol issues.

Ivan Ristic has been quietly weeding through millions of registered domain names to find and test SSL protocol implementations.

We need to know if we're secure and if there are insecure aspects, we need to know what they are and what we can do to fix them.
Ivan Ristic,
director of engineeringQualys Inc.

Ristic, director of engineering at Redwood Shores, Calif.-based Qualys Inc., runs SSL Labs, a non-commercial research effort that was acquired by Qualys last year. The site uses an SSL testing tool to check for configuration issues and protocol errors that can be used by cybercriminals in man-in-the-middle attacks to trick people into giving up sensitive data.

"We're trying to find as many SSL servers on the Internet and assess every single one of them," Ristic said. "The goal is to really understand how SSL is used. We need to know if we're secure and if there are insecure aspects, we need to know what they are and what we can do to fix them."

Ristic plans to present details of the SSL study at the Black Hat briefings later this month in Las Vegas. Of about 120 million domain names reviewed, approximately 720,000 are using SSL certificates, Ristic said. In this interview, Ristic explains why researchers need to focus on SSL despite its reputation for being a nearly foolproof security protocol.

SSL protocol issues:
How does SSL 'sit' between the network layer and application layer? SSL is neither a network layer protocol nor an application layer protocol. In this SearchSecurity.com Q&A, Michael Cobb explains how SSL "sits" between both layers. 

SSLstrip hacking tool bypasses SSL to trick users, steal passwords: In 2009, Moxie Marlinspike explained how his hacking technique fools Web users into thinking they are on an SSL-protected site, leaving them feeling quite safe, but pwned all the same. 

What is SSL Labs and how did it become part of Qualys?
Ristic: SSL Labs is a research organization that focuses on the SSL and TLS protocols. I started it about a year ago and it came out of my obsession with SSL. I became fascinated with SSL when I realized how good of a protocol it is. SSL is one of the most successful protocols that we have and it's the security backbone of the Internet, yet we are spending very little time researching it to understand how it is used and helping our users everywhere configure it and use it properly. I started this website which has a lot of information and tools to help people understand how to configure it properly. Qualys really liked what I was doing and in a way I was doing SSL Labs in parallel with other things. Qualys offered me the opportunity to focus on my research full time giving me the opportunity to do this study.

Why is there a lack of research on SSL?
Ristic: My theory is that there was quite a lot of excitement about SSL initially. The protocol itself is about 15 years old. Somehow we got distracted over the years and went away to pursue other security issues in the application security space and even the network security space. I think SSL got a reputation that it is something that we don't have to think hard about, which is a shame. That really changed a couple of years ago. We have had quite a few revelations about SSL. Several people independently worked and discovered not only that many of the implementations have issues, but also the protocol itself has some small, finer problems that need to be addressed. Now, there's a revival when it comes to SSL with more and more people starting to ask questions and fix what's wrong.

Many of the problems are configuration issues?
Ristic: Yes. There are issues with implementation and small protocol issues. If you are a normal user, you don't have to be concerned with [protocol issues] very much. It's something for SSL vendors to be concerned about and for security researchers to work to improve the protocol. As a normal user you simply have to keep you systems patched. If you keep your systems up to date, then you take care of all those issues. Configuration problems are something that you can immediately understand and fix within a half hour or couple of hours of your work. The problem there is that most people don't know that they have configuration issues.

Several people ... discovered not only that many of the implementations have issues, but also the protocol itself has some small, finer problems that need to be addressed.
,

Is that the basis of the online SSL assessment tool? It takes a look at all these issues?
Ristic: Yes. There are two parts to the online tool. Part one is the methodology, which documents exactly how the assessment is performed. The second part is the tool itself. If you go to the website and type in the domain name , the tool will go to that domain name, it will find all the SSL servers behind it, even when there are multiple SSL servers behind the same domain name and then it will assess every server individually. The results will be very easy to understand because we sum up the configuration of every site as a single grade from A to F and a number from 0 to 100. So, if you're not deeply involved with SSL, it will be easy to understand. If you are technical user, we provide more technical information as well. Both of these groups of people can be satisfied.

You spoke one time about a SSL renegotiation vulnerability. What is the problem?
Ristic: The renegotiation was discovered late last year. Basically the issue comes from one particular aspect of SSL, which is both an advantage and disadvantage. SSL was designed to be protocol independent, so it sits in a separate network layer. That allows it to work for any underlying network protocol. You can use SSL to protect HTTP, to protect SMTP, for email, IMAP, LDAP and other protocols, and there's little work involved to get all these different protocols to work with SSL. However, we now know there's a danger when you deploy protocols that have no direct connection to SSL. What we end up having is a mismatched problem and issues in which you can mishandle SSL because you don't know what's really going on. It essentially allows an attacker to open two connections and trick a client into using two connections as one. The attacker can inject arbitrary content into a vulnerable website. It was relatively quick to fix, however the problem now is that all the SSL servers out there actually need to be patched to fix the problem. That's one of the things I want to check in my survey to check the numbers of servers that are getting patched and to see how quickly the admins can react when there is a need to fix systematic issues like this one.

Your test is designed to be fast and takes about 2,000 packets to test a single server?
Ristic: The assessment was designed with a very large number of assessment tests in mind and it's written at a very low level without going to a complete SSL connection and that is what makes it very fast. A single test will take about 200 connections and exchange about 250 kbts of data. We don't want to overwhelm the server that is being tested. It won't jeopardize any of the servers. … We're trying to find as many SSL servers on the Internet and assess every single one of them. The goal is to really understand how SSL is used. We need to know if they are secure and if there are insecure aspects; we need to know what they are and what we can do to fix them.

We have a big problem in the SSL space because to host a million websites, you can put all of them onto a single IP address.
,

There are millions of sites out there, but there is a relatively small number that use SSL certificates. Is that correct?
Ristic: Yes. There are about 200 million registered domain names and in my tests, I've worked with 60% of them (120 million). I did a very light weight phase that looked at all of these 120 million websites to figure out what services they support. I wanted to see if there is a website and whether there is a secure website running behind the domain name. In the end what we found that about a quarter of all domain names are not functional. About 77% of domain names I tested have a service. About 22 million have a Web server running and about 3% of have SSL certificates which are potentially valid. There's about 720,000 secure websites that I have discovered and that I'm going to be assessing in depth in the second phase. Today we have a big problem in the SSL space because to host a million websites, you can put all of them onto a single IP address. For every single secure website, you have a separate and exclusive IP address. This is generally a huge problem and hindering the adoption of SSL for security worldwide.

You have been involved with the ModSecurity open source Web application firewall. What is your reaction to Trustwave acquiring Breach Security and along with it, the ModSecurity Project?
Ristic: It can affect the ModSecurity Project, but at this point we don't know what their intentions with ModSecurity are. Truth be told, ModSecurity hasn't exactly thrived under Breach Security, so the way I see it, with this, things can only get better. They have done a really good job maintaining ModSecurity, but we haven't really seen much progress in the last couple of years. I'm still involved in the project as a contributor and I plan to continue to contribute when I have time.

Why hasn't there been much progress for ModSecurity?
Ristic: I think the interests of Breach Security haven't aligned with ModSecurity because Breach Security has their own product, which is separate from ModSecurity. It is unfortunate that after the acquisition of ModSecurity, Breach Security didn't integrate it into their own product line. Had they done that, ModSecurity would have benefited because then it would have been in their interest.

Dig deeper on Network Protocols and Security

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close