000029995 - AM 8.1 SP1 P2 How to Disable SSLv3 on Web Tier (Windows 2008R2)

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 4Show Document
  • View in full screen mode

Article Content

Article Number000029995
Applies ToRSA Product Set: SecurID
RSA Product/Service Type: Authentication Manager
RSA Version/Condition: 8.1.0 SP1 P2
Platform: VMware
Platform (Other): .
O/S Version: ESXi 5.0
Product Name: RSA-0010015
Product Description: RSA SecurID Appliance SW License
IssueCustomer wishes to Disable SSLv3 on Web Tier: I would like to know, how to disable SSLv3 on Web Tier Server for RSA Self Service Console. I see the RSA Web Tier allows the SSLv3 connections on Port 443. 
Note: RSA Engineering maintains that the communication between the AM 8.1 SP1 P2 Primary/Replica Servers (TCPport 7022) and the RSA Web Tier software installed on Windows Server or Red Hat Server (TCP port 7030) uses TLSv1 by default and therefore is not vulnerable to any currently known CVEs.
Since AM 8.1 SP1 P2, the RSA Authentication Manager Web Tier will use TLSv1 by default on its Web Tier Port 7030, but a scanning tool can force a reply of SSLv3.  For example, openssl with the -ssl3 switch requests that SSLV3 be used.
        openssl s_client -connect 192.168.2.153:7030 -ssl3

ssl3
RSA does not consider this a vulnerability, but this KB documents an unsupported way to disable SSLv3 responses on the Web Tier port TCP 7030
 
Tasks1. Disable SSLv3 on the Authentication Manager Web Tier side - this KB
TCP Port 7030 is the Web Tier port for the Web Tier Server (AM 8.1 SP1 P2 server uses TCP port 7022 for Web Tier). This solution also disabled SSLv3 on TCP port 443.  So you do not need to look into a Microsoft or RHEL solution to disable the Internet facing side
ResolutionEdit the WebtierServerWrapper.conf file;
In Windows Web Tier: Program Files\SA Security\RSA Authentication Manager Webtier\server\wrapper\
and find the highest wrapper.java.additional.nn Number e.g.
wrapper.java.additional.43=-Djavax.management.builder.initial=weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder
and add the following line after this highest wrapper.java.additional.nn
             wrapper.java.additional.44=-Dweblogic.security.SSL.protocolVersion=TLS1
conf
Save the file, restart Web Tier and Web Tier Wrapper services.
NotesTest with opernssl and -ssl3 switch
        openssl s_client -connect 192.168.2.153:7030 -ssl3

fail
Engineering Note: 

Thank you Jay -
Please keep track of any systems that are altered as these may be unsupportable in the future and changes could result in security and functional failures. You should be prepared to remove the changes before performing updates and other support operations.


The current server is functioning as designed. There is an RFE submitted for removing SSLv3 support for AM OA, auto-reg, etc - being considered for the next release from development (but no schedule or commitment).


SSLv3 is not insecure when used with non-CBC ciphers. Some point to POODLE as causing SSLv3 to be fully insecure but have not carefully read the announcement or description of POODLE:


From the announcement:


http://googleonlinesecurity.blogspot.co.uk/2014/10/this-poodle-bites-exploiting-ssl-30.html


Disabling SSL 3.0 support, or CBC-mode ciphers with SSL 3.0, is sufficient to mitigate this issue


And the paper describing POODLE:
https://www.openssl.org/~bodo/ssl-poodle.pdf


We show here how to put together an effective attack against CBC encryption as used by SSL3.0, again assuming that the attacker can modify network transmissions between the client and the server.


Why the researchers who reported this issue felt it necessary to misrepresent the issue is unknown (but it may be that they considered that identifying an attack on SSLv3 would bring them more fame than just another attack on CBC ciphers and so attempted to make it seem that the problem was more general that it actually was. The report also claimed that part of the problem was "DLE" Downgraded Legacy Encryption" and this was also rejected, leaving just a Padding Oracle attack (or POO)).

Attachments

    Outcomes