Consolidating security requirements mandate at a customer's the ciphers listed below:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
The above are being used on z/OS with IBM System SSL.
XCOM secure transfers initiated from Windows to z/OS LPARs show that an ECDHE cipher is being used i.e. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
However when secure transfers from XCOM for z/OS to XCOM for Windows are tested they do not use a cipher from the above approved list and a 3DES cipher TLS_RSA_WITH_3DES_EDE_CBC_SHA needs to be added for the transfer to be successful.
Currently testing XCOM for Windows r11.6 20035 SP03 (GA version of SP03). The default configssl.cnf file has only one change, RECEIVE_SIDE in RSAKEY = YES:
**********# Mandatory, note that CA-XCOM supports v3, tlsv1, tlsv1.1, tlsv1.2.
[SSL_OPTION]
INITIATE_SIDE = SSL_OP_ALL|SSL_OP_NO_SSLv2
RECEIVE_SIDE = SSL_OP_ALL|SSL_OP_NO_SSLv2|SSL_OP_SINGLE_DH_USE
# Mandatory
[VERIFY_DEPTH]
INITIATE_SIDE = 4
RECEIVE_SIDE = 4
# Mandatory, note that CA-XCOM supports v3, tlsv1, tlsv1.1, tlsv1.2.
# default "all"
[SSL_METHOD]
INITIATE_SIDE = all
RECEIVE_SIDE = all
# Optional
[CIPHER]
INITIATE_SIDE = ALL:!ADH:!LOW:!EXP:MD5:@STRENGTH
RECEIVE_SIDE = ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH
...
# Mandatory, YES/NO (if NO, DH will be used)
[RSAKEY]
RECEIVE_SIDE = YES
# Optional (for RSA NO, see above). If RSA NO and DH files empty,
# then internal program tables will be used.
[DH]
DH_512_RECEIVE_SIDE =
DH_1024_RECEIVE_SIDE =
DH_2048_RECEIVE_SIDE =
DH_4096_RECEIVE_SIDE =
**********
XCOM™ Data Transport® for Linux PC
XCOM™ Data Transport® for UNIX
XCOM™ Data Transport® for Windows
XCOM Engineering tests show XCOM Windows 11.6 20035 SP03 (GA) and later PTF levels (including 12.0) work as follows:
The above results are when using a configssl.cnf file as follows:
*****# Mandatory, YES/NO (if NO, DH will be used)
[RSAKEY]
RECEIVE_SIDE = NO
# Optional (for RSA NO, see above). If RSA NO and DH files empty,
# then internal program tables will be used.
[DH]
DH_512_RECEIVE_SIDE =
DH_1024_RECEIVE_SIDE = %XCOM_HOME%\\Config\\dh1024.pem
DH_2048_RECEIVE_SIDE =
DH_4096_RECEIVE_SIDE =
*****NOTE: Without setting DH_1024_RECEIVE_SIDE the default internal program table for DH 512 is used which causes a "
Cryptographic processing error" for a z/OS to Windows transfer.
So the cause of the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher being used is that the default configssl.cnf has been changed to enable RSA for key exchange instead of using DH (Diffie-Hellman) i.e. [RSAKEY] RECEIVE_SIDE = YES
After changing the configssl.cnf to use the same values as Engineering tested the required ciphers from the approved list were used i.e.
Windows to z/OS: Cipher TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 is used.
z/OS to Windows: Cipher TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 is used.
XCOM Windows PTF LU06617 11.6 SP3 22076 and later will make the above DH_1024_RECEIVE_SIDE change in configssl.cnf.
A manual change of the RECEIVE_SIDE RSAKEY to YES will require a manual change back to NO.
1.The z/OS transfer data can be used to locate IP addresses of Windows/distributed machines which are using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher so the change can be made there as well.
2. The XCOM for Windows 11.6 SP03 machines will be at various PTF levels and thus may already have the DH_1024_RECEIVE_SIDE change that was implemented in a PTF post 11.6 SP03 GA and is also in 12.0 GA.
Engineering advised as follows:
Patch LU08141 (XCOM Windows 11.6 22076 SP03) is the first fix to make a backup of configssl.cnf and to update DH1024 in that file. To make sure that the XCOM Windows version is at least at level 11.6 22076 SP03 will be the first task.
From the XCOM z/OS XCOMLOG, we know that all remote systems with cipher TLS_RSA_WITH_3DES_EDE_CBC_SHA have RSAKEY changed to YES. Before we change it to NO, we have to make sure that the DH1024 parameter is set.
A XCOM PING command from z/OS against those Windows IP addresses allows finding out if they are at 22076 or higher. If they are, it is enough to change the RSAKEY to NO.
The z/OS modify command against the STC xcom /f xcom,ping,10.2.3.4,8045,ssl
<=== Encrypted request /f xcom,ping,10.2.3.4,8044,ipv4
<=== Clear request
will give output similar to … RELEASE=r11.6 SP03 GEN LEVEL=22073
SYSTEM NAME= …
If they are not at level 22076 or higher, there is the choice of upgrading or setting the DH1024 parameter manually.
The OpenSSL versions in use, all the way back to XCOM Windows 11.6 SP2 base 17090, support TLSv1.2 with ciphers TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 or TLS_DHE_RSA_WITH_AES_256_GCM_SHA384.
Setting the DH1024 parameter manually is absolutely an option, if for some reason upgrading immediately is a problem.
ADDITIONAL NOTES:
1. ECDHE ciphers will not be used for a z/OS to Windows transfer because when receiving an SSL handshake the Windows side does not have a callback function for ECDHE implemented yet (a future enhancement is planned).
2. The documented supported ciphers doc. pages will also be reviewed and updated in due course.
11.6:
Cipher Suite Support
Cipher Suites for r11.6 SP01/ SP02/SP03
12.0:
Supported Cipher Suites
3. Corresponding OpenSSL cipher suite names for TLS cipher suite names can be found here: OpenSSL Documentation
e.g.
TLS Cipher Suite Name OpenSSL Cipher Suite Name
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 -> ECDHE-ECDSA-AES128-GCM-SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 -> ECDHE-RSA-AES128-GCM-SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 -> ECDHE-ECDSA-AES256-GCM-SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 -> ECDHE-RSA-AES256-GCM-SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 -> DHE-RSA-AES128-GCM-SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 -> DHE-RSA-AES256-GCM-SHA384