Domino on Linux/Unix, Troubleshooting, Best Practices, Tips and more ...

alt

Daniel Nashed

First Perfect Forward Secrecy Ciphers shipped with 9.0.1 FP3 IF2

Daniel Nashed – 30 March 2015 11:14:58
As posted before IBM shipped a new IF (9.0.1 FP3 IF2/IF3) that introduces TLS 1.2 Along with this new version a set of ciphers have been added.
Some of them are enabled by default and other can be enabled using notes.ini settings.

Other ciphers that are regarded as "weak" have been removed from the default cipher list.


Update: Also check for additional information in the new Wiki article -->
http://www.lotus.com/ldd/dominowiki.nsf/dx/TLS_Cipher_Configuration

So by default without any additional settings you get the ciphers that IBM currently recommends.

What has been added to the default are the AEAD (AES-GCM) ciphers -- see details below.


There are additional ciphers that will provide "Perfect Forward Secrecy" (PFS) for some platforms/browsers.


IBM implemented Ephemeral Diffie-Hellman (DHE) ciphers. Those ciphers are used by many but not all platforms.

That's why even if you enable them you the SSL Test Site will not give you a better rating because not all the reference browsers will use PFS.


In addition those ciphers have a higher overhead to your Domino Server. Therefore IBM left the decision which cipher to add to administrators.

You have to find the right balance between security and performance.
Probably on a smaller server it will not have that much overhead. But on a larger server you might want to take special care and watch the CPU load of your server before and after you enabled the DHE ciphers!


The current default setting is that the cipher order on the server takes preference.

As mentioned before all the fixes currently have no design change because that will have to wait until 9.0.2.

Therefore also the cipher spec has to be enabled using notes.ini settings as already described in our ConnectED presentation.


There is a notes.ini setting described in a recent Wiki entry. Each cipher has an internal reference number that is standard.

Domino uses the two digit hexadecimal number to specify the ciphers you want to have enabled on your server.

The order of entries does not matter. You just have to make sure that you always use a two digit value per cipher -- even the cipher itself might have just one hex digit.

There is no space between the cipher numbers.



Here is what you get by default without any changes:


SSLCipherSpec=9D9C3D3C352F0A


9D = RSA_WITH_AES_256_GCM_SHA384

9C = RSA_WITH_AES_128_GCM_SHA256

3D = SA_WITH_AES_256_CBC_SHA256

3C = RSA_WITH_AES_128_CBC_SHA256


35 = RSA_WITH_AES_256_CBC_SHA

2F = RSA_WITH_AES_128_CBC_SHA

0A = RSA_WITH_3DES_EDE_CBC_SHA



In addition to that you have the folllowing new DHE ciphers available.


33 - DHE_RSA_WITH_AES_128_CBC_SHA

39 - DHE_RSA_WITH_AES_256_CBC_SHA

67 - DHE_RSA_WITH_AES_128_CBC_SHA256

6B - DHE_RSA_WITH_AES_256_CBC_SHA256

9E - DHE_RSA_WITH_AES_128_GCM_SHA256

9F - DHE_RSA_WITH_AES_256_GCM_SHA384


So as an example when you want to enable all DHE ciphers and keep the other ciphers you set the following notes.ini setting and restart the servertasks like http.



SSLCipherSpec=9D9C3D3C352F0A
3339676B9E9F

So you could add those ciphers to your cipher list using the notes.ini setting.

Once you are done you can use the SSL Labs Test Website
https://www.ssllabs.com/ssltest/ to check if the ciphers are properly configured.
What is nice on the website is that the website will "simulate" which client type will probably use which type of cipher when connecting given the current settings of your server.


Now you should have all the default ciphers and the DHE ciphers enabled.


You should take special care which ciphers to disable because you could block out certain devices types.


When testing with the SSL Tabs Test and also using Java applications I noticed that they will pick the DHE ciphers.

But Java 1.6/1.7 does currently not support more that 1024 bits. By default Domino uses higher key-length.


So Java sees that DHE ciphers are enabled and will try to use them. And it does not check before using it that it cannot handle larger key sizes than 1024.


That means if you enable DHE ciphers you might have to consider to lower the key-length used.
If you change the key-length to 1024 the SSL Labs Test site will report that your key is "weak".


So you have to balance lower security with compatibility at this point.


There is a notes.ini setting to specify the key-length for DHE ciphers.


You could set notes.ini SSL_DH_KEYSIZE=1024 to resolve this incompatibility.


There have been also discussions about other PFS ciphers that are used by other applications like older IE versions.


"Elliptic Curves ciphers" (ECDHE..) are supported by older IE versions and by Windows mobile.
But they are currently not implemented on the Domino side.


All the development work in this area based by priorities and demand. And IBM is releasing it step by step with IF fixes.

It's not confirmed IBM is working on those type of ciphers. I just wanted to mention it to explain why not all platforms will use PFS ciphers when you enable the DHE ciphers.

Also the ECDHE ciphers have better performance than the DHE ciphers. But the first priority was to implement the DHE ciphers because most platforms support it.

This was for sure not the last functionality update we get via a IF. I am looking forward to see that is next on the list.


Not all of the notes.ini settings are documented yet. I expect that IBM will publish another Wiki article soon.

I might update this blog entry or have a more complete article with more details as soon more information is available.


-- Daniel

Comments

1Craig Wiseman  01.04.2015 17:06:04  First Perfect Forward Secrecy Ciphers shipped with 9.0.1 FP3 IF2

Thanks (as always) for this post.

I'm going to play around with this, but I'll ask before I get a chance to:

Have you noticed if this removes the old Domino rule of one separate IP address req'd for each SSL certificate?

2Daniel Nashed  02.04.2015 9:21:43  First Perfect Forward Secrecy Ciphers shipped with 9.0.1 FP3 IF2

@Craig, this limitation still exists and is a general SSL limitation. The http server name is in the encrypted request.

The only work-around that for example reverse proxies do is to use a wild-card cert and decrypt the request and than check the host name requested.

The other approach is to use SNI (http://en.wikipedia.org/wiki/Server_Name_Indication) but that needs to be supported on client and server side support.

Domino currently does not support SNI.

3Craig Wiseman  06.04.2015 20:49:43  First Perfect Forward Secrecy Ciphers shipped with 9.0.1 FP3 IF2

Thanks... SNI is the acronym I was trying to remember!

I knew it was a general SSL restriction/definition, and SNI is the way around it... if (as you say) both sides support it.

4Matthias Wille  13.09.2016 10:35:46  First Perfect Forward Secrecy Ciphers shipped with 9.0.1 FP3 IF2

Is SNI support planned for any of the fix packs to come? 9.0.2 is not come as I understand and FP6 still doesn't seem to support SNI.

5Daniel Nashed  16.09.2016 8:51:59  First Perfect Forward Secrecy Ciphers shipped with 9.0.1 FP3 IF2

@Matthias, I have not seen SNI on any feature list yet. It is not in FP7 but it was discussed a while ago.

The change is not simple because it might need also some UI configuration change depending on how they implement it.

We are still waiting for an official statement how IBM will continue with the Domino roadmap.

Ed Brill will hopefully says something about it next week on an event here in Germany.

Links

    Archives


    • [HCL Domino]
    • [Domino on Linux]
    • [Nash!Com]
    • [Daniel Nashed]