Testing Secured Connections

This article describe some methods for testing the condition of a secured server.

This article is part of the Securing Applications Collection

Testing TLS settings

Proper configuration is only part of the equation to establishing secure network encryption. Once your configurations have been set and services restarted it's time to test your system to verify that the desired protocols and ciphers are functional and that the weak or broken protocols and ciphers have been properly disabled.

Note that the tool used (openssl) only has support for either direct TLS start, or a limited number of services that have a pre-amble (smtp", "pop3", "imap", and "ftp"). This precludes direct testing of services like mysql, postgresl or ldap which have a more complex startup procedure. Also note that to ensure that as complete a test as possible is performed the actual probe should be made from a RHEL6 or RHEL7 machine.

Test for SSLv2 being disabled

SSL 2.0 is broken and considered insecure. Your servers should not negotiate this protocol. You should not see a valid connection, with key exchange, when you perform this test.

openssl s_client -connect host:port -ssl2

Test for SSLv3 being disabled

SSL 3.0 is very weak and considered insecure. Your servers should not negotiate this protocol. You should not see a valid connection, with key exchange, when you perform this test.

openssl s_client -connect host:port -ssl3

Test for TLSv1.2 being enabled

TLS 1.2 is the strongest TLS protocol available and is considered secure. Your servers should negotiate this protocol. You should see a valid connection, with key exchange, when you perform this test.

openssl s_client -connect host:port -tls1_2

Test for ECDHE-RSA-AES128-GCM-SHA256 being enabled

This is the best ciphersuite available for servers with RSA keys.

openssl s_client -connect host:port -cipher ECDHE-RSA-AES128-GCM-SHA256