Environment
Novell Access Manager 3.1 Linux Access Gateway
Novell Access Manager 3.1 Linux Novell Identity Server
Novell Access Manager 3.1 SSLVPN Server
Novell Access Manager 3.1 Access Administration
Novell Access Manager 3.1 Windows Novell Identity Server
Novell Access Manager 3.1 Access Gateway Service
Novell Access Manager 3.1 Linux Novell Identity Server
Novell Access Manager 3.1 SSLVPN Server
Novell Access Manager 3.1 Access Administration
Novell Access Manager 3.1 Windows Novell Identity Server
Novell Access Manager 3.1 Access Gateway Service
Situation
The TLS protocol, and the SSL protocol 3.0 and possibly earlier, as
used in mod_ssl in the Apache HTTP Server 2.2.14 and earlier,
OpenSSL before 0.9.8l, GnuTLS 2.8.5 and earlier, and many other
products, does not properly associate renegotiation handshakes with
an existing connection, which allows man-in-the-middle attackers to
insert data into HTTPS sessions, and possibly other types of
sessions protected by TLS or SSL, by sending an unauthenticated
request that is processed retroactively by a server in a
post-renegotiation context, related to a "plaintext injection"
attack, aka the "Project Mogul" issue.
Does Novell Access Manager have a fix for this issue?
Does Novell Access Manager have a fix for this issue?
Resolution
OpenSSL organization (www.openssl.org) fixed this issue
implementing the RFC 5746 starting
from the OpenSSL version 0.9.8m.
The Linux Access Gateway Appliance (LAG) version 3.1 SP3 IR2 (3.1.3-292) or earlier, ships with a SLES 9/SLES 11 OpenSSL version that does NOT support the RFC 5746 and is actually affected by the vulnerability described in the CVE-2009-3555.
The first LAG shipping with an OpenSSL version that fully supports RFC 5746 is the 3.1 SP4 (3.1.4-27).
The Linux Access Gateway Service, instead, does not ship with its own OpenSSL version, but relies on the one currently installed on the underlying OS.
In general, If the various NAM components (Identity Server, Administration Console, Access Gateway Service and SSLVPN server) are affected or not from the vulnerability described in the CVE-2009-3555, depends on the OpenSSL versions of the underlying operating system.
SUSE Linux Enterprise Server 11 Service Pack 1 ships with the following OpenSSL version:
openssl-0.9.8h-30.34.1
openssl-certs-0.9.8h-27.1.30
libopenssl0_9_8-0.9.8h-30.34.1
Even if the listed OpenSSL versions are earlier than 0.9.8m, the code extension to fix the vulnerability has been back ported, therefore the secure SSL renegotiation is fully supported as per RFC 5746. This means that every NAM component installed on top of SLES 11 SP1 will support RFC 5746.
Concerning the OpenSSL versions shipped with SLE11 code base, this is what has been done:
0.9.8h-30.15.1 was the first version where the SSL renegotiation was disabled, as a temporary workaround as the fix was not ready yet;
0.9.8h-30.22.21.1 was the first version where SSL renegotiation was re-enabled and made secure back- porting the fix from OpenSSL 0.9.8m that implements RFC 5746.
This means that every SLE based server that runs an OpenSSL version earlier than 0.9.8h-30.15.1 is actually vulnerable.
You can verify if IDS, AG and AC supports secure renegotiation using the following command from any Linux client:
openssl s_client -connect xxx.xxx.xxx.xxx:8443 (where xxx.xxx.xxx.xxx is the IP number of the NAM component you are connecting to)
In the received response you will note a line that ill clearly state "Secure Renegotiation IS supported" or "Secure Renegotiation IS NOT supported".
The Windows installer for the various Novell Access Manager (NAM) components includes, when needed, the OpenSSL libraries, and those are supporting RFC 5574 since NAM 3.1 SP3.
The Linux Access Gateway Appliance (LAG) version 3.1 SP3 IR2 (3.1.3-292) or earlier, ships with a SLES 9/SLES 11 OpenSSL version that does NOT support the RFC 5746 and is actually affected by the vulnerability described in the CVE-2009-3555.
The first LAG shipping with an OpenSSL version that fully supports RFC 5746 is the 3.1 SP4 (3.1.4-27).
The Linux Access Gateway Service, instead, does not ship with its own OpenSSL version, but relies on the one currently installed on the underlying OS.
In general, If the various NAM components (Identity Server, Administration Console, Access Gateway Service and SSLVPN server) are affected or not from the vulnerability described in the CVE-2009-3555, depends on the OpenSSL versions of the underlying operating system.
SUSE Linux Enterprise Server 11 Service Pack 1 ships with the following OpenSSL version:
openssl-0.9.8h-30.34.1
openssl-certs-0.9.8h-27.1.30
libopenssl0_9_8-0.9.8h-30.34.1
Even if the listed OpenSSL versions are earlier than 0.9.8m, the code extension to fix the vulnerability has been back ported, therefore the secure SSL renegotiation is fully supported as per RFC 5746. This means that every NAM component installed on top of SLES 11 SP1 will support RFC 5746.
Concerning the OpenSSL versions shipped with SLE11 code base, this is what has been done:
0.9.8h-30.15.1 was the first version where the SSL renegotiation was disabled, as a temporary workaround as the fix was not ready yet;
0.9.8h-30.22.21.1 was the first version where SSL renegotiation was re-enabled and made secure back- porting the fix from OpenSSL 0.9.8m that implements RFC 5746.
This means that every SLE based server that runs an OpenSSL version earlier than 0.9.8h-30.15.1 is actually vulnerable.
You can verify if IDS, AG and AC supports secure renegotiation using the following command from any Linux client:
openssl s_client -connect xxx.xxx.xxx.xxx:8443 (where xxx.xxx.xxx.xxx is the IP number of the NAM component you are connecting to)
In the received response you will note a line that ill clearly state "Secure Renegotiation IS supported" or "Secure Renegotiation IS NOT supported".
The Windows installer for the various Novell Access Manager (NAM) components includes, when needed, the OpenSSL libraries, and those are supporting RFC 5574 since NAM 3.1 SP3.