Not sure about advice given re: RC4 ciphers

HCL Domino Domino Forum
1

Our company uses Google (now called G Suite) to scan all of our inbound mail for spam and viruses before passing through to our servers

Everything has been working fine until around Oct 12th. One of our users indicated that a sender was getting a delivery failure with a permanent error of “read error: generic::failed_precondition: read error (0): error”.

I couldn’t really find anything on line and figured maybe I needed to the sender to our safe sender list. I don’t know if that would make any difference.

Two days later I found out that an IT user is having issues receiving, intermittently, from a sender that we receive emails from frequently. Some were getting through and others had the same error when I looked in the Google logs.

The logs indicated that their system was transferring the messages to the Google pipeline and allegedly delivering to the users gmail box, (which then passes to our server) but these messages would never reach our server, so users wouldn’t know that they hadn’t received an email unless the sender followed up for some reason.

After opening a ticket and then having the re-route it because they thought we were having issues sending (not receiving) messages it reached the appropriate group.

They claim that a) this has been happening since July (but we wer unawares) and b) that the issue is on our end. They have pointed out a problem with the Recursive Queries assigned by our DNS host (Network Solutions) that could be causing some problems on our server. However, they say the error we are getting (read error: generic::failed_precondition: read error (0): error) could be a different problem. They then go on to

They then go on to say:

Google announced deprecation of RC4 in September 2015 and began its gradual roll-out on June 16th 2016. On July 26th, the deprecation finally hit Google SMTP servers and this is when your organization could be encountering mail delivery issues. Based on our investigation, the TLS connections switched to another cipher suite which appears to fail intermittently due to an implementation bug on the receiving end (mail.polyair.com).
Based on the assumption that our disabling of RC4 was the cause of delivery failures, we recommend you disable RC4 to attempt to confirm the issue.

And that’s where I run into issues because I have no idea what I’m supposed to do. We don’t have SSL on our two servers that handle the SMTP traffic (and I know I should). This is what the server documents look like on the Ports - Internet Ports tab.

Should I be unchecking the 3 that reference RC4?

They want me to confirm if this is the issue, but since I don’t know when the issue will crop up, how am I supposed to know if it worked? And by disabling these, am I opening up some other issue?

Any help would be appreciated.

Thanks,

Pam

2

Subject: I haven’t made changes in a year

The servers in question both run Domino 9.0.1.FP4 and have done so since October/2015.

I don’t apply fixpacks unless there is an issue, because if it ain’t broke, don’t fix it.

I do not have SSL enabled on these two servers.

I cannot duplicate the issue that has been experienced.

It is an intermittent issue, apparently, that can affect senders from whom we have previously received emails.

3

Subject: And thanks, Dave Kern. I was having trouble with the FP descriptions.

You cleared up some things for me as to what’s going on in this vein.

Is FP7 the first fixpack that ignores the existing settings, or was that an older feature?

4

Subject: No problem…

The first release that ignored the UI configuration settings for version (SSLv3, SSLv2, and a few permutations of those two) was the release that added TLS 1.0. Since TLS 1.0 wasn’t in the UI and we couldn’t update the UI in a IF or FP, the only option was to ignore the UI and rely on the new notes.ini settings with sane defaults.

https://www-10.lotus.com/ldd/dominowiki.nsf/dx/IBM_Domino_TLS_1.0 https://www-10.lotus.com/ldd/dominowiki.nsf/dx/IBM_Domino_TLS_1.0
https://www-10.lotus.com/ldd/dominowiki.nsf/dx/SSLv2 https://www-10.lotus.com/ldd/dominowiki.nsf/dx/SSLv2

The first release that ignored the UI configuration settings for ciphers was the release that enabled TLS 1.2 and added the DHE ciphers for forward secrecy plus the AEAD (AES-GCM) and SHA-2 (SHA256, SHA384) ciphers. Since those new ciphers weren’t shown in the UI and we couldn’t update the UI in an IF or FP, the only option was to ignore the UI and rely solely on the existing notes.ini setting (SSLCipherSpec) for cipher configuration.

