« Speaking on SSL at OWASP AppSec Research in Sweden | Main | Breaking SSL: Why leave to others what you can do yourself »

Deep protocol and cipher suite testing in SSL Labs

May 14, 2010

SSL has a usability problem when the negotiation of a secure communication channel fails: the user is left with a cryptic error message and his head to scratch. Let's say that you are someone whose browser is not particularly equipped in the cryptography department and that you want to connect to a high-security site. Your browser fails to negotiate a SSL session and tells you that "SSL peer was unable to negotiate an acceptable set of security parameters" (Firefox). The problem is that there is no way for the site to communicate the problem to you and explain how you can fix it.

It's a hard problem to solve. SSL could be extended to allow a custom redirection URL to be dispatched to the user who is unable to negotiate good-quality encryption, leading him to a non-SSL page with more information. But such a page could be intercepted and modified (think MITM and sslstrip), allowing an attacker to take control over the user's session. Even the redirection URL itself might be intercepted and modified in transit. The same could happen with a custom text message.

Although the failure to negotiate a secure connection is very rare, there are some sites that find it unacceptable. They will thus accept weak protocols and cipher suites on the SSL level, reporting the problem via HTTP. I think this approach is more secure because in many cases using a weaker protocol is better than no communication security at all.

It is inconvenience for me, though, because there is no standard way in HTTP say that you are, in effect, politely refusing to talk to someone. To detect the situation, I have to look for clues in HTTP responses. Here's what NetScaler responds with:

HTTP/1.1 500 Internal Server Error
Connection: close
Content-Length: 510
Content-Type: text/html

<html><body><b>SSL Alert</b><p>The browser and the web-site cannot communicate securely because there are no common encryption algorithms.</p><p>Please try the following:</p><p>- Check the SSL protocol settings on the browser for SSLv3/TLSv1 protocol support.</p><p>- The secure web-site may be using high-strength encryption algorithms(128 bit).<br>  Check the SSL settings on your browser, if it supports high-strength encryption algorithms.</p><p>- Upgrade your browser to latest version.</p></body></html>

I already did that last year for SSLv2 protocol detection, but a couple of days ago I further improved the assessment engine adding support for deep cipher suite testing. SSL Labs now detects the default NetScaler error response delivered for both weak protocols and weak cipher suites. If you want to see an example, have a look at the Amazon.com results.