Daniel Nashed 1 April 2015 12:24:03Yesterday at engage conference in Ghent (http://www.engage.ug/) I gave an updated presentation based on the ConnectED 2015 presentation.
I added most of the new notes.ini parameter and also information how to enable those new ciphers and rewrote/reordered a bunch of slides and added more information after the latest IF has been shipped.
During the conference I got the question what I would recommend .
Here is what I would recommend for the latest fix -- which is sort of a short summary of the presentation.
By the default some of the new ciphers are already enabled. And all other security functionality introduced is enabled by default. I would recommend not to disable them if you don't really need to.
There are a couple of options that you might still want to consider based on your environment.
Note: The current IF does completely ignore all SSL settings in the server/internet site doc.
With previous fixes you have been able to specify the ciphers still in the server/internet site doc but it was recommended to already make changes using the SSLCipherSpec described in the presentation.
-- Disable SSLv3 --
I think it is time to completely disable SSLv3 on Domino because almost all applications and browsers support at least TLS 1.0
-- Re-Enable SSL V2 HELLO if you really have to --
If you are running a public SMTP Server you don't control what you customers, partners and other do with their SMTP servers.
In some cases they are still using an older version which still tries an old SSL V2 HELLO.
By default Domino has this old version of the handshake disabled.
As blogged before you can re-enable it since the previous IF with the following notes.ini variable.
-- Enable DHE Ciphers if you need "PFS" --
If you are interested using the new PFS ciphers I mentioned in my last blog post (DHE ciphers which will provide PFS for most clients) you really have think about balancing higher overhead in CPU and maybe slower response time with security.
You could enable it and check what additional CPU overhead you have afterwards.
A good cipher spec to configure in that case would be:
This would give you the currently enabled default ciphers + the new DHE ciphers which are not enabled by default for performance reasons.
9D = RSA_WITH_AES_256_GCM_SHA384
9C = RSA_WITH_AES_128_GCM_SHA256
3D = RSA_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
New DHE ciphers (for PFS support) not enabled by default
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
-- In case of Java Apps reduce the DHE Key Size used --
In addition if you have Java applications accessing your server they will use the DHE ciphers.
But Java 1.6 and 1.7 do only support key length up to 1024 bit.
So in that case you have to reduce the key length for the DHE ciphers (which will let the DHE ciphers be rated as sort of "weak" by some SSL testing sites).
-- Get a proper SHA-256 based Certificate --
In addition you have to ensure that you are using a proper SHA-256 based certificate.
That's a very short summary or recommendations from my presentation depending on your needs.
You should be careful when you disable some of the default ciphers.
All of them are currently rated as secure. And if you disable cipher you could end up having no cipher in common for one of your SSL clients.
I hope this short summary is helpful.
- Comments