Skip to Content
Author's profile photo Peter Todorov

Hardening SSL/TLS Configuration by Usage of Secure Cipher Suites on AS Java 7.0x and 6.40

In my previous blog I have described how to protect SAP NetWeaver AS ABAP (all versions) and AS Java version 7.10 and newer. As we are operating also multiple systems with releases prior to 7.10, the following blog is due.

In this blog I will explain how to harden the cipher suite configuration of your AS Java (v. 7.0x  and older) and how to mitigate the BEAST attacks.

The major difference with regard to the SSL configuration between AS Java releases (7.10 onwards) is that they make use of the Internet Communication Manager (ICM) and prior versions use the Dispatcher process. The Dispatcher maintains connections to the clients and is responsible for handling also the SSL/TLS connections.


Prerequisite for implementing the suggested configuration is that you have already configured and run SSL/TLS on the application server.


As I already mentioned in my previous blog, hardening cipher suites and mitigating BEAST attacks should be balanced against the usability of the service. Hardening

ciphers implies that the server has to support only secure ciphers. If clients (e.g. client browsers) do not though support these ciphers enforced by the server, no encrypted communication can be established, therefore possibly leading to unhappy clients who cannot use the services provided. In this blog I am aiming for a solution which is both secure and client-friendly.

Cipher Suite Hardening:

My tool of choice to configure SSL/TLS ciphers of the application server is Visual Administrator. Run the tool and connect to the system you want to harden. In the navigation tree go to tab Cluster and navigate to Dispatcher -> Services -> SSL Provider. On the lower right you will find the tab Cipher Suite and the configured ciphers.


There are by default about 50 (depending on the release) cipher suites active and configured on the system. Our task would be to:

  • remove insecure ciphers
  • out of the reduced set of ciphers we will prioritize more secure ciphers higher than less secure ciphers (we leave less secure ciphers activated to ensure that clients can still connect to the system if they do not support the high security ciphers)
  • activate as many ciphers as possible which meet the requirements

After removing weak ciphers and ciphers with no encryption (_NULL_ ciphers) our choice is reduced to about 20. Now these have to be prioritized by their strength.

A cipher name is a set of algorithms used for ensuring secure message communication. Let’s dissect a cipher suite name and see what is behind it. For example SSL_RSA_WITH_RC4_128_MD5:

  • SSL –  protocol (alternatives are e.g. TLS)
  • RSA – key exchange / authentication (alternatives are e.g. PSK)
  • RC4_128 – message encryption cipher and key length (alternatives are e.g. CBC)
  • MD5 – message authentication/integrity (alternatives are e.g. SHA)

To mitigate BEAST attacks, RC4 ciphers should be preferred. Stronger encryption with longer keys should be preferred as well. For message authenticity SHA should be preferred as it is considered more secure than MD5. Having this in mind, I suggest the usage of the following ciphers in this particular order:






If the system should be absolutely BEAST-proof then you should leave only the 5 RC4 ciphers listed above. This could though lead to client issues, who cannot initiate SSL/TLS connections to the system. Therefore, I suggest additionally activating the following CBC ciphers:


















These configurations must be performed on all Dispatcher processes of the system individually. Finally restart the system and you are done!

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Abinash Nanda
      Abinash Nanda

      Nice blog with great explanation Peter!!!