Howto disable SSL 3.0 to mitigate vulnerabilities caused by Poodle attack on that Protocol

A recent report outlines how one can exploit SSL v3 code to gain access to sensitive information such as HTTP session cookies or application data. The link at https://www.openssl.org/~bodo/ssl-poodle.pdf gives more details on this so called Poodle attack.

The following TID outlines the configuration settings on the Admin Console, Identity Server and Access Gateways that will allow an administrator disable the SSL v3 protocol and mitigate this client based attack. Most browsers (next release of Firefox will disable SSL v3) use TLS protocols by default but support SSL v3.0 too.

a) Admin Console - modify /opt/novell/nam/adminconsole/conf/server.xml and make sure that the connector on TCP 8443 (or 2443 if Identity Server and Admin Console share the same host) sets the SSLProtocol to TLS as shown below:

    <Connector NIDP_Name="connector" port="2443" maxHttpHeaderSize="8192" maxThreads="200" minSpareThreads="5" enableLookups="false" disableUploadTimeout="true" acceptCount="0" scheme=
"https" secure="true" clientAuth="false" sslProtocol="tlsv1.2" sslEnabledProtocols="SSLv2Hello,TLSv1,TLSv1.1,TLSv1.2" URIEncoding="UTF-8" allowUnsafeLegacyRenegotiation="false" keystoreFile="/var/opt/novell/novlwww/.keystore" keystorePass="cha
ngeit" SSLEnabled="true" address="147.2.16.135" ciphers="SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS
_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA" />
  </Service>

The sslProtocol parameter defines the SSL protocol(s) to use (a single value may enable multiple protocols - see the JVM documentation for details). If not specified, the default is TLS.

b) Identity Server: As with the Admin Console setup above, modify /opt/novell/nam/idp/conf/server.xml and make sure that the connector on TCP 8443 or 443 sets the SSLProtocol to TLS as shown below:

    <Connector NIDP_Name="connector" SSLEnabled="true" URIEncoding="utf-8" acceptCount="100" address="147.2.16.135" ciphers="SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA
_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_C
BC_SHA, TLS_KRB5_WITH_3DES_EDE_CBC_SHA, TLS_KRB5_WITH_RC4_128_SHA" clientAuth="false" disableUploadTimeout="true" enableLookups="false" keystoreFile="/opt/novell/devman/jcc/certs/idp/c
onnector.keystore" keystorePass="D5c5jX45O1hg2lc" maxThreads="600" minSpareThreads="5" port="8443" scheme="https" secure="true" sslImplementationName="com.novell.nidp.common.util.net.s
erver.NIDPSSLImplementation" sslProtocol="TLSv1.2" sslEnabledProtocols="SSLv2Hello,TLSv1,TLSv1.1,TLSv1.2" />

In the unusual case where SAML introductions are enabled on the Identity Server or Provider, a connector for TCP port 8445 or 8446 will also show up in the server.xml file. To mitigate the SSL 3.0 vulnerability on these Introduction related connectors, the same change as that for the NIDP connector above will also be required so that SSL 3.0 is disabled as a protocol.

c) Access Gateway: To disable SSL v3.0 on the Access Gateway, manually add the following Advanced Options to the Global list of advanced options (Edit -> AG -> Advanced Options)

SSLProtocol All -SSLv2 -SSLv3
SSLProxyProtocol All -SSLv2 -SSLv3


See http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslprotocol and http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslproxyprotocol for more details on the available options.

Note that some very old browsers and apps may be effected by this if they do not support TLS. It is possible to turn SSL v3 on per proxy service with the local Advanced Options too, should the need arise.


Note that an admin can use many commands to verify whether SSL v3.0 is supported on the wire. Here's an example of  the openssl command available on SLES that can be used to check:

// Case 1: Response from SSL enabled host that has SSL v3.0 disabled

root@nam32phys:~> openssl s_client -connect 147.2.16.135:8443 -ssl3
CONNECTED(00000003)
2104:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:284:
root@nam32phys:~>

// Case 2: Response from SSL enabled host that has SSL v3.0 still enabled

root@ncashell2:~> openssl s_client -connect 147.2.16.135:8443 -ssl3
CONNECTED(00000003)
depth=1 /OU=Organizational CA/O=nam32phys_tree
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/CN=*.lab.novell.com
   i:/OU=Organizational CA/O=nam32phys_tree
 1 s:/OU=Organizational CA/O=nam32phys_tree
   i:/OU=Organizational CA/O=nam32phys_tree
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEjTCCA3WgAwIBAgIkAhwR/6Up6sAKUPG0u1GPDCmnNZvTNqCqJh/7oG0EAgIW
:
-----END CERTIFICATE-----
subject=/CN=*.lab.novell.com
issuer=/OU=Organizational CA/O=nam32phys_tree
---
No client certificate CA names sent
---
SSL handshake has read 3119 bytes and written 283 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3 ***************************** ENABLED
    Cipher    : EDH-RSA-DES-CBC3-SHA
    Session-ID: 543E3579EAD0CCD1B12BB8C56E5E94C6C02CD5F2014C0566A56E2F4CF473F83F
    Session-ID-ctx:
    Master-Key: 10229CD443736D9A363380346AEBB97FA00E795094D66D7F435DAD6D2FB3DD05AD982C01E141FF3CEE56DECEE20882B3
    Key-Arg   : None
    Start Time: 1413363065
    Timeout   : 7200 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)

Note that the AC/IDP connector changes reference SSLv2 (sslEnabledProtocols="SSLv2Hello,TLSv1,TLSv1.1,TLSv1.2"). The reason for this is that several older but still prevalent versions of IE browser (version 8, 9 and 10) have SSLv2, SSLv3, and TLSv1 protocols checked by default (TLSv1.1 + TLSv1.2 are present but not enabled by default). With this setting, the the client will always begin the handshake with an SSLv2 Client Hello. WIthout the SSLv2Hello, NAM Tomcat instances on AC/IDP will reply with the fatal Alert: Handshake Failure.

The SSLv2Hello does not turn on server-side support for the entire SSLv2 protocol -- just the Client Hello, which allows the server to transition the rest of the handshake up to the strongest protocol level supported by both. Even if the client indicates that SSLv2 is still the best protocol it supports (if you uncheck everything else), the server will stop with the desired fatal
alert for Handshake Failure.

Access Manager 3.1 LAG cannot be modified to disable SSL v3.0. Only solution is to upgrade to 3.2 or 4.0 versions of Access Manager.