On 1/25/2025 11:01 PM, Colin Paice wrote:
The client usually sends up a list of acceptable cipher specs, and the
server picks one. Perhaps you need to change the client to add more.
For example from my definitions
We are specifying many different ciphers and have tried Bronze, Silver,
Gold and Platinum settings in the Network Configuration Assistant (see
below for an example). We have observed that none of this matters.
TTLSCipherParms cipher2~AT-TLS__Platinum_with_TL
{
V3CipherSuites TLS_RSA_WITH_AES_256_GCM_SHA384
V3CipherSuites TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
V3CipherSuites TLS_RSA_WITH_AES_256_CBC_SHA256
V3CipherSuites TLS_RSA_WITH_AES_256_CBC_SHA
V3CipherSuites TLS_DHE_DSS_WITH_AES_256_CBC_SHA
V3CipherSuites TLS_DHE_RSA_WITH_AES_256_CBC_SHA
V3CipherSuites TLS_RSA_WITH_AES_128_GCM_SHA256
V3CipherSuites TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
V3CipherSuites TLS_RSA_WITH_AES_128_CBC_SHA256
V3CipherSuites TLS_RSA_WITH_AES_128_CBC_SHA
V3CipherSuites TLS_DHE_DSS_WITH_AES_128_CBC_SHA
V3CipherSuites TLS_DHE_RSA_WITH_AES_128_CBC_SHA
}
From the trace, it appears that what's happening is the encryption for
the *initial* handshake is failing. Once we get past the initial
handshake, then of course the list of ciphers will matter.
https://www.ibm.com/docs/en/zos/3.1.0?topic=support-key-shares
"One of the security improvements made in TLS V1.3 is that most of the
handshake is now encrypted. This is done by having the client and server
sides each specify a key share group list. When the client attempts a
TLS V1.3 handshake, it generates a public/private key pair for each
supported group and the generated public value or values are put into
the client's initial handshake message. The server selects a group in
common with the client's groups and then generates its own
public/private key pair for the selected group. The server takes its
private value and the client's public value to generate a shared secret,
which is used to generate keys for encrypting and decrypting handshake
messages. Likewise, the client generates the same shared secret with the
server's public value that is transmitted in the server's initial
handshake message."
The "key share group list" described above is being passed by z/OS as
the singular value "secp521r1". It would be great if we could figure out
how to make it send an actual list of group names that also includes
"secp256r1" (the only one supported by the RedHat 9 wsftp server), but
so far we haven't been able to figure out how to do that.
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/
--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
