Mar 30, 2015 3:40 PM
122 Posts

IBM Notes and Domino Interim Fixes to support TLS 1.2

  • Category: Domino Server,Security
  • Platform: All Platforms
  • Release: 9.0.1
  • Role: Administrator
  • Tags: domino,Interim Fix,security,SSL,ssl kyrtool,tls
  • Replies: 6
As follow up to delivery of Transport Layer Security (TLS) 1.0 support in 4Q2014, this page introduces TLS 1.2 support in Notes 9.0.1 FP3 IF 3 and Domino 9.0.1 FP3 IF2
http://www-10.lotus.com/ldd/dominowiki.nsf/dx/TLS_1.2
Apr 1, 2015 8:52 AM
26 Posts
Supported Ciphers?

Hello,

 

is there a list which Ciphers are supported by Domino  for TLS 1.0 and 1.2?

Apr 1, 2015 8:52 AM
92 Posts
Yes, and more info coming
I updated the existing article in the N/D wiki for the SSLCipherSpec notes.ini with the new ciphers:

http://www-10.lotus.com/ldd/dominowiki.nsf/dx/SSLCipherSpec

and will be posting a new article with detailed information about TLS cipher spec configuration within the next day or two.

The AES-GCM, SHA256, and SHA384 ciphers are only defined for TLS 1.2, but the others will work as far back as SSLv3. Naturally, I would recommend against using any of the weak ciphers listed in italics.
Apr 1, 2015 12:25 PM
26 Posts
Doesn't work as expected..

TLS 1.2 is working. But I have disabled TLS 1.0 wit the notes.ini parameter SSL_DISABLE_TLS_10=1.

But Domino still offers TLS 1.0 when negotiating. (But not always)

0A88:000F-1050] 01.04.2015 18:19:32,50 SSLInitContext> 0 Available cipherspec: 0x009D
[0A88:000F-1050] 01.04.2015 18:19:32,50 SSLInitContext> 1 Available cipherspec: 0x009C
[0A88:000F-1050] 01.04.2015 18:19:32,50 SSLInitContext> 2 Available cipherspec: 0x003D
[0A88:000F-1050] 01.04.2015 18:19:32,50 SSLInitContext> 3 Available cipherspec: 0x0035
[0A88:000F-1050] 01.04.2015 18:19:32,50 SSLInitContext> 4 Available cipherspec: 0x003C
[0A88:000F-1050] 01.04.2015 18:19:32,50 SSLInitContext> 5 Available cipherspec: 0x002F
[0A88:000F-1050] 01.04.2015 18:19:32,50 SSLInitContext> 6 Available cipherspec: 0x000A
[0A88:000F-1050] 01.04.2015 18:19:32,50 SSL_TRUSTPOLICY>  bits for signature hashes: 0004
[0A88:000F-1050] 01.04.2015 18:19:32,50 int_MapSSLError> Mapping SSL error 0 to 0 [SSLNoErr]
[0A88:000F-1050] 01.04.2015 18:19:32,50 SSL_Handshake> Enter
[0A88:000F-1050] 01.04.2015 18:19:32,50 SSL_Handshake> Current Cipher 0x0000 (Unknown Cipher)
[0A88:000F-1050] 01.04.2015 18:19:32,50 SSL_Handshake> outgoing ->protocolVersion: 0303
[0A88:000F-1050] 01.04.2015 18:19:32,50 SSLEncodeClientHello> We offered SSL/TLS version TLS1.0 (0x0301)
[0A88:000F-1050] 01.04.2015 18:19:32,50 SSLProcessServerHello> Server chose SSL/TLS version TLS1.0 (0x0301)
[0A88:000F-1050] 01.04.2015 18:19:32,50 SSLProcessServerHello> Server chose cipher spec RSA_WITH_AES_256_CBC_SHA256 (0x003D)
[0A88:000F-1050] 01.04.2015 18:19:32,50 FindCipherSpec> Cipher spec RSA_WITH_AES_256_CBC_SHA256 is not supported with TLS1.0
[0A88:000F-1050] 01.04.2015 18:19:32,50 SSLSendAlert> Sending an alert of 0x2F (illegal_parameter) level 0x2 (fatal)

 

Seems like the Domino Server first offers Ciphers that don't work with TLS 1.0 and then offers only TLS 1.0 instead of 1.2

Apr 1, 2015 2:52 PM
92 Posts
That looks like outbound, not inbound....
The way that SSL/TLS works is that the client offers its highest supported protocol version and a list of ciphers to the server and the server selects what version of the protocol and what cipher from that list will be used. The server can select a lower protocol version, but not a higher version.

The DISABLE_SSLV3 and SSL_DISABLE_TLS_10 notes.ini variables prevent Domino when acting as an SSL/TLS server from choosing those protocol versions. It does not prevent the remote server from selecting SSLv3 or TLS 1.0, or cause Notes or Domino to reject a connection  because the remote server selected one of those versions.
The line

[0A88:000F-1050] 01.04.2015 18:19:32,50 SSL_Handshake> outgoing ->protocolVersion: 0303

from your log shows that you are configured to use TLS 1.2. When acting as a client and configured to use TLS 1.2, Domino will always offer the full TLS 1.2 cipher list. If the server selects a lower protocol version, it is their responsibility to select a cipher that works with the selected protocol version.  

The only reason for N/D to be configured for TLS 1.2 but to offer TLS 1.0 to the server would be when resuming a previously negotiated session where the server had negotiated down to TLS 1.0.   RFC 5246 states that clients MUST include at least the cipher that was used in the original session when attempting resumption, and since Domino offers the original cipher list this will be true.  RFC 5246 also states that "For resumed sessions, this field [the ServerHello cipher_suite] is the value from the resumed session state".


It sounds like Domino (TLS client) initially offered TLS 1.2 and the full cipher list, and the TLS server responded with TLS 1.0 and (presumably) a TLS 1.0 cipher suite.  Domino then attempted to resume the session, offering TLS 1.0 and the same cipher list, but the TLS server responded with TLS 1.0 and a TLS 1.2 cipher suite.

What server are you attempting to reach when you see that error? Could you post the section of the console log that covers both connections to that TLS server? Thanks!

Apr 11, 2015 4:53 AM
26 Posts
Found a workaround and more questions

The Workaround is quite simple. Since the Servers negotiate a TLS1.0 Protocol with a Cipher that is only supported by TLS 1.2, I have used the SSLCipherSpec notes.ini Variable to restrict Ciphers to a set that is supported bei both Versions.

I added The Line "SSLCipherSpec=3933352F0A" to the notes.ini and Problems were gone!

 

Now my questions to Dave (hope he is still reading this)

You wrote that the notes.ini parameters DISABLE_SSLV3 and SSL_DISABLE_TLS_10 only have an effect when Domino is acting as server (incoming mail).

Is there a way to drop all connections, no matter if incoming or outgoing, if the Protocol Version is lower than TLS 1.0?

 

Dave wrote:

from your log shows that you are configured to use TLS 1.2. When acting as a client and configured to use TLS 1.2, Domino will always offer the full TLS 1.2 cipher list. If the server selects a lower protocol version, it is their responsibility to select a cipher that works with the selected protocol version.  

This looks like a poorly configured recipient server. But the majority of problems were with gmx, gmail, yahoo and web.de. Has anyone else similar problems with these Domains?