Skip to Main Content
Integration


This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.


Status Delivered
Created by Guest
Created on Feb 14, 2019

Best Effort Attempt to Default useIBMCipherMappings

Please change IBM MQ to make a best effort to default the useIBMCipherMappings to false if no IBM security providers are queried in the JRE. I understand that this RFE is similar to RFE 108278 which was rejected to remove useIBMCipherMappings. I do agree that there is a need to still have this useIBMCipherMappings option if IBM MQ is unable to default this value correctly, but I would assume IBM MQ could make an educated guess by querying the security provider list and get it right at least 90% of the time. We constantly have MQ Java applications that use Oracle JREs that are forgetting to set this useIBMCipherMappings option and it causes delays to our development lifecycle and sometimes errors in Production. We are ok if IBM doesn't get the useIBMCipherMappings=false correct and then we have to set it explicitly. But IBM MQ making an initial attempt to get it right would go a long way to alleviate the previously mentioned TLS issues with non-IBM JREs using IBM MQ and TLS.

Idea priority High
RFE ID 129984
RFE URL
RFE Product IBM MQ
  • Guest
    Reply
    |
    Dec 15, 2023
    Delivered
  • Guest
    Reply
    |
    Apr 4, 2019

    This is something we will consider implementing as part of a broader update around JSSE capabilities in a future version of MQ.

  • Guest
    Reply
    |
    Feb 15, 2019

    IBM probably has this on their radar, but please also use the IETF naming standards for the TLS 1.3 CipherSuites for IBM MQ.

    TLS 1.3 RFC -> https://tools.ietf.org/html/rfc8446

    +------------------------------+-------------+
    | Description | Value |
    +------------------------------+-------------+
    | TLS_AES_128_GCM_SHA256 | {0x13,0x01} |
    | TLS_AES_256_GCM_SHA384 | {0x13,0x02} |
    | TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
    | TLS_AES_128_CCM_SHA256 | {0x13,0x04} |
    | TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} |
    +------------------------------+-------------+

    This will help prevent the issue we have at TLS 1.2 with the CipherSuite naming issue between IBM and the IETF CipherSuite names. Hopefully, the IBM JSSE is doing this, as well.

  • Guest
    Reply
    |
    Feb 15, 2019

    After doing more research into the IETF TLS specifications, I have found that it looks like the Oracle JSSE did follow the IETF CipherSuite naming standards, and IBM did not for either the IBM JSSE or IBM MQ queue manager TLS implementations. If this true, I feel the places even more onus on IBM to fix this in a way that is seamless to the customer. The IETF CipherSuite naming standards should be followed by a TLS implementer, in my opinion.

  • Guest
    Reply
    |
    Feb 15, 2019

    If both IBM/Oracle (and others) all followed the same naming standard for TLS Ciphers/Cipher Specs there would not be any need for a TLS Cipher mapper function in the first place..... Would make life so much easier for all.....

  • Guest
    Reply
    |
    Feb 14, 2019

    Another possible solution is to just have MQ inquire which ciphers are available rather than worry about the specific provider.

    The program at the URL below outputs all available cipher suites for the java it is executed from and puts a * in the first column if they are a default cipher. I tried this with Oracle Java 1.6 and 1.8 and IBM Java 1.6 and 1.7 and they all produced output:

    https://confluence.atlassian.com/stashkb/files/679609085/679772359/1/1414093373406/Ciphers.java

    With Oracle 1.8 I see this:
    java Ciphers|egrep '^\*'
    * SSL_DHE_DSS_WITH_3DES_EDE_CBC_SH
    * SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
    * SSL_RSA_WITH_3DES_EDE_CBC_SHA
    * TLS_DHE_DSS_WITH_AES_128_CBC_SHA
    * TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
    * TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
    * TLS_DHE_RSA_WITH_AES_128_CBC_SHA
    * TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
    * TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
    * TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
    * TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
    * TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
    * TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    * TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
    * TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
    * TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
    * TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    * TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
    * TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
    * TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
    * TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
    * TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
    * TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
    * TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
    * TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
    * TLS_EMPTY_RENEGOTIATION_INFO_SCSV
    * TLS_RSA_WITH_AES_128_CBC_SHA
    * TLS_RSA_WITH_AES_128_CBC_SHA256
    * TLS_RSA_WITH_AES_128_GCM_SHA256

    With IBMs jre included in MQ v8.0.0.10 I see this:
    $ /opt/mqm/java/jre64/jre/bin/java Ciphers|egrep '^\*'
    * SSL_DHE_DSS_WITH_AES_128_CBC_SHA
    * SSL_DHE_DSS_WITH_AES_128_CBC_SHA256
    * SSL_DHE_DSS_WITH_AES_256_CBC_SHA
    * SSL_DHE_DSS_WITH_AES_256_CBC_SHA256
    * SSL_DHE_RSA_WITH_AES_128_CBC_SHA
    * SSL_DHE_RSA_WITH_AES_128_CBC_SHA256
    * SSL_DHE_RSA_WITH_AES_256_CBC_SHA
    * SSL_DHE_RSA_WITH_AES_256_CBC_SHA256
    * SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
    * SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
    * SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
    * SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
    * SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA
    * SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA256
    * SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA
    * SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384
    * SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA
    * SSL_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
    * SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA
    * SSL_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
    * SSL_ECDH_RSA_WITH_AES_128_CBC_SHA
    * SSL_ECDH_RSA_WITH_AES_128_CBC_SHA256
    * SSL_ECDH_RSA_WITH_AES_256_CBC_SHA
    * SSL_ECDH_RSA_WITH_AES_256_CBC_SHA384
    * SSL_RSA_WITH_AES_128_CBC_SHA
    * SSL_RSA_WITH_AES_128_CBC_SHA256
    * SSL_RSA_WITH_AES_256_CBC_SHA
    * SSL_RSA_WITH_AES_256_CBC_SHA256
    * TLS_EMPTY_RENEGOTIATION_INFO_SCSV