https://www-10.lotus.com/ldd/dominowiki.nsf/dx/TLS_1.2 https://www-10.lotus.com/ldd/dominowiki.nsf/dx/TLS_1.2
https://www-10.lotus.com/ldd/dominowiki.nsf/dx/TLS_Cipher_Configuration https://www-10.lotus.com/ldd/dominowiki.nsf/dx/TLS_Cipher_Configuration

5

Subject: Just to be sure what’s going on, Pam: were any fixpacks applied at the time you last ran into the prob?

I’m trying to get a handle on exactly what circumstances produce what kinds of issues.

6

Subject: I don’t have SSLCipherSpec in my notes.ini

Thanks for the replies.

Dave - If If upgrade to FP7 is that all I need to do or should I modify and deselect any entries in the SSL Cipher Settings screenshot in my original post?

7

Subject: Upgrading 9.0.1 FP4 or better will do the trick…

… but I would highly recommend FP7, as there have been many performance and security improvements made since between FP4 and FP7.

Domino FP4 (technically, Domino FP3 IF2) is when TLS 1.2 was added and the old UI configuration options were disabled.

https://www-10.lotus.com/ldd/dominowiki.nsf/dx/TLS_1.2 https://www-10.lotus.com/ldd/dominowiki.nsf/dx/TLS_1.2

8

Subject: Upgrade to the latest FP, remove the SSLCipherSpec notes.ini, and any RC4-related problems will go away.

Recent FPs of 9.0.1 support TLS 1.2 and a host of modern ciphers by default. The UI configuration that you showed is not used, instead secure defaults are used that can be overridden with the SSLCipherSpec notes.ini.

https://www-10.lotus.com/ldd/dominowiki.nsf/dx/TLS_Cipher_Configuration https://www-10.lotus.com/ldd/dominowiki.nsf/dx/TLS_Cipher_Configuration

9

Subject: ok, here comes the very complicated response.

You can remove the RC4 keys by deselecting them.

It might work. It depends on whether there are any keys left that’ll authenticate with the contacting server.

Now you may ask, how do you tell?

It seems to be a black art. We’ve noticed when there are piles of other settings in the certificates & keyfile … files … specifying when it’s appropriate & not to use a cipher, it’s become almost impossible to tell whether a cipher will work for a particular use unless you “try it”.

Still, to keep you informed about what I’ve run across, here’s the complicated & technical note IBM released on the ciphers now supported.

https://www-10.lotus.com/ldd/dominowiki.nsf/dx/TLS_Cipher_Configuration https://www-10.lotus.com/ldd/dominowiki.nsf/dx/TLS_Cipher_Configuration

It seems you can override the settings you’ve screen-shot using the Notes.INI variable, “SSLCipherSpec”. It doesn’t seem to me this is an action for the fat-fingering-faint-of-heart. But hey, it looks like it can be done. I assume it can be done from the “Server Configuration” document. The format looks like it’s a long string of hex describing in arcane naming, which cipher to use “next”.

There’s not an example of a realistic cipher setting at the link. There’s one unrealistic example. Does anyone have a realistic example of these ciphers in use?

There’s also the remarkable potential issue:FP4’s “SSLCipherSpec” formatting is not backward compatible in FP5’s “SSLCipherSpec” formatting.

I’m unsure how to determine that a Domino server actually has the certificates & keyfiles, too: files that could actually deliver keys that would allow Domino to ahem, actually use these encryption schemes. There must be something out there saying how. I don’t know what it is.

I’ve read Domino’s “nonversion release” strategy has complicated matters as well. The postings told me they hadn’t updated the complete list of available ciphers on the Address Book, and so … well I don’t know how to enable ciphers that are “there”, but not “available”. Maybe more googling could’ve told me that too. I abandoned the issue 'til a more opportune time. Unfortunately it looks as though you’re in great need of the answer I also tried to get.

But maybe this’ll help. I hope it does.

10

Subject: Just to be sure what’s going on, Pam: were any fixpacks applied at the time you last ran into the prob?

I’m trying to get a handle on exactly what circumstances produce what kinds of issues.