Testing for weak SSL ciphers for security audits

During security audits, such as a PCI-DSS compliance audit, it is very commonplace to test the cipher mechanism that a website / server uses and supports to ensure that weak / outdated cipher methods are not used.

Weak ciphers allow for an increased risk in encryption compromise, man-in-the-middle attacks and other related attack vectors.

Due to historic export restrictions of high grade cryptography, legacy and new web servers are often able and configured to handle weak cryptographic options.

Even if high grade ciphers are normally used and installed, some server misconfiguration could be used to force the use of a weaker cipher to gain access to the supposed secure communication channel.

Testing SSL / TLS cipher specifications and requirements for site

The http clear-text protocol is normally secured via an SSL or TLS tunnel, resulting in https traffic. In addition to providing encryption of data in transit, https allows the identification of servers (and, optionally, of clients) by means of digital certificates.

Historically, there have been limitations set in place by the U.S. government to allow cryptosystems to be exported only for key sizes of, at most, 40 bits, a key length which could be broken and would allow the decryption of communications. Since then, cryptographic export regulations have been relaxed (though some constraints still hold); however, it is important to check the SSL configuration being used to avoid putting in place cryptographic support which could be easily defeated. SSL-based services should not offer the possibility to choose weak ciphers.

Testing for weak ciphers : examples

In order to detect possible support of weak ciphers, the ports associated to SSL/TLS wrapped services must be identified. These typically include port 443, which is the standard https port; however, this may change because a) https services may be configured to run on non-standard ports, and b) there may be additional SSL/TLS wrapped services related to the web application. In general, a service discovery is required to identify such ports.

The nmap scanner, via the “–sV” scan option, is able to identify SSL services. Vulnerability Scanners, in addition to performing service discovery, may include checks against weak ciphers (for example, the Nessus scanner has the capability of checking SSL services on arbitrary ports, and will report weak ciphers).

Example 1. SSL service recognition via nmap.

Example 2. Identifying weak ciphers with Nessus. The following is an anonymized excerpt of a report generated by the Nessus scanner, corresponding to the identification of a server certificate allowing weak ciphers

Example 3. Manually audit weak SSL cipher levels with OpenSSL. The following will attempt to connect to Google.com with SSLv2.

These tests usually provide a very in-depth and reliable method for ensuring weak and vulnerable ciphers are not used in order to comply with said audits.

Personally, I prefer the nessus audit scans. Usually the default “free” plugins are enough to complete these types of one-off audits. There are, however, commercial nessus plugins designed just for PCI-DSS compliance audits and are available for purchase from the nessus site.

  • Vivek

    Nice post. There is a tool called sslscan that can help scan an SSL server for the ciphers it supports. Example with Google shown below.

    visuthan@visuthan:~/Documents/RSA$ sslscan http://www.google.ca:443 | grep Accepted
    Accepted SSLv3 256 bits ECDHE-RSA-AES256-SHA
    Accepted SSLv3 256 bits AES256-SHA
    Accepted SSLv3 168 bits ECDHE-RSA-DES-CBC3-SHA
    Accepted SSLv3 168 bits DES-CBC3-SHA
    Accepted SSLv3 128 bits ECDHE-RSA-AES128-SHA
    Accepted SSLv3 128 bits AES128-SHA
    Accepted SSLv3 128 bits ECDHE-RSA-RC4-SHA
    Accepted SSLv3 128 bits RC4-SHA
    Accepted SSLv3 128 bits RC4-MD5
    Accepted TLSv1 256 bits ECDHE-RSA-AES256-SHA
    Accepted TLSv1 256 bits AES256-SHA
    Accepted TLSv1 168 bits ECDHE-RSA-DES-CBC3-SHA
    Accepted TLSv1 168 bits DES-CBC3-SHA
    Accepted TLSv1 128 bits ECDHE-RSA-AES128-SHA
    Accepted TLSv1 128 bits AES128-SHA
    Accepted TLSv1 128 bits ECDHE-RSA-RC4-SHA
    Accepted TLSv1 128 bits RC4-SHA
    Accepted TLSv1 128 bits RC4-MD5
    visuthan@visuthan:~/Documents/RSA$

    • Kevin

      Thanks for this! :)

  • Anonymous

    Copy paste from OWASP! Could have given some credits