|Subject:||strengthening server SSL|
I recently made use of the SSL Pulse tool to report on some of our https servers. Most of these are apache but I did test Mojolicious which is a perl event-based server making use of IO::Socket::SSL. Before I mention the specific items reported, would it make sense for the IO::Socket::SSL docs to include a section mentioning configuration items that could improve security ? Perhaps one section for client and another for server. It's the latter I'm most interested in. Then again maybe there's some debate about the significance of what they choose to report. Rather than change current defaults or have other authors setting up options, maybe you could add something like: use_more_secure_server_defaults That's if you were happy accepting that responsibility. One advantage of providing such functionality could be if the best options needed to be based on the openssl version/capabilities. So on RHEL5 with OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008. perl 5.14.2, IO::Socket::SSL 1.62, Net::SSLeay 1.47, Mojolicious 2.8.5TLS 1.2 No TLS 1.1 No SSL 2.0 INSECURE SSL_RC4_128_EXPORT40_WITH_MD5 (0x20080) WEAK SSL_RC2_128_CBC_EXPORT40_WITH_MD5 (0x40080) WEAK SSL_DES_64_CBC_WITH_MD5 (0x60040) WEAK TLS_RSA_WITH_DES_CBC_SHA (0x9) WEAK Session resumption No (IDs assigned but not accepted) BEAST attack Vulnerable INSECURE (more info) Secure Renegotiation Supported, with client-initiated renegotiation enabled DoS DANGER (more info) The first 2 slightly reduce the rating but are not considered significant because a lot of deployed software doesn't support versions of TLS past 1.0 The WEAK ciphers were removed by adding this to mojolicious SSL_cipher_list => 'ALL:!LOW:!EXP:!ADH', taken from IO::Socket::SSL docs However attempts to remove SSLv2 by trying things like this in the options mojolicious uses SSL_version => 'SSLv3', SSL_version => 'TLSv1', SSL_version => 'SSLv3 TLSv1', SSL_version => '!SSLv2,SSLv3,TLSv1', # based on OpenSSL docs didn't work. In fact the first 2 resulted in the mojolicious server not responding to https. That could be a problem with that software, but is there some way to be as flexible with SSL_version as openssl itself is, as is the case with SSL_cipher_list ? If that was the case you could use something like SSL_version => '-ALL -SSLv2 +SSLv3 +TLSv1' However I think Session resumption BEAST attack Secure Renegotiation need low-level access and I'm not sure Net::SSLeay provides all of these, e.g. BEAST mitigation requires the server to use it's cipher order rather than what client offers.