Trying to make the SSLv3 and TLS protocols coexist

Question

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 ?

Answer 1

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