Trying to make the SSLv3 and TLS protocols coexist

[martin_E]

I have a customer who wants to remove their vulnerability to (among other things) POODLE by getting rid of SSLv3 for communicating with external vendors via their PI system, by restricting traffic to using the TLS protocol.

Unfortunately, not all their External Partners can meet this requirement, so temporarily, they want to have SSLv3 traffic (where still necessary) over one port and TLS traffic over another. The plan is that there will also be fire wall rules restricting the IP addresses of  "legacy partners" to the SSLv3 port. Following the instructions in 510007 - Setting up SSL on Application Server ABAP, they have installed SAPCRYPTOLIB version 5.5 and have set up the following configuration in DEFAULT.PFL:

* outgoing connections
ssl/ciphersuites = 135:HIGH
*
* incoming connections - TLS only protocol 
icm/server_port_02 = PROT=HTTPS,PORT=443,SSLCONFIG=......... 
icm/ssl_config_02 = CIPHERS=135:HIGH:MEDIUM:+e3DES 
* 
* incoming connections - SSL protocol 
icm/server_port_01 = PROT=HTTPS,PORT=444,SSLCONFIG=......... 
icm/ssl_config_01 = CIPHERS=196:HIGH:MEDIUM:+e3DES 
*

So, what happens now is that f the External Partner attempts to initiate SSLv3 communications via port 443, then it fails. Yes, as currently setup, the External Partner can also initiate TLS communication over this port, but this is fine (for example, wireshark shows that the TLS protocol doesn't get downgraded to SSLv3).

The problem is that there is no way to control by port or customer whether outgoing connections are going to an SSLv3 or TLS only partner, so ssl/ciphersuites must allow for SSLv3 connections. This means that we can get a partner responding, over port 443, with the SSLv3 protocol without any error, thus allowing for an interception (ala POODLE).

Can we prevent SSLV3 traffic from succeeding over port 443, regardless of who initiates it ?

[mvoros · Accepted solution]

Hi,

I don't think that PI provides capabilities of setting allowed cipher suites per communication channel. Hence you can try to do this outside of SAP which brings additional complexity to your landscape. You could introduce a reverse proxy that would have hostnames like customer1.weakssl.local, customer2.weakssl.local for every customer that still needs SSLv3. This proxy would accept only TLS connection so you would be able to set ssl/client_ciphersuites to allow only strong suites. Your PI system would connect to partners with TLS or this reverse proxy only. The reverse proxy would drop TLS connection from PI and establish new connection SSLv3 between itself and customer. Hence PI would never use SSLv3 and the allowed SSLv3 outbound connections would be controlled by reverse proxy configuration.

PI ------------TLS----------------> Client that supports TLS

PI ------------TLS----->Reverse Proxy -----------SSLv3 ---------> Client that does not support TLS

Another disadvantage is that you will have to update PI config to connect via new reverse proxy instead of direct connection to customer's system.

Cheers

[martin_E · Accepted solution]

Nt sure what the effect of what I've just done will be, but here goes ...

I originally marked the previous response as Helpful several months ago. I dressed it up and passed it on to my client, and I've since found out that this is, essentially, the way they went.

So I unmarked it as helpful then marked it as correct

[former_member476865]

The example configuration given above is misleading and incorrect.  The profile parameters ssl/ciphersuites and ssl/client_ciphersuites DO NOT APPLY to outgoing communication from SAP AS Java.

The version of IAIK included with all previously shipped versions of SAP AS Java do not support TLSv1.2.  Recently, an update of IAIK has become available which does support TLSv1.2:

https://service.sap.com/sap/support/notes/2284059

If you want to modify the TLS properties for outgoing connections of SAP AS ABAP, please use the profile parameter "ssl/client_ciphersuites" and do *NOT* enable "BC" (backwards compatibility) for outgoing(!!) connections.  While it is true that an single profile parameter setting ssl/ciphersuites in a SAP Netweaver 6xx, 70x, 71x and 72x Kernel will also affect properties for outgoing connections (for the purpose of backwards compatibility), this does not apply to SAP Netweaver 74x, which ships with a default setting for ssl/client_ciphersuites, which must be explicitly overriden.

For actual recommendations for values of the profile parameters ssl/ciphersuites and ssl/client_ciphersuites, see section 7 of SAP Note 510007.

https://service.sap.com/sap/support/notes/510007

I don't know what SAP software (middleware) component folks are referring to when they talk of "PI" (and I'm not sure that all of those who use the (marketing) term "PI" have the necessary knowledge about what SAP middleware components it contains..).

There seems to exist a component called "SOAP Adapter", which seems to get used in PI and XI usage scenarios.  SOAP Adapter is implemented in Java (i.e. running on SAP AS Java), and when outgoing communication is performed through the Java-based SOAP Adapter, then SSL/TLS (if used) will be provided by the native-Java (OEM) toolkit IAIK within SAP AS Java. For this outgoing communication, the profile parameter settings ssl/ciphersuites and ssl/client_ciphersuites are entirely irrelevant.

-Martin