Axway TSIM incoming TLS connection errors - Revision history

Admin at 12:07, 13 November 2024

2024-11-13T12:07:53Z

Admin at 12:41, 11 November 2024

2024-11-11T12:41:35Z

Admin at 13:47, 28 October 2024

2024-10-28T13:47:54Z

Admin: /* Summary */

2024-10-28T13:42:37Z

Summary

Admin: Admin moved page Axway TSIM incoming connection errors to Axway TSIM incoming TLS connection errors without leaving a redirect

2024-10-28T13:32:54Z

Admin moved page Axway TSIM incoming connection errors to Axway TSIM incoming TLS connection errors without leaving a redirect

Admin: Created page with "= Summary = Incoming OFTP2 TLS connections from an Axway TSIM system are not successful. OS4X logs this in several ways, such as "Unsuccessful connect try from IP ..." and oth..."

2024-10-28T13:12:24Z

Created page with "= Summary = Incoming OFTP2 TLS connections from an Axway TSIM system are not successful. OS4X logs this in several ways, such as "Unsuccessful connect try from IP ..." and oth..."

New page

= Summary =
Incoming OFTP2 TLS connections from an Axway TSIM system are not successful. OS4X logs this in several ways, such as "Unsuccessful connect try from IP ..." and others. O)utgoiung connections from OS4X to affected partners work fine.

= Technical background =
Incoming TLS connections are verified very securely before any OFTP2 communication takes place. These checks are:
#Is the TLS client certificate valid (trusted, within validity timeframe, trusted and supports all required features)?
#Is the TLS cipher secure?
#Is the used TLS cipher able to fulfill [[OS4X_Core_configuration#Enable_only_PFS_ciphers.3F|optional requirement]]s regarding Perfect Forward Secrecy (PFS)?
#In case of a used OFTP2 SmartProxy: check if the SSID contained in the client certificate is known to exactly one partner?

In the case of the Axway TSIM situation, option 2) fails. The OS4X daemon (plain or SmartProxy) offer an ordered list of [[OS4X_Core_configuration#TLS_ciphers.3F|usable TLS ciphers]] for every supported TLS version, [[OS4X_Core_configuration#Enable_only_PFS_ciphers.3F|optionally limited]] to only offer PFS ciphers (known to contain the text "DHE" in the cipher name). As TLS is specified, the client picks the best possible cipher from the top of the list which is supports. In most cases, it is a DHE ("Diffie-Hellman key exchange") affected cipher, which is technically good. The cryptographic library OS4X is using forces to handshake a new session key via a secure mechanism. This mechanism requires the used Diffie-Hellman key to be as big as the RSA private/public key of the OS4X TLS server certificate (which is 4096 as of time writing this document).

Axway TSIM is often running in JRE (Java Runtime Environment) version 8 which fails to support Diffie-Hellman keys of 4096 and requests to use 1024 bits instead. The TLS handshake then fails due to this inability to support a strong and secure Diffie-Hellman key size.

= Solution =
The best solution would be to use a modern Java Runtime Environment which supports modern TLS ciphers and most actual security requirements. Often this is not possible due to impacts unknown to data exchange partners.

= Workaround =
Axway TSIM and JRE8 customers can change the list of used TLS ciphers. When they prefer a non-DHE cipher first, the TLS connection can finish the handshake with a less secure cipher. For this, OS4X must not request a PFS cipher in the TLS listener (see [[OS4X_Core_configuration#Enable_only_PFS_ciphers.3F|this configuration option]]). The values for outgoing TLS ciphers in Axway TSIM then must be:
*TLS_RSA_WITH_AES_256_CBC_SHA
*TLS_RSA_WITH_AES_128_CBC_SHA

'''Beware: the session can be recorded by any party which is able to intercept network traffic and afterwards decrypt the content! So you are highly encouraged to keep security requirements high!'''

= External ressources =
Java has a very good documentation about their release dates: https://www.oracle.com/de/java/technologies/java-se-support-roadmap.html

For Java 8, the mechanism of how Diffie-Hellman keys are supported, the following documentation is available (which shows the mess of the support if the required value "<code>matched</code>" for this configuration is used): https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#customizing_dh_keys

[[Category:Best practice]]

@@ Line 28: / Line 28: @@
 For Java 8, the mechanism of how Diffie-Hellman keys are supported, the following documentation is available (which shows the mess of the support if the required value "<code>matched</code>" for this configuration is used): https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#customizing_dh_keys
+= Meme context =
 [[Category:Best practice]]

@@ Line 4: / Line 4: @@
 = Technical background =
 Incoming TLS connections are verified very securely before any OFTP2 communication takes place. These checks are:
-#Is the TLS client certificate valid (trusted, within validity timeframe, trusted and supports all required features)?
+#Is the TLS client certificate valid (trusted, within validity timeframe and supports all required features)?
 #Is the TLS cipher secure?
 #Is the used TLS cipher able to fulfill [[OS4X_Core_configuration#Enable_only_PFS_ciphers.3F|optional requirement]]s regarding Perfect Forward Secrecy (PFS)?

@@ Line 14: / Line 14: @@
 = Solution =
-The best solution would be to use a modern Java Runtime Environment which supports modern TLS ciphers and most actual security requirements. Often this is not possible due to impacts unknown to data exchange partners.
+The best solution would be to use a modern Java Runtime Environment which supports modern TLS ciphers and most recent security requirements. Often this is not possible due to impacts unknown to data exchange partners.
 = Workaround =
@@ Line 23: / Line 23: @@
 '''Beware: the session can be recorded by any party which is able to intercept network traffic and afterwards decrypt the content! So you are highly encouraged to keep security requirements high!'''
-= External ressources =
+= External resources =
 Java has a very good documentation about their release dates: https://www.oracle.com/de/java/technologies/java-se-support-roadmap.html

@@ Line 1: / Line 1: @@
 = Summary =
-Incoming OFTP2 TLS connections from an Axway TSIM system are not successful. OS4X logs this in several ways, such as "Unsuccessful connect try from IP ..." and others. O)utgoiung connections from OS4X to affected partners work fine.
+Incoming OFTP2 TLS connections from an Axway TSIM system are not successful. OS4X logs this in several ways, such as "Unsuccessful connect try from IP ..." and others. Outgoing connections from OS4X to affected partners work fine.
 = Technical background =

← Older revision	Revision as of 13:32, 28 October 2024
(No difference)