| Author |
Message
|
| JosephGramig |
 Posted: Fri Apr 30, 2021 6:46 am Post subject: TLS_RSA_WITH_AES_256_GCM_SHA384 data limit reached |
 |
|
Grand Master
Joined: 09 Feb 2006
Posts: 1237
Location: Gold Coast of Florida, USA
|
The following error was received:
AMQ9288E: Secure data transfer limit for channel exceeded.
EXPLANATION:
CipherSpec 'TLS_RSA_WITH_AES_256_GCM_SHA384' has reached a data transfer limit of 4294967295 (the transfer limit is expressed in terms of TLS records for GCM ciphers, or MB for all other ciphers). Session keys using this CipherSpec must be used only to encrypt a limited quantity of data to reduce the risk of key compromise.
The channel 'QMGR1.TO.QMGR2' terminated because it exceeded the allowed data transfer limit for its CipherSpec.
ACTION:
This error can be avoided in one of the following ways:
(a) Use secret key reset to ensure that the session key is reset before the data transfer limit is exceeded.
(b) Use a stronger CipherSpec which is not subject to a data transfer limit.
###
The MQ admin does not like that the secret key reset is for all channels on the Qmgr. They want it by channel. What are their options? Is there more to this story (like the key reset impacts only certain ciphers (I'm guessing here))? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Apr 30, 2021 4:10 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20729
Location: LI,NY
|
The key reset impacts specifically GCM ciphers and all other ciphers that need a key reset to continue working... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Sun May 02, 2021 2:33 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1948
Location: Bay of Plenty, New Zealand
|
Key reset affects all channels with a cipher spec.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| tczielke |
| Posted: Mon May 03, 2021 4:47 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
A few notes:
IBM recently lowered the TLS 1.2 GCM CipherSuite restriction from 2^32 TLS records sent to 2^24.5 TLS records sent.
https://www.ibm.com/docs/en/ibm-mq/9.1?topic=messages-enabling-cipherspecs
2 ^ 32 = 4,294,967,296, so it looks like the code that issued that error is running with the 2 ^ 32 check and is not stopping the channel at 2 ^ 24.5 TLS records, and is therefore, unsecure.
At TLS 1.3, the TLS protocol does the key resets implicitly for you for GCM, so there is no need to do manual key resets at the queue manager or client level.
If this queue manager uses clients that use the TLS 1.2 GCM CipherSuite, the clients have to be changed to do key resets, too.
I would follow the IBM advice and avoid using GCM CipherSuites at TLS 1.2, if possible.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Mon May 03, 2021 6:04 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1237
Location: Gold Coast of Florida, USA
|
| tczielke wrote: |
| I would follow the IBM advice and avoid using GCM CipherSuites at TLS 1.2, if possible. |
Hmmm, what IBM advice?
Where does IBM give that advice?
thx, Joseph |
|
| Back to top |
|
|
| tczielke |
| Posted: Mon May 03, 2021 6:25 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
It is here in that previous link:
| Quote: |
[Linux][Windows] Following a recommendation by GSKit, TLS 1.2 GCM CipherSpecs have a restriction which means that after 2ˆ24.5 TLS records are sent, using the same session key, the connection is terminated with message AMQ9288.
To prevent this error from happening: avoid using TLS 1.2 GCM Ciphers, enable secret key reset, or start your IBM MQ queue manager or client with the environment variable GSK_ENFORCE_GCM_RESTRICTION=GSK_FALSE set.
This restriction does not apply to IBM MQ for z/OS®. |
"avoid using TLS 1.2 GCM Ciphers"
If a security requirement here is to also use a TLS 1.2 CipherSuite that supports forward secrecy, ECDHE_RSA_AES_256_CBC_SHA384 would be a good alternative for the GCM CipherSuite that was being used.
One other note, I question the accuracy of this below statement, if z/OS is not doing implicit key resets in the TLS 1.2 protocol, which I don't believe they are doing.
| Quote: |
| This restriction does not apply to IBM MQ for z/OS®. |
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed May 05, 2021 5:25 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1237
Location: Gold Coast of Florida, USA
|
I'm wondering if the error message is really more like a warning message saying it is going to renegotiate the secret key?
I also wonder how many TLS records relate to how many bytes in the SSLRKEY(0) param (which is saying never reset by default).
Obviously, this only effects long running channels with lots of traffic. This is my case. Billion+ transactions needing low milli second latency. |
|
| Back to top |
|
|
| tczielke |
| Posted: Wed May 05, 2021 6:43 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
The original error is saying the channel will be stopped because it is about to go past 2^32 TLS records for a TLS 1.2 GCM CipherSuite. Please note that IBM lowered the recommendation to 2^24.5 TLS records for TLS 1.2 GCM CipherSuites, and this looks like older code that does not have the new check.
It is not easy to know how to set the SSLKEYR value, since it is in bytes and this GCM check is in TLS records. I think IBM provides some guidance on it though, especially if you ask them in a PMR.
I would say just don't use GCM at TLS 1.2, if at all possible. All of this goes away at TLS 1.3, as the protocol handles the key resets for you for GCM or any other CipherSuite that needs key resets to be secure.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| AMiguelTrindade |
| Posted: Tue Sep 12, 2023 1:43 am Post subject: setting SSLKEYR for JMS clients |
|
|
Newbie
Joined: 13 Jul 2018
Posts: 1
|
You can set the SSLKEYR value when using the JMSAdmin tool to create a JMS bindings file.
The option to use is SSLRESETCOUNT.
Usage:
DEF QCF(QCFNAME) [...] SSLRESETCOUNT(2147483648)
The value is in bytes, so in the above, the keys should be reset every 2GB of data exchanged. |
|
| Back to top |
|
|
|
|
