For V7R3, anyone willing to share their QSSLCSL Secure sockets layer cipher specification list.
Below is my current list, which I will be updating.
Weak ciphers, sequences 100 thru 220 are considered weak by multiple sources (except IBM) and are being removed.
Sequence 100 is the only weak cipher that is currently being used, all other weak ciphers not used, based on SST SSLCONFIG CONNECTIONCOUNTS.
The end result is a very small cipher list, which concerns me a bit.
Sequence Cipher
number Suite
0
10 *AES_128_GCM_SHA256 TLSv1.3
20 *AES_256_GCM_SHA384 TLSv1.3
30 *CHACHA20_POLY1305_SHA256 TLSv1.3
40 *ECDHE_ECDSA_AES_128_GCM_SHA256 TLSv1.2
50 *ECDHE_ECDSA_AES_256_GCM_SHA384 TLSv1.2
60 *ECDHE_RSA_AES_128_GCM_SHA256 TLSv1.2
70 *ECDHE_RSA_AES_256_GCM_SHA384 TLSv1.2
80 *ECDHE_ECDSA_CHACHA20_POLY1305_SHA256 TLSv1.2
90 *ECDHE_RSA_CHACHA20_POLY1305_SHA256 TLSv1.2
100 *RSA_AES_128_GCM_SHA256 TLSv1.2 weak
110 *RSA_AES_256_GCM_SHA384 TLSv1.2 weak
120 *ECDHE_ECDSA_AES_128_CBC_SHA256 TLSv1.2 weak
130 *ECDHE_ECDSA_AES_256_CBC_SHA384 TLSv1.2 weak
140 *ECDHE_RSA_AES_128_CBC_SHA256 TLSv1.2 weak
150 *ECDHE_RSA_AES_256_CBC_SHA384 TLSv1.2 weak
160 *RSA_AES_128_CBC_SHA256 TLSv1.2 weak
170 *RSA_AES_128_CBC_SHA TLSv1.2 weak
180 *RSA_AES_256_CBC_SHA256 TLSv1.2 weak
190 *RSA_AES_256_CBC_SHA TLSv1.1 weak
200 *ECDHE_ECDSA_3DES_EDE_CBC_SHA TLSv1.1 weak
210 *ECDHE_RSA_3DES_EDE_CBC_SHA TLSv1.1 weak
220 *RSA_3DES_EDE_CBC_SHA TLSv1.1 weak
Joe Sizer
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Scott Klement
Sent: Thursday, January 27, 2022 7:02 PM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Subject: Re: SSL connection issues, cipher questions
This is a difficult question to answer, because things aren't as simple as "secure" or "not secure". Instead, there's a wide spectrum of varying degrees of ease of cracking the cryptography.
To put it another way: It's not all black or white, there are many shades of gray in between.
My opinion: This cipher uses an RSA non-ephemeral key exchange, and has a 128-bit key. 128-bit key is relatively weak by today's standards, and once broken the entire conversation will be completely visible to the attacker. I would not call this secure by today's standards.
By contrast, if you used a Diffie-Hellman ephemeral (DHE) key exchange, and the key is compromised, they'll only be able to see a part of the conversation because the key will change periodically. So this is more secure. Even better would be to use a 256 bit key.
But, it really depends on how big of a risk you're willing to take, how crucial your data is, etc.
I wonder why you don't just use a stronger cipher and be done with it?
On 1/27/2022 1:56 PM, Steinmetz, Paul via MIDRANGE-L wrote:
IBM is stating that TLS 1.2 cipher RSA_AES_128_GCM_SHA256 is safe and secure, can be used.
According to site ciphersuite.info it is weak, should be removed.
https://ciphersuite.info/search/?q=RSA_AES_128_GCM_SHA256
One of our main apps uses this cipher.
Our IT folks are asking I remove it, IBM states its ok.
How does one deal with conflicting statements regarding ciphers?
Paul
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
