Retiring old ciphers.
Cyber security compliance and best practices are something we all aim to achieve. As time goes on, we’re starting to see legacy protocols and weak cipher sets being phased out in favour of strong more robust protocols. Kemp have made this process easily accessible to our customer, allowing the creation of custom cipher sets.
A weak Cipher can be defined as an encryption algorithm that uses a weak or insufficient key length. These ciphers have a high probability that the encryption method could be broken and should be removed to ensure your application is using the strongest ciphers possible. You can customise ciphers on the LoadMaster using Cipher Set Management under Certificates & Security > Cipher Sets and then apply the cipher set to your chosen virtual service. While doing this is very easy, it can often cause problems for the end user as their devices may be using a legacy OS or cipher sets. Once’s the changes have been made these users will no longer be able to connect to the virtual service and will receive a generic SSL message in the browser.
With the release of firmware 7.2.52 it is now possible to add SSL/TLS information in the Client Request Headers and pass these headers along to the back-end server. This information can be useful for maintain ciphers sets over time as it will allow you to identify which ciphers are being used and you can then plan on what ciphers to change or delete.
Configuring a Virtual Service to use the Add Received Cipher Headers.
Select a virtual service with SSL Acceleration enabled, Virtual Services > View/Modify Services. On the selected Virtual Service navigate to SSL Properties, Check Add Received Cipher Name.
New Headers will be added to any traffic going to the real servers. These headers and values can be seen in the tables below.
Header |
Description |
Content Rule Variable |
|
X-SSL-Cipher |
The cipher used. |
ssl-cipher |
|
X-SSL-Protocol |
The SSL protocol version used. |
ssl-version |
|
X-SSL-Serialid |
The Virtual Service certificate serial number. |
ssl-clientserialid |
|
X-SSL-ClientSerialid |
The client certificate serial number. |
ssl-serialid |
|
X-SSL-SNIHost |
The value of the received SNI name. |
ssl-sni |
The table below shows examples of the header values.
Header |
Example Value |
X-SSL-Cipher |
ECDHE-RSA-AES256-GCM-SHA384 |
X-SSL-Protocol |
TLSv1.2 |
X-SSL-Serialid |
4900000006A2ABDC165ACEAD55000000000006 |
X-SSL-ClientSerialid |
490000005D6898F3C7E590536100010000005D |
X-SSL-SNIHost |
sni.test.com |
The X-SSL-ClientSerialid will only be added if client certs are used and X-SSL-SNIHost will be added if the option for SNI have been enabled on the virtual service.
Configuring Custom IIS Logging Fields on Microsoft Server 2012
In IIS 8.5 and later, custom logging fields is possible and can be used to log the new headers being sent to the IIS server. Navigate to the site which will use Received Cipher Header’s for logging and click Logging and Open Feature.
Click the Select Fields... option
Click the Add Field... option.
Configure the fields as indicated below: Repeat these steps for each of the required Headers.
Now generate some traffic and view the logs under the default folder x:\inetpub\logs\LogFiles\W3SVC1.
An Example of the logs is shown below. The HTTP request Method is displayed along with the backend server port. The User Agent string shows the browser being used.
2021-06-24 11:22:14 10.4.139.80 GET / - 80 - 10.1.158.90 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/86.0.4240.75+Safari/537.36 - 200 0 0 88 TLS_AES_256_GCM_SHA384 TLSv1.3 12375019 10.0.37.28
Header |
Value found |
X-SSL-Cipher |
TLS_AES_256_GCM_SHA384 |
X-SSL-Protocol |
TLSv1.3 |
X-SSL-Serialid |
12375019 |
We can now discern the ciphers and protocols being used by our clients. Priory to modifying the cipher certs we can use this information to determine how many clients will be affected by our changes. Using an Additional X-Forward-For header in the Virtual Services Advance options, will also enable the LoadMaster to add the true client IP in a header and send this to the IIS log. This can be used to catalog the IP addresses and ciphers before making a decision to modify the cipher suites on the Virtual Service.