Daniel Nashed's Blog

Domino 9.0.1 FP5 IF1 with Security Fixes

There is a new IF1 for Domino 9.0.1 that includes two fixes we have waited for in the TLS area specially when communicating with STARTTLS and web-services as posted before on my blog.
       

SPR #KLYHA57S37 - Disable TLS Session Resumption on outbound connections by default        

This fix addresses and issue for outgoing STARTLS sessions on SMTP.

See some more details in my other blog post -->  http://blog.nashcom.de/nashcomblog.nsf/dx/tls-1.2-connection-issues-with-protection.outlook.com.htm

SPR #MKENA4SQ7R - Domino TLS 1.2 Client Hello does not offer a Signature Algorithm extension causing some handshakes to fail        

The second issue is a problem with a missing security algorithm extension that causes connection issues which happened in many customer environments -- and it looks like this happened depending on the certificate used in some cases.
And also what the remote server supported. The fix implements the missing extensions and improves compatibility.


SPR #KLYHA5YRVP - Recommended security fix for IBM Domino (technote 1974958)        

The Domino SLOTH vulnerability is about collision attack with the MD5 hash function that is used in the TLS handshake.
The fix addresses this issue.

Here are the main details from the TN describing the SPR.

CVEID: CVE-2015-7575
DESCRIPTION: The TLS protocol could allow weaker than expected security caused by a collision attack when using the MD5 hash function for signing a ServerKeyExchange message during a TLS handshake. An attacker could exploit this vulnerability using man-in-the-middle techniques to impersonate a TLS server and obtain credentials.

See more details here -> http://www.ibm.com/support/docview.wss?uid=swg21974958



SPR #DKENA32JMP - Add support for Extended Master Secret (RFC 7627) to TLS 1.2        

This is a quite new RFC which has been implemented by Microsoft and Google for their browsers recently. Both sides need to support this extension!
Domino does now support this extension which eliminates a risk of a man-in- the-middle attack in some situations described in the RFC below.


The Transport Layer Security (TLS) master secret is not
cryptographically bound to important session parameters such as the
server certificate.  Consequently, it is possible for an active
attacker to set up two sessions, one with a client and another with a
server, such that the master secrets on the two sessions are the
same.  Thereafter, any mechanism that relies on the master secret for
authentication, including session resumption, becomes vulnerable to a
man-in-the-middle attack, where the attacker can simply forward
messages back and forth between the client and server.  This
specification defines a TLS extension that contextually binds the
master secret to a log of the full handshake that computes it, thus
preventing such attacks.

https://www.ietf.org/mail-archive/web/ietf-announce/current/msg14570.html

• Comments [4]