ROBOT SSL/TLS Attack
Daniel Nashed – 17 January 2018 03:41:02
This has not been widely discussed yet. But since SSL Labs will start reporting it with a rating of F beginning of February let me explain some background and what you could do. The issue has been there in a similar way before and is back. You can read the details here --> https://robotattack.org/
Affected are the older ciphers that are not widely used by current browsers/client. You could disable those ciphers until the issue is fixed.
But on the other side most browsers/clients do support higher secure ciphers. And because by default the server cipher order is used, a client should not choose a weaker cipher.
In addition because of Secure Renegotiation which is supported by Domino and most browsers/clients support it, no weaker cipher will be used than the best common cipher between client and server.
That means that only a very small fraction of connections might use those affected ciphers and if you disable those the client cannot connect at all.
A fix for the ROBOT Attack is planned for FP10.
So IMHO there is no need right now to disable those affected older RSA ciphers unless you have very high security requirements or if you are concerned about your SSL labs rating ..
If you disable those affected ciphers the warning on the SSL Labs test side goes away.
Here is a more paranoid configuration of TLS ciphers that you could use:
set config SSLCipherSpecÀ30009FC02F009EC028006BC0140039C02700670033C013
restart task http
If you look into the compatibility report, there is no current client that could not connect any more (even older IE versions would connect).
The other positive effect would be that you would only support DHE and ECDHE ciphers which is a good idea in general..
UPDATE 17.01.2018
Andy Brunner had an interesting comment. In my cipher list I am still having 0033 which is rated as a weak cipher which is not enabled by default.
I have a cipher configuration database where I still had that cipher listed.
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)
If you still have this cipher listed and did not allow weak ciphers the server will give you a hint:
SSLDisableExportCiphers> Disabling weak cipher DHE_RSA_WITH_AES_128_CBC_SHA. Set notes.ini "USE_WEAK_SSL_CIPHERS=1" to re-enable.
So the better fitting cipher liste in this case would be
set config SSLCipherSpecÀ30009FC02F009EC028006BC0140039C0270067C013
restart task http
The mentioned cipher is rated as weak by Domino because it is a cipher that internally uses "SHA"
Update: I almost forgot and got reminded about this Java 1.6 issue.
The cipher is rated as weak for another reason. Older Java can only support this DHE cipher with 1024 bit.
That's a longer story which you can find details here --> http://blog.nashcom.de/nashcomblog.nsf/dx/dha-with-more-than-1024-key-size-and-java-still-works.htm
and another blog post here with some more details and ideas --> http://blog.nashcom.de/nashcomblog.nsf/dx/higher-crypt-standards-with-notesdomino-and-jvm-1.6.htm
-- Daniel
- Comments [1]
![[HCL Domino]](../lotus-domino.gif){kind=small}
![[Domino on Linux]](../domino-linux.gif){kind=small}
![[Nash!Com]](../nashcom.gif){kind=small}
![[Daniel Nashed]](../daniel-nsh.gif){kind=small}