 |
| ||||||||
SAP Ariba and SAP Business Network are committed to protect security of the customers and their suppliers. SAP Ariba and SAP Business Network will be implementing some mandatory changes to ensure the use of stronger cryptographic algorithms, enhanced security mechanisms, and better protection against known vulnerabilities.
-
Removing weak TLS 1.2 ciphers is essential for enhancing SAP Ariba and SAP Business Network security. Weak ciphers can be exploited by attackers to decrypt sensitive data, perform man-in-the-middle attacks, or compromise the integrity of communications
-
In addition, TLS 1.3 eliminates outdated and vulnerable cryptographic algorithms and protocols, making it more secure against known attacks compared to previous versions.
What is going to change after January 24, 2025?
Starting January 24, 2025 SAP Ariba and SAP Business Network applications will remove weak TLS 1.2 ciphers and enable support for TLS 1.3 protocol along with TLS 1.2 strong ciphers.
The deployment of TLS changes will start from January 24, 2025, and will complete by April 30, 2025, across all SAP Ariba and Business Network data centers.
Hence you need to wait until April 30, 2025 until the TLS changes will reflect on all DCs.
Note: If you are planning to remove the TLS 1.2 protocol please refrain from doing it until April 30, 2025. As this is a phased approach and removing TLS 1.2 would lead to failures of integration.
Which ciphers suites are going to be deprecated? How to identify which ciphers to be removed?
Following TLS 1.2 cipher suites will be deprecated:
CBC based ciphers:
Any cipher which use CBC mode of encryption will not be supported, Few examples of CBC based ciphers:
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_RSA_WITH_AES_128_CBC_SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_DH_anon_WITH_AES_128_CBC_SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
RSA Key-exchange based ciphers
Any cipher which uses RSA as Key exchange algorithm will not be supported. Example of RSA key exchange-based ciphers:
TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
SHA-1 hash based cipher suites.
Any cipher which uses SHA/SHA-1 hashing will not be supported. Examples of SHA-1 based ciphers:
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
Why are Ariba and Business Network removing weak TLS 1.2 cipher suites?
Cipher Block Chaining (CBC) mode is a popular mode of operation for block ciphers. However, it is equipped with many vulnerabilities such as IV reuse attacks, Padding Oracle Attacks, Bit Flipping Attacks etc.
SHA-1 (Secure Hash Algorithm 1) has several well-documented vulnerabilities that make it less secure for cryptographic applications. Few examples of SHA or SHA-1 hashing algorithm include Collision Vulnerabilities, Length Extension Attacks etc.
TLS_RSA (Transport Layer Security using RSA for key exchange and authentication) has several vulnerabilities that can compromise the security of communications. Few examples, of TLS_RSA include Lack of Forward Secrecy, Vulnerability to Key Compromise, Timing Attacks etc.
Removing weak TLS 1.2 ciphers is essential for enhancing SAP Ariba applications and SAP Business Network applications security. Weak ciphers can be exploited by attackers to decrypt sensitive data, perform man-in-the-middle attacks, or compromise the integrity of communications.
Which TLS 1.2 ciphers should be used in place of weak ciphers?
In place of CBC mode ciphers, Use GCM (Galois/Counter Mode) or CCM (Counter with CBC-MAC) for authenticated encryption, which provides both confidentiality and integrity
Instead of SHA-1 ciphers, move to more secure alternatives like SHA-256 or SHA-3 for all cryptographic applications, especially those involving digital signatures, certificates, and integrity verification.
In place of TLS_RSA ciphers, Use Modern Key Exchange Protocols which support forward secrecy such as ECDHE or DHE (Diffie-Hellman Ephemeral).
Ariba and Business Network will support only the following TLS 1.2 ciphers suites which are considered strong as compared to the ones getting deprecated:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
Additionally, SAP Ariba and Business Network will be supporting only the following TLS 1.3 cipher suites:
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
Customers need to ensure that they support at least one of the above-mentioned cipher suites
Is this applicable to HTTP or HTTPS?
This is applicable to HTTPS, since HTTPS uses TLS protocol
Which additional cipher suites we need to support?
Please ensure they support following strong cipher suites (at least):
TLS 1.3 cipher:
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS 1.2 ciphers:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
Is there any way to for external partners/client systems (such as using API/Webservice/ITK and etc) to verify if they can be impacted?
Customers/Partners can use following test URLs to test their connection:
Test URL for TLS 1.2 protocol: Enabled with TLS1.2 ciphers only.
https://tls12-strong-cipher-check.xglab.ariba.com
If the client can establish a connection to the endpoint, the server will return the message “OK”. If the result is anything different to "OK" or a connection failure, then the customer/partner system must enable the strong TLS 1.2 ciphers mentioned to allow successful connection
Test URL for TLS 1.3 protocol: Enabled with TLS 1.3 ciphers only.
https://tls13-strong-cipher-check.xglab.ariba.com/
If the client can establish a connection to the endpoint, the server will return the message “OK”. If the result is anything different to "OK" or a connection failure, then the customer/partner system must enable the TLS 1.3 to allow successful connections
NOTE: These test URLs are intended solely for evaluating TLS protocol and cipher compatibility and should not be used for end-to-end testing
Is it possible for SAP to depreciate CBC ciphers in the Test tenant in advance e.g. to allow for impact testing?
Unfortunately, this is not possible because this change is being applied for the whole landscape and there is no option to restrict this only on a particular tenant.
My organization cannot support TLS 1.3 at the moment. Will there be any issues?
No, as long as you are supporting above mentioned Strong TLS 1.2 ciphers there should not be any issues. Currently Ariba does not plan to remove support for TLS 1.2. However, we recommend to test your changes using below test URL:
Test URL for TLS 1.2 protocol: Enabled with TLS1.2 ciphers only.
https://tls12-strong-cipher-check.xglab.ariba.com
NOTE: These test URLs are intended solely for evaluating TLS protocol and cipher compatibility and should not be used for end-to-end testing
My organization is planning to remove support for TLS 1.2 and support only TLS 1.3. Will there be any issues?
No, Ariba will support both TLS 1.3 and TLS 1.2 with strong cipher suites, hence there should not be any issues.
However, we recommend to test your changes using below test URL:
Test URL for TLS 1.3 protocol: Enabled with TLS 1.3 ciphers only.
https://tls13-strong-cipher-check.xglab.ariba.com/
NOTE: These test URLs are intended solely for evaluating TLS protocol and cipher compatibility and should not be used for end-to-end testing
How to add support for TLS 1.3 protocol?
The process/steps for updating the TLS protocol and ciphers varies for different tools and libraries.
Few examples are as follows:
For Browser: Upgrade to the latest browser or minimum following browser version which by default support TLS 1.3 and strong TLS 1.2 ciphers:
Google Chrome (88 or above)
Microsoft Edge (88 or above)
Mozilla Firefox (87 or above)
Apple Safari (15 or above)
Mobile Safari on iPad (15 or above)
For JAVA client:
TLS 1.3 will be enabled by default on the client for JDK 8. JDK 8 has included an implementation of the TLS 1.3 specification (RFC 8446) since (8u261). However, TLS 1.3 has not yet been enabled by default on the client.
To test this change, the TLS 1.3 protocol can be enabled on the client using the jdk.tls.client.protocols system property, for example:
java -Djdk.tls.client.protocols="TLSv1.3,TLSv1.2" ...
or by using the https.protocols system property if the application is using the HttpsURLConnection or URL.openStream() APIs, for example:
java -Dhttps.protocols="TLSv1.3,TLSv1.2"
For more details, please refer:
https://www.java.com/en/configure_crypto.html
https://www.java.com/en/jre-jdk-cryptoroadmap.html
How to add/remove TLS cipher suites?
The process/steps for updating the TLS protocol and ciphers varies for different tools and libraries.
Few examples are as follows:
For Browsers:
Ensure you are using latest version of browser which supports strong TLS 1.2 ciphers and TLS 1.3.
For JAVA client:
Please refer Configure Oracle's JDK and JRE Cryptographic Algorithms (java.com) on how to "Improve TLS cipher suite order"
How long suppliers will be able to access the below test urls provided in the TLS notice. Are these planned to be expired at some point?
The test URLs will be active till Q1 2025 (i.e. March 2025)
Test URL for TLS 1.2 protocol: Enabled with TLS1.2 ciphers only.
https://tls12-strong-cipher-check.xglab.ariba.com
Test URL for TLS 1.3 protocol: Enabled with TLS 1.3 ciphers only.
https://tls13-strong-cipher-check.xglab.ariba.com/
Zentrale Beschaffungsplattform > Basis-Framework