Hey, Mark! Thanks for the update!

I just made the same change and tested - for me, SSLv3 also now shows as disabled in the Qualys SSL test - but I received a 'B'  rating

The other 'errors' that I receive are:

The server supports only older protocols, but not the current best TLS 1.2. Grade capped to B.
This server accepts the RC4 cipher, which is weak. Grade capped to B.  MORE INFO »
There is no support for secure renegotiation.  MORE INFO »
The server does not support Forward Secrecy with the reference browsers.  MORE INFO »

Note that I recently disabled (another thread) AES and 3DES encryption - that brought my score from an 'F' to a 'B'.  The only ciphers that I'm now using are:

TLS_RSA_WITH_RC4_128_MD5 (0x4)   WEAK        128
TLS_RSA_WITH_RC4_128_SHA (0x5)   WEAK        128

Oh, you know, I think that the logic behind the Qualsys SSL test changed the other night - because I had noticed Monday night my grade had fallen to an 'F'. - I'll bet you still have 3DES enabled - disable that and you'll get a 'B'.

http://blog.darrenduke.net/Darren/DDBZ.nsf/dx/poodle-tls-the-poodle-strikes-back.htm

"Set correctly" is just an opinion.  I saw the Darren Duke blog a day ago or so.  The Qualys thing is great, and it's proven indispensable during these SSL issues.  However, the problem isn't so simple, and configuring a system to score well on a single test may or may not translate to the real world.

The problem with removing the AES ciphers and leaving the RC4 to get a "B" on the test is that many have argued previously that it is the RC4 ciphers that should be disabled.  To wit:

http://blog.cloudflare.com/killing-rc4-the-long-goodbye/

"We recently removed support for RC4 for browsers using TLS 1.1+. Now we are removing RC4 as the preferred cipher. Servers behind CloudFlare will prefer AES-based cipher suites..."

http://www.acunetix.com/blog/articles/tls-ssl-cipher-hardening/

"Furthermore, it is also crucial to disable weak ciphers. Weak ciphers such as DES and RC4 should be disabled. Using current technology, DES can be broken in a few hours while RC4 has been found to be weaker than was previously thought. While it may have been advised to use RC4 to mitigate BEAST attacks in the past, given the latest attacks on the RC4 cipher, Microsoft has issued an advisory again its use."

Just two examples from a quick search.  Microsoft apparently advises against using RC4.  Cloudflare, an awesome vendor we use, removed support for RC4 for TLS 1.1+ (yes, I know we're stuck at 1.0).

Many of the ciphers and SSL/TLs versions each have different vulnerabilities.  If you offer a very narrow set of ciphers (i.e. exactly two in this case), and a connecting client or SMTP server (TLS isn't just about HTTP...) has removed those due to some other valid security reason and only offers different ciphers, no secure connection can be made.

The point is, it's not so simple to choose what to do here without risking breaking something else.  IBM needs to rebuild Domino's SSL/TLS support from the ground up, and it needs to look forward to TLS 1.3 that is expected to be approved in 2015, as well as SHA3.

I agree that going RC4 is *not* the best solution, but if you're running Domino directly on the web (i.e. no proxy, hint, hint, cough, cough) then that is probably your best course of action right now. Not, perfect, but again, weak is better than compromised.

The real solution is for IBM to finally take Domino's HTTP stack seriously and provide at least TLS1.2 and a new set of up-to-date cipher suites. Until that happens use only RC4 or put a proxy in they way (FYI, there is a freely downloadable Apache proxy built on Ubuntu for iNotes and other Domino stuff on my blog if you want to go that way).

If however you are stuck with a provider who is forcing your hand, then go another way. It's all trade offs at this point anyway.

Totally agree, except I want to take it one step further. IBM needs to re-acquire it's leadership position in security and PKI. It shouldn't be catching up to current standards, it should also be putting the ciphers and protocols into its products that will become the future standards, before they are: that's the product's history, will it be the future?

Release 1.0 offered the following functionality, much of it revolutionary in 1989:

• Encryption, signing, and authentication using the RSA public-key technology, which allows you to mark a document in such a way that the recipient of the document can decisively determine that the document was unmodified during transmission. Lotus Notes was the first important commercial product to use RSA cryptography, and from that point on, users considered security as a prime feature of Lotus Notes.

"It's all trade offs at this point anyway."

Agreed. Pick your poison.

BTW, your blog has been a big asset during this.  Used it earlier to get an SHA-1 cert going on IHS with that special version of ikeyman.  Thanks.

Now that we've upgraded our Domino server version 9.0.1 FP2 IF1, whenever an IE user with "Use SSL 2.0" setting selected goes to the site they get a page cannot be displayed.  It doesn't matter is they have "Use SSL 3.0" or "Use TLS 1.0" selected.

Here is the setting: http://i.imgur.com/6qO0b5a.png

Would this INI setting get around this since it turns off all SSL support for Domino?

Thanks Dave, I have read that.  Very well written BTW.  So there appears that there isn't a server side solution to the problem.  The issue is that our client is a military base and their machines are locked down and they can't make these changes.  Do you think a future patch will keep SSLv2 disabled, but allow the handshake?

I ended up installing an nginx proxy server in front of Domino.  Now I have support for TLS 1.0, 1.1 and 1.2.