After releasing TLS Coverage Improvements in Nexpose 6.0.2 we figured that the Nexpose Security Console should be able to abide by our own suggestions. Last year we had already disabled SSLv3 support by default and allowed configuring what other protocols are enabled on the console as well. With this week's release we're limiting the TLS cipher suites available to the console's web server by default. Similar to the protocols, the cipher suites can also be configured to be more or less strict as required by your organization.
Configuring SSL/TLS Protocol and Cipher Settings
Currently, these settings are configured through the CustomEnvironment.properties file, which can be created/edited in the [installation path]/nsc/ directory. A restart of the Nexpose service is required for changes to take effect. The following examples reflect the default settings, which means setting them exactly as shown will not change anything.
For SSL/TLS protocols, the following parameters are allowed:
To configure the enabled protocols, add the following line to the file where each protocol is separated by a comma without any spaces:
For cipher suites, you can use either Apache-style syntax or JSSE syntax. To configure the enabled cipher suites using Apache-style syntax, add the following line to the file:
If the default cipher suites are not suitable for your use, we suggest reviewing the recommendations from Mozilla as they are quite comprehensive: Security/Server Side TLS - MozillaWiki.
If your Nexpose Security Console is still using a SHA-1 certificate (generated more than a year ago), you have a few options to upgrade the certificate strength. If you're using the generated self-signed certificate, you can simply generate a new one from the Administration > Administer Console page. Under the Web Server settings click the Manage Certificates button, then generate a new certificate. A restart of the Nexpose service is required for the new certificate to be used.
If you're using a certificate signed by an internal or external Certificate Authority (CA) you can generate a new CSR, which requires generating a new self-signed certificate as well. Note that if the parameters of the CSR are not satisfactory for your requirements, your CA may allow overriding some of the settings related to algorithms when signing the certificate.
In the future we hope to expand the functionality around certificates and TLS connections from the user interface. We would love to hear your feedback on what options you need the most and how you would like to use them.