IBM Domino SMTP, LDAP, IMAP & POP3 over TLS - usefull notes.ini values & best practices

Within the last few months I experienced several issues and interesting behaviour in the TLS communication between Domino servers and other servers - especially for SMTP over TLS.
I just want to share some facts with you - and hopefully you will also add some of your experience.

SSL_ENABLE_INSECURE_SSLV2_HELLO=1
Some customers experienced communication issues with older SMTP clients and also applications that were using ancient OpenSSL version after upgrading there Domino to FP2IF1. This notes.ini parameter were introduced in FP3 IF1 to re-enable the V2 HELO for compatibility reasons.
If you want some more details on this you should visit Daniel Nashed's blog .

RouterFallbackNonTLS=1
Imagine you only enabled the DH-ciphers on your Domino server, enabled STARTTLS and send a mail to a server that is also using TLS but it is only supporting non-DH TLS1.2 ciphers.
What would happen ? Right...the communication will fail and the sender will get a NDR . The console should show some "SSL I/O" error messages:

HTTP Server: SSL handshake failure, IP address [x.x.x.x],
Keyring[keyfile.kyr],[SSL Error: Network IO error], code [4165]

With this .ini-parameter enabled the Domino server won't send a NDR to the sender but instead will fallback to non-TLS communication.
On the one hand this will improve user experience but on the other hand this will also enable MITM attacks & you can't be sure that every communication between you and your partners is encrypted which is why I advise you to not enable this parameter if you want your communication to be secured.


DISABLE_SSLV3=1 & SSL_DISABLE_TLS_10=1
Since SSLV3 and TLS10 were cracked years ago I would definitly advise you to deactivate these protocol versions if you communicate with servers outside of your local network.

IBM Domino and TLS - Part 3 - How To fix your trust & security issues

"The Server accepts the RC4 cipher, which is weak"
You can define the ciphers used/supported by a Domino Server using the .ini - Parameter "SSLCipherSpec=" following hexcodes describing ciphers. Here you will find some examples.
Since 9.0.1.3 you don't have to define specific ciphers. All weak ciphers were deactivated by default.

"There is no Support for secure renegotiation"
Use the .ini-Parameter "SSL_DISABLE_RENEGOTIATE=1"

IBM Domino and TLS - Part 2 - How To fix your trust & security issues

"Certificate uses a weak signature. When renewing, ensure you upgrade to SHA2"
You will only have to request a SHA2 signature the next time you order a certificate from your trusted certificate vendor. In most cases you should also be able to request a change/update of your certificates for no further charge. Please keep in mind that you will have to use the KYR tool to merge SHA2-signed stuff into your keyring.
I recommend reading this article form netcraft.com to get some further Information regarding SHA. Including a cost calculation for cracking SHA1 signed things.

"The server supports only older protocols, but not current best TLS 1.2"
That is a pretty easy one: You will only have to update your Domino Server to the most recent release. Domino supports TLS1.2 starting with 9.0.1.3 IF2.

"The server private key is too small and insecure"
You will have to create a new key with >2048bits and a new certificate/certificate request based on the new key for this. You can use some free tools like XCA or OpenSSL to create this key.
Please keep in mind that the generated keys created by tools like XCA may not be as random as other keys that are created by mouse movement / other random functions.

multiple vulnerabilities in Java SDK affecting Notes and Domino

A few days ago the IBM reported multiple vulnerabilities in the Java SDK that affects all Notes-&Domino Versions - including 9.0.1.5 .
You may find a summary of all(12!) vulnerabilities here and (Notes) here (Domino).

The vulnerabilities reach CVSS Scores  from 4 up to 10(max. value) and should be fixed asap. IBM offers several JVM patches for most Domino/Notes versions. If you can not find what you need you will have to open a PMR and request a custom fix.

Summary

There are multiple vulnerabilities in IBM® SDK Java™ Technology Edition, Version 6 SR16FP15 that is used by IBM Notes Standard Client. These issues were disclosed as part of the IBM Java SDK updates in January 2016 and includes the vulnerability commonly referred to as “SLOTH”.

Just two weeks ago I already needed to update all our Domino Servers because of this vulnerability .

Let us hope that it will be the last one in this quarter.

 

"TLS"-Interim Fixes for IBM Notes and Domino

IBM just released new Interim Fixes for Domino and Notes. Check this out ! You can find the download links here.
Mainly this "fix" activates all industrial standard encryption methods like PFS, HSTS and TLS1.2 for Domino and also for the Notes Client.
In my opionion "IF" is just too small for the content this fix contains. IBM just introduced TLS with a delay of more than 5 years and now they also got 1.2 running. I hope IBM continues to implement new encryption methods for Domino (as soon as they are released).

Before this fix was released you needed to install Domino with IHS(or use a additional Proxy) and configure the IHS to use TLS, PFS etc.
I didn't check the supported cipher methods yet but I think we can uninstall our IHS and start using Domino HTTP again - if you don't need to use TLS1.1. This is still unsupported.


Regards,
Jan

IBM Domino and TLS - Part 1 - How To fix your trust & security issues

Recently a customer asked me how he could raise the site raiting for his iNotes / webmail server .
The rating for his server using a SSL check from from Qualys was T:

iNotes was not accessible eventhough the Domino server itself had no problems at all.
This problem appeared after several modern browsers updated their security policys. I will try to explain what is causing these problems and how you are able to solve them:

"This server's certificate is not trusted, see below for details."
This often indicates that you are using self-signed certificates or certificates that were created/signed from an untrusted CA. I would advise you to buy a SSL certificate from a common seller. You can get them for less than 20$ a year. ROI after the first user of your company doesn't ask you details about this message.

"This server is vulnerable to the POODLE attack. If possible, disable SSL 3 to mitigate."
IBM provided fixpacks for the POODLE exploits and also implemented TLSv 1.0. ( index for fixpacks )
Yes, only v1.0, eventhough v1.2 exists since > 6 years and has already know vulnerabilities.
And you will have to set the .ini-Parameter "DISABLE_SSLV3=1" .

I will discuss the other problems in my next posts.
I would be happy if you could leave some comments on my first part. Or only share this blog with others ;-)

As security seems be something that was left behind the last years in many companys I am trying to revive this topic by writing about things that I get a contact with as a junior consultant at a IBM Premier Business Partner company.

How to run IBM Notes Traveler with two hostnames and multiple SSL certificates

Hello,

recently my company decided to update the certificates to SHA-2-signed-certificates.
The Traveler is accessed by several URLs. One internal URL that is used by "BES"-managed devices and one external URL that is used by Android devices. The server itself only provided one certificate for the public address. While setting up BlackBerry10 devices we needed to manually trust the certificate that was provided by the Traveler.

So....how can I update the certificate without getting security warnings on the BlackBerry10 devices again ? This would be a catastrophe because every device sync would stop until the user accepts the new certificate.


Solution A - Use a Multidomain-certificate

Solution B - Use two certificates and Internet Site Documents for each keyring/certificate on your IBM Notes Traveler server

And also another hint: Collect information about the used URLs for your Traveler by activating the Domino Weblog .


Greetings,
Jan