Qualys Blog

Ivan Ristic

Per-Protocol Cipher Suite Detection in SSL Labs

Just a couple of days ago SSL Labs started showing multiple certificates when they are configured for the same host, and we now have another useful feature lined up—per protocol cipher suite testing. When I started working on SSL Labs in 2009, everyone had the same cipher suite configuration, no matter what protocol version was used. In the years that followed we had various security issues in earlier protocol versions, and the ability to configure per-protocol cipher suites slowly started to find its way into libraries. Today, different suites for different protocols is still not very common, but not rare any more.

Now, it seems like a small thing to test supported cipher suites for each protocol separately, but it actually required a lot of work. The first problem was that cipher suite testing was the slowest part of the assessment. That’s because SSL Labs used to use one connection to test support for one suite. If you suddenly multiply that by two or three, the assessment time explodes. There’s a good historical method why this approach was used, by the way. Back in the day, there were lots of F5 devices that wouldn’t tolerate TLS handshakes with a large number of suites. So, to avoid interoperability problems, the easiest solution was to check one suite at the time.

When the time came to switch to per-protocol suite testing, we decided to completely overhaul cipher suite detection to speed it up. Luckily, in the meantime one of the F5 engineers provided a workaround for their interoperability problem; we even have RFC 7685 for it. To cut the long story short, the new testing method in SSL Labs is both faster and provides better suite detection. Refactoring at its best.

Our work is not yet done, however. There is another aspect of cipher suite testing, and that’s support for Server Name Indication (SNI). SNI is a special feature of TLS that allows multiple secure sites to exist on the same IP address. Another thing that has become common is that sites configure cipher suite support on per-site (not server) basis. In this case, clients that don’t support SNI and thus can’t specify the desired site name (e.g., Windows XP and some very old Android devices), get server suites not site suites.

The new cipher suite detection implementation is now running on the SSL Labs staging server. Once ready, we’ll migrate it to production.

2 responses to “Per-Protocol Cipher Suite Detection in SSL Labs”

  1. Will we ever see support for other protocols than http? Like pop3, imap, smtp, ftp (starttls and regular variant).

    That would be great.

    • Personally, once I temporarily shut down my website and temporarily served each of my mail servers on port 443 to run the SSL Labs tests on them. It led to me receiving an e-mail from someone reporting a weird error message trying to visit my site which I assured was temporary.
      Until SSL Labs supports non-HTTPS ports, I use another service from HTBridge to test my mailservers, as their SSL test allows custom ports.

      For SSL Labs, you can only test services that operate on port 443 and have a domain on the public DNS.

Leave a Reply