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

alt

Daniel Nashed

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



Image:ROBOT SSL/TLS Attack
Comments

1Andy Brunner  17.01.2018 5:45:16  ROBOT SSL/TLS Attack

Thanks, Daniel!

I think there is a typo in the SET CONFIG statement. Shouldn't it read

SSLCipherSpec=C030009FC02F009EC028006BC0140039C0270067C013

Andy

Links

    Archives


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