Skip to content
TLS 1.3 for SAP

Are you getting started with TLS 1.3 for SAP?

ebde76d0d55c1a42c8ff2d0159c52217?s=96&d=mm&r=g
Gert-Jan Koster
SAP Security specialist
July 25, 2024
10 min read
Chapters

Share Article

Anyone involved in connectivity hardening for SAP landscapes has likely wondered if it is possible to use the latest Transport Layer Security (TLS) protocol 1.3 for HTTPS connections. For the main technology stacks, the general answer to that question has been a simple “no” for a long time. TLS 1.2 was the highest available version. However, that situation is shifting because, with recent releases of the SAP Kernel and CommonCryptoLib, there is support for TLS 1.3. In this article, we explore this further and make some suggestions for implementation. Let’s dive in! 

TLS 1.3 – Why bother?

For many people and IT users, HTTPS is nothing more than putting an ‘s’ behind ‘http’ in the URL of their browser. And so it should be. But for IT and security experts, there is a lot more to it than that. Before an HTTPS connection is established successfully, there is a complex exchange of encryption logic happening to get it working. We won’t try to go into detail here but stick to the protocol used for encryption of this client-server communication: Transport Layer Security (TLS). This protocol comes in different versions and in terms of security, we can roughly summarize it as follows: 

 

  • Secure Socket Layer (SSL): the predecessor of TLS and should no longer be used. Its abbreviation (‘ssl’) is still used a lot though, as we will also see in this article.  
  • Transport Layer Security (TLS): the successor of SSL and comes in versions 1.0, 1.1, 1.2, and 1.3. Many security authorities consider version 1.2 the minimum version for secure connectivity. 

 

TLS 1.2 was published in 2008, while version 1.3 came 10 years later in 2018. It is not uncommon for new standards to take years to take hold, and with TLS this is no different. But gradually, over the past years, there have been many initiatives by software vendors and service providers to phase out TLS versions below 1.2.  Similarly, we see many initiatives today to extend support for TLS to include 1.3 besides 1.2. Why is that? Not because TLS 1.2 is considered a risk. A proper TLS 1.2 configuration is by no means seen as ‘insecure’. But by adding support for TLS 1.3, the ‘security bar’ is raised yet again and, at the same time, configurations are better prepared for future requirements.  

Supported, but hold on…

So, let’s zoom in on TLS 1.3 in an SAP landscape. First, it is always important to realize that SAP landscapes are complex, heterogeneous collections of several components, technology stacks, etc. Especially nowadays, with added cloud components and services. As such, we often cannot speak in general terms and the same goes for TLS encryption. Depending on the SAP component and type of connectivity, different libraries are used in SAP landscapes. In this article though, we focus on HTTPS encryption that uses the so-called CommonCryptoLib. This library is owned and developed by SAP and is used to facilitate encryption for TLS and other protocols. Why focus on this type in particular? The reason is that this library is used by the main technology stacks in an SAP landscape (like NetWeaver ABAP/Java, S/4 HANA, and others).  

 

As said, CommonCryptoLib supports TLS 1.3 now. It is first mentioned with version 8.5.48, dating back to March 2023. But that does not mean you can flip a switch and start using it. There are some points to consider: 

 

  • For ABAP and Java-based systems, kernel 7.93 is a prerequisite (for Java, only inbound traffic is relevant here). The result is that only S/4 HANA 2023 can be configured with TLS 1.3 so far.  
  • When the downward compatible (DCK) version of kernel 7.93 is officially released, lower S/4 HANA versions can also be configured with TLS 1.3. This is a very recent development though (at this time of writing). 
  • Currently, NetWeaver ABAP or Java systems cannot be configured to use TLS 1.3 – at all. 
  • Other components like Web Dispatcher and SAP Content server can also use TLS 1.3 by using CommonCryptoLib. 

 

As we can see, there is support for TLS 1.3 but with a few restrictions. And the actual usage of TLS 1.3 using CommonCryptoLib ‘in the field’ is probably quite limited as well. Especially since TLS 1.3 is not automatically enabled even if the required software is there. 

 

So, with the current support status, should you consider implementing TLS 1.3? The sensible answer is probably: it depends. If you want to rule out any kind of instability on your core SAP systems, it is no problem to wait it out for a while and use a solid TLS 1.2 configuration. And if you’re still supporting older TLS versions than 1.2, there is more merit in phasing those out than going for TLS 1.3. On the other hand, if you’re already running a TLS 1.2-only environment and you want to raise the bar further (see “why bother”) you could start extending to TLS 1.3.  

Implementation guidelines

Below, we provide some suggestions for implementing/hardening TLS configurations in an SAP landscape. 

 

  1. Implement TLS logging 

It is highly recommended to implement logging so that you get insight into the TLS settings that are really used in your landscape. Implement it for both client and server connections and make sure it logs the TLS protocol, cipher suites, and the source/target IP addresses of the service involved. This will greatly assist in making informed decisions for target configurations and identifying problem areas. This is relevant for any TLS version, not just for implementing TLS 1.3, see next point. 

 

    2. Analyze and plan further actions 

Analyze the logging and determine what connections (do not) comply with your security standards. Like the TLS version and a certain set of cipher suites. As said, there is a consensus that TLS should be version 1.2. In a perfect world, all connections are compliant, and your logging shows you that. In reality, configurations very often allow fallback to insecure configurations. Don’t be surprised to find a lot of such connectivity coming from legacy systems, unpatched components, or simply poorly configured setups. You wouldn’t be the first… 

 

Next, categorize to identify connections that are related to (critical) business processes, interfaces, end-user communities, etc. This will help you focus on what parties you need to contact for non-compliant connections or proactive measures. Expect some discussion and lead time, especially if this concerns external organizations or departments. For example: if you have a critical interface that happens to use TLS 1.1 somewhere along the line, you probably don’t want this to break down because you implement a configuration that no longer allows the connection. When the relevant component is hosted by an external supplier, they may have different security standards or other obstacles to align with the standard you intend to implement.  

For other connection categories, you may not be able to take proactive measures at all. In that case, clear communication is key. 

 

   3. Apply updates using the common tiers 

Depending on the analysis, you may decide to first focus on non-compliant connections, implement a new standard (like TLS 1.3), or combine these actions. Regardless of the exact plan, implement changes with clear communication using the common tiers up to your production systems. Keep in mind that not all connections in production may have a counterpart in non-production layers. And keep analyzing the logs!  

Example: Web Dispatcher with TLS 1.3

As explained above, TLS 1.3 support on SAP is very recent, which may raise concerns about its implementation. Additionally, not all systems can be configured for TLS 1.3, even if you want to implement it. A possible solution here is to deploy a Web Dispatcher with TLS 1.3 first, without making changes to the backend systems. This allows you to start with TLS 1.3 for inbound connections regardless of the backend, and a Web Dispatcher is much easier in terms of applying or reverting changes.  

 

We’ll show this in a basic example setup where we configure a Web Dispatcher and an SAP NetWeaver ABAP 7.52 system: 

 

Web Dispatcher and an SAP NetWeaver ABAP 7.52 system setup

 

We use the latest SAP Web Dispatcher (7.93 111) and CommonCryptoLib (8.5.56) currently available for enabling TLS 1.3. 

 

  1. Implement TLS logging 

With the latest web dispatcher version, logging is already activated to log used TLS versions. This does not log the cipher suites – for this, you would need to adjust the configuration (See SAP note 2379540). However, let’s focus on the TLS version now and use these default settings. Note that these are controlled by system parameters ‘icm/HTTP/logging’ and ‘icm/HTTP/logging_client’.  

 

In our setup, we trigger several HTTPS requests to the Web Dispatcher admin page and the ABAP backend system using different TLS versions. This results in logging like this: 

 

logging version e1721912110294

 

Note that several items are logged. Like date/time stamp (not shown for readability), HTTP response code, source, and target IP addresses. And the TLS version, of course.  

 

     2. Analyze and plan further actions 

The logged connections show connectivity with TLS versions below 1.2. We use service /sap/public/ping here on the backend system but that’s only for demonstration. The actual service that is called, combined with the IP address info should give a further indication of the business process concerned. With this information, you can plan further (proactive) actions.  

 

    3. Apply updates 

In our test setup, we have kept settings at default. Interestingly, this shows that even the most recent Web Dispatcher supports TLS version 1.0-1.2. A clear example of how default settings need adjustment to be secure! 

 

Let’s assume we want to move to a configuration that supports only TLS 1.2 and 1.3. For this, we need to change parameter ‘ssl/ciphersuites’ accordingly. Following SAP note 3318423, we change the value as follows:

 

From: 135:PFS:HIGH::EC_X25519:EC_P256:EC_HIGH 

To: 1569:PFS:HIGH::EC_X25519:EC_P256:EC_HIGH 

 

After restarting the Web Dispatcher, only connections that use TLS 1.2 AND 1.3 can be made. The earlier identified connections (in ‘red’) will fail when trying to connect and are not shown in the log data. The logging now looks something like this:

 

logging version 2 e1721912175919

 

Again, this can be further analyzed. For example: to show the usage of TLS 1.3 compared to 1.2. Additionally, logging can be adjusted to log cipher suite information so that a more fine-grained adjustment can be planned.  

Conclusion

In this article, we briefly discussed TLS 1.3 for main SAP technology stacks and gave guidelines with a practical example. Find below an overview of referred sources: 

 

SAP notes: 

  • 3318423 – Is TLS 1.3 Supported by SAP Kernel for Netweaver AS ABAP and S/4HANA? 
  • 2834475 – Does SAP NetWeaver AS Java support TLS 1.3? 
  • 3405657 – What version of Content Server is available for TLS 1.3? 
  • 1848999 – Central Note for CommonCryptoLib 8 (SAPCRYPTOLIB) 
  • 2379540 – User-defined HTTP logging with TLS information 
  • 3457117 – Using Kernel 7.93 instead of Kernel 7.81, 7.85 or 7.89 

 

The SecurityBridge platform offers various controls to check several components for configuration, parameterization, and much more. This includes TLS settings for ABAP, Java, and Web Dispatcher systems that rely on CommonCryptoLib configurations. These can be checked against various security recommendations.  

 

Try SecurityBridge and immediately improve the security of your SAP systems! For more SAP security-related news, articles, and whitepapers, please follow us on LinkedIn.