Robert, Andrew | 24 Oct 17:04 2014

IBM MQ and SSL - MQ Explorer works while MO71 failing

Hi everyone,

 

I have been watching the posts of late regarding MQ, SSL, and Poodle with interest.

 

We don’t want to have to go through recreating key databases so I chose TLS_RSA_WITH_AES_256_CBC_SHA256 as a reasonable middle ground for a low risk environment.

 

A little experimentation in my Dev environment shows that MQ Explorer connects just fine ( validating the key database, loaded certs, etc  are good).

 

Attempts to connect via MO71 show an SSL initialization error.

 

I realize this is a generic error so a peek at the queue manager log shows:

 

10/24/2014 09:39:12 AM - Process(9990.54) User(mqm) Program(amqrmppa)

                    Host(bmqd1) Installation(Installation2)

                    VRMF(7.5.0.3) QMgr(BMQD1)

 

AMQ9633: Bad SSL certificate for channel '????'.

 

EXPLANATION:

A certificate encountered during SSL handshaking is regarded as bad for one of

the following reasons:

(a) it was formatted incorrectly and could not be validated

(b) it was formatted correctly but failed validation against the Certification

  Authority (CA) root and other certificates held on the local system

(c) it was found in a Certification Revocation List (CRL) on an LDAP server

(d) a CRL was specified but the CRL could not be found on the LDAP server

(e) an OCSP responder has indicated that it is revoked

 

The channel is '????'; in some cases its name cannot be determined and so is

shown as '????'. The remote host is '001-v395 (168.66.158.230)'. The channel

did not start.

 

The details of the certificate which could not be validated are '????'.

 

The certificate validation error was 0.

ACTION:

Check which of the possible causes applies on your system. Correct the error,

and restart the channel.

 

Not unexpectedly, the MQ client shows the following:

 

10/24/2014 09:53:38 - Process(254476.1) User(robert_a) Program(mqmonntp.exe)

                      Host(001-V395) Installation(Installation1)

                      VRMF(7.5.0.3)

AMQ9665: SSL connection closed by remote end of channel 'ADMIN.SVRCONN'.

 

EXPLANATION:

The SSL or TLS connection was closed by the remote host 'bmqd1

(168.66.122.71)(1415)' during the secure socket handshake. The channel is

'ADMIN.SVRCONN'; in some cases its name cannot be determined and so is shown as

'????'. The channel did not start.

ACTION:

Check the remote end of the channel for SSL and TLS errors. Fix them and

restart the channel.

 

I will be reaching out separately to MQ Gem regarding this behavior but I figured I would put it to the list.

 

As anyone seen this behavior before?

 

I'd be 'okay' with things if both MQ Explorer and MO71 failed.. Kind of a head scratcher that one works and one does not.

 

 

 


Andrew Robert, MQ Architect
T: 617-954-5882  M: 508-330-7738  E: arobert-tT5qeM1EjDQ@public.gmane.org
MFS Investment Management
111 Huntington Avenue, Boston, MA 02119

 

 

MFS Mail Relay Service made the following annotation on 10/24/14, 10:48:36
---------------------------------------------------------------------------------------------------------------------------------------
This email communication and any attachments may contain proprietary, confidential, or privileged information. If you are not the intended recipient, you are hereby notified that you have received this email in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. The sender does not waive confidentiality or any privilege by mistransmission. If you have received this email in error, please notify the sender immediately, delete this email, and destroy all copies and any attachments. ==============================================================================
List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Jefferson Lowrey | 24 Oct 15:02 2014
Picon

Re: SSL client support

Some commentary on an otherwise excellent post.  The only intent of the commentary is to add information.

JMS draws a separation between the actual objects that are in use - the Connection object, the Destination Object, and etc - and the things that create those objects.  So you have a Factory object who's job it is to create a Connection - a ConnectionFactory, usually a QueueConnectionFactory (QCF).  So if you see people discusing JMS and QCFs, that's what they are talking about.

JMS also allows for those Factory objects to have their own configuration stored externally.  This is where the bindings file comes in.  The factories are created by additional objects - namely Context Objects.

So in order to establish a connection to a queue manager, JMS requires that you create three things:
  1. An InitialContext,
  2. A QueueConnectionFactory built by the InitialContext,
  3. A Connection object itself

The InitialContext is what uses the .bindings file.  But that's only if the context provider actually *uses* files.  It is very typical in JEE server arenas (like WAS) for the context provider to use LDAP or otherwise a Java Naming and Directory Interface (JNDI) provider that uses a distributed data store.  When using a file-based JNDI (that is, a .bindings file), you will almost certainly use a class named com.sun.jndi.fscontext.RefFSContextFactory .  (FS in this case is for "file system").
If you do a google search for "jndi bindings file" you will run into a variety of links that may provide a more nuanced explanation of what's going on, as well as a few step-by-steps.

When using SSL with JMS, the major two differences are that you need to configure the QueueConnection object (built by the QCF) to contain the necessary SSL properties, and you need to configure the necessary keystore and truststores (which can be the same file) on the JMS client side to know about the right certificates.   Whether or not a given JavaRuntimeEnvironment (JRE) ships with a default truststore that knows about all of the modern CAs depends rather a bit on the JRE itself.  And there are some security implications of leaving a truststore filled with more certificates than you absolutely require - if someone intercepts your connection to the queue manager using a cert signed by "the wrong" CA, your app would still connect to the bogus QM.

Thank you,

Jeff Lowrey




From:        Frank Swarbrick <00000006cad63953-dmarc-request-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org>
To:        MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org
Date:        10/23/2014 07:00 PM
Subject:        Re: [MQSERIES] SSL client support
Sent by:        MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org>



I never got a detailed example of how to configure a JMS application to support SSL encryption, but after reading dozens of only partially helpful websites and doing a lot of "just trying things" I finally got it working.  And it was, in the end, "simple".  Just took me a long time to get there!

For "the world" here is basically what is required...

JMS uses something called a .bindings file to hold the configuration information for connecting to an MQ manager using 'client' mode.  The .bindings file can be created/updated using the "JMSAdmin" tool that comes with MQ.  One need only specify the appropriate SSLCIPHERSUITE parameter that corresponds to the SSLCIPH parameter specified for the channel on the MQ Manager.

Here is an example of the (relevant) parameters on the MQ manager channel configuration:
DEFINE CHANNEL(MY_SSL_CHANNEL) SSLCIPH(RC4_MD5_US) SSLCAUTH(OPTIONAL) SSLPEER( )

Given this, one can use the following JMSAdmin command (all one one line) to define a JMS "Queue Connection Factory" that will use SSL:
DEFINE QCF(myQCF) TRANSPORT(CLIENT) QMANAGER(MQM1) HOSTNAME(mymqhost.com) PORT(1414) CHANNEL(MY_SSL_CHANNEL) SSLCIPHERSUITE(SSL_RSA_WITH_RC4_128_MD5)

The final consideration appears to be if the server certificate presented to the client by the MQ manager is signed by a trusted CA; that is a CA with a certificate present in the default "java Trust store" for your JVM.  In the case of my Java 7 64-bit JVM running on windows that Trust store is here: C:\Program Files\Java\jre7\lib\security\cacerts.  Surely it is elsewhere for other JVMs and other operating systems.  Nonetheless, it appears to have the certificates for the major CAs present, and thus (I believe!!) if your MQ manager's certificate is signed by one of these CAs it appears you don't need to "install" the certificate in the java Trust Store.

The last part is a bit of guess work, and I'd love to know if my assumptions of why I don't need to load my server cert in to a trust store, even though pretty much everything I read on the web indicated that I needed to do that.

If SSL authentication is required its a slight bit more work (and a java Key Store is definitely required).  I can go in to it if anyone is interested.

Or perhaps all of this is "well known" already.
Oh, I should mention that MQ Explorer can also be used to create/update the .bindings file.  I'll leave the instructions on that as an exercise for the reader.  It's much easier to document scripting actions than it is to document a GUI!

--
Frank Swarbrick
Mainframe Applications Architect
FirstBank -- Lakewood, CO USA



List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Tim Zielke | 24 Oct 14:38 2014

Re: IBM MQ, SSL and the POODLE Attack

I did open a PMR to get some clarity to my question on if a SSL v3 cipher like RC4_MD5_US (which I think is non-CBC) is susceptible to POODLE.  This was the response.

 

“The vulnerability is specifically within the SSLv3 protocol, thus that protocol must not be used if the customer wants to close their exposure to the vulnerability.”

 

Tim Zielke | CICS/MQ Systems Programmer

Aon Service Corporation | Aon Technology | Enterprise Architecture and Engineering

4 Overlook Point, Lincolnshire, IL 60069 

t +1.847.295.5000

tim.zielke <at> aon.com

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Frank Swarbrick
Sent: Thursday, October 23, 2014 6:36 PM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: IBM MQ, SSL and the POODLE Attack

 

That article is also interesting in that it states that only web browser clients are vulnerable. Since we're talking about MQ clients here, is there still a concern?  (Not that remediation on MQ shouldn't be attempted; just that perhaps it's not as important as in the web browser world.)

 

I know little about security, so take this comment for what it's worth!

 

Frank

From: Tim Zielke <tim.zielke <at> AON.COM>
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Sent: Wednesday, October 22, 2014 3:04 PM
Subject: Re: IBM MQ, SSL and the POODLE Attack

 

Here is something that I recently ran across that I thought was worth posting.  If someone with more MQ or encryption knowledge wants to refute my statements, please do.  I don’t claim to be an expert!

 

It sounds like there are other valid security reasons to move from RC4, but one thing I have just become aware of is that it looks like RC4 is not susceptible to POODLE because it is not a CBC based cipher.

 

 

So it does look like there are MQ SSL v3 ciphers (i.e RC4_MD5_US) that are not susceptible to POODLE. 

 

Please note, I am not trying to refute the recommendation of the IBM MQ security bulletin on POODLE.  I just thought this extra piece of information was worth knowing for the other MQ administrators out there.

 

Thanks,

Tim

 

 

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of T.Rob
Sent: Wednesday, October 22, 2014 12:55 PM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: IBM MQ, SSL and the POODLE Attack

 

SHA1 is deprecated but still viable for compatibility on those platforms where it is the greatest common denominator.  If you can get past SHA1, do so.  I haven't looked recently to see the distribution of ciphers across all platforms but for Dave's case (Bloomberg's clients all over the map on versioning) it might not be possible.  Or at least not without provisioning channels with the names "DEPRECATED" and "SECURE" in them and making clients switch to the secure ones where possible.  Yeah, I know its invasive but the difference represents latent risk and making two sets of channels is the least invasive thing I can think of that raises visibility to customers.  In any case, it isn't good if one back-level customer imposes that latent risk on the other 99.  Classes of service are the way to go here.

 

 

Kind regards,

-- T.Rob

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, October 22, 2014 11:44 AM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: IBM MQ, SSL and the POODLE Attack

 

T.Rob,

If we’re going to be changing Ciphers to avoid SSL, what about also staying away from SHA-1, even the TLS SHAs. Hasn’t SHA-1 been (theoretically?) compromised and if you are going to pic a TLS SHA Cipher, you should pick one that is not SHA-1?

 

Table showing which Ciphers use SSL or not, which use SHA-1 or not:

 

 

I Googled “Chrome Support for SHA-1” after overhearing someone talking about it and that’s why I’m thinking we should no longer choose SHA-1 for anything new. Yes?

 

 

Peter Potkay

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of T.Rob
Sent: Wednesday, October 22, 2014 10:53 AM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: IBM MQ, SSL and the PODLE Attack

 

> Since SSL v3 is no longer supported, the security community has basically “pulled the plug” on SSL v3. 

 

About time.  SSL v3 has other known vulns, but apparently this one we care about.  There's an easy test for it so fair enough.  Incidentally, as you are looking for alternate ciphers, keep in mind that MD5 is also broken and CBC has some known issues.  If I had to pick one, I'd take CBC over MD5 in a heartbeat though.

 

The SSL Labs site Peter points to is great.  I frequently point people at it.  And while you are busy testing, take a look at http://checktls.com where they test your company's SMTP (email) server.  As bad as HTTPS is, email is 100 times worse.  Half the time the servers are set up to accept plaintext connections if the encrypted ones fail and the encryption is often SSL at best.  But nobody sees the SMTP servers or deals with mail transfer at the back end other than admins.  Instead of encryption they have a kludge of putting authentication info into DNS records but it's hardly what you'd call secure.  Wouldn't it be cool if CheckTLS.com went viral and half the net started asking their companies and ISPs why email was so bad?

 

 

Kind regards,

-- T.Rob

 

T.Robert Wyatt, Managing partner

IoPT Consulting, LLC

+1 704-443-TROB (8762) Voice/Text

+44 (0) 8714 089 546  Voice

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Tim Zielke
Sent: Wednesday, October 22, 2014 9:43 AM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: IBM MQ, SSL and the PODLE Attack

 

My understanding is that any cipher that uses the TLS protocol would remediate POODLE.  I used the MQ v8 manual which lists what protocol (i.e. SSL v3, TLS 1.0, TLS 1.2) the cipher is using -> http://www-01.ibm.com/support/knowledgecenter/#!/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q014260_copy.htm

 

As Isvtan mentioned, it would be better to also choose a TLS cipher that is also FIPS compliant.  The IBM MQ security bulletin for POODLE tells you which TLS ciphers are not FIPS compliant -> http://www-01.ibm.com/support/docview.wss?uid=swg21687433&myns=swgws&mynp=OCSSFKSJ&mync=E

 

This is my understanding of POODLE based on the research I have done.  POODLE (Padding Oracle on Downgraded Legacy Encryption) is a new security vulnerability on SSL v3.  Padding Oracle is the method to do the security breach.  Downgraded Legacy Encryption is SSL v3.  Since SSL v3 is no longer supported, the security community has basically “pulled the plug” on SSL v3. 

 

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of David Awerbuch (BLOOMBERG/ 120 PARK)
Sent: Wednesday, October 22, 2014 8:22 AM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: IBM MQ, SSL and the PODLE Attack

 

Is there a definitive list of the TLS cipherspecs?

We are running 7.5 mgrs, our connection partners are running server 8.0, 7.5, 7.1, 7.0, and a few are still at 6.0.
Customer client verions are across the spectrum.

Thanks.
Dave

----- Original Message -----
From: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
At: Oct 21 2014 21:01:14

It looks like POODLE has caused the security community to put the fork in SSL.  We just have TLS from here on out, for “secure” MQ ciphers.

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of dhornby5 <at> COMCAST.NET
Sent: Tuesday, October 21, 2014 6:34 PM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: IBM MQ, SSL and the PODLE Attack

 

yes, AFAIK you just need to use a TLS cipherspec

 

From: "Peter M Potkay (CTO Architecture + Engineering)" <Peter.Potkay <at> THEHARTFORD.COM>
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Sent: Tuesday, October 21, 2014 5:19:41 PM
Subject: Re: IBM MQ, SSL and the PODLE Attack

 

Would it be accurate to say…If your QM is running with SSLFIPS(YES) you are not vulnerable to POODLE, but you do not necessarily need to be SSL FIPS compliant to remediate the POODLE attack.

 

Peter Potkay

 

From: MQSeries List [mailto:MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Neil Casey
Sent: Tuesday, October 21, 2014 4:58 PM
To: MQSERIES <at> LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: IBM MQ, SSL and the PODLE Attack

 

Hi,

 

thanks for your work, and for publishing the results.

 

I would just like to ask… what was the cipher spec defined in the channel?

 

Successfully establishing an MQ channel requires more than just the SSL session. The negotiated cipher has to match the SSLCIPH value too.

 

Regards,

 

Neil Casey.

 

 

On 22 Oct 2014, at 4:48 am, Istvan M. <ipl873 <at> GMAIL.COM> wrote:

 

Hello List,

 

just tested on Linux with a small script provided by RedHat.

 

QMNAME(QM1V701)                         SSLFIPS(NO)

-bash-4.1$ ./poodle.sh 

127.0.0.1:1414 - Vulnerable!  SSLv3 connection established using SSLv3/AES128-SHA

 

QMNAME(QM1V701)                         SSLFIPS(YES)

-bash-4.1$ ./poodle.sh 

127.0.0.1:1414 - Not vulnerable.  Failed to establish SSLv3 connection.

 

poodle.sh: https://access.redhat.com/articles/1232123 at "attachments"

 

So enabling FIPS mode really solves this vulnerability.

 

On Mon, Oct 20, 2014 at 8:23 PM, Istvan M. <ipl873 <at> gmail.com> wrote:

Hello List,

 

I've been waiting for this technote, really, we suspected that enabling SSLFIPS with a good cipher (TLS_RSA_WITH_AES_256_CBC_SHA for example, good for distributed, Z and i platforms) will eliminate this problem.

Now it's official. Tomorrow I'll test it. I assume Broker is also affected (seems no exceptions, everything is affected if it uses SSLv3).

 

On Mon, Oct 20, 2014 at 6:46 PM, Potkay, Peter M (CTO Architecture + Engineering) <Peter.Potkay <at> thehartford.com> wrote:

This just came out from IBM on how MQ is impacted by POODLE:

 

 

 

Still waiting for the WMB TechNote on POODLE.

 

 

 

Peter Potkay

 

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information.  If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

 

--

 

Üdvözlettel / Best regards,

Melich István / Istvan Melich

 

 

--

 

Best regards / Üdvözlettel,

MELICH, István

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information.  If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 



<< "Once the game is over, the king and the pawn go back into the same box." - Anon >>

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information.  If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

 

 

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Johnson, William | 23 Oct 21:57 2014

How to tell who deleted/read a message from a queue?

Trying to track down who (or what) read or cleared a message from a queue. Is there a way I can tell that? SMF records perhaps?

 

TIA

 

Bill Johnson

Mainframe Tech Support

216-595-4778

 

 

Visit MedMutual.com

CONFIDENTIALITY NOTICE:
This message is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential or exempt from disclosure by law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are strictly prohibited from printing, storing, disseminating, distributing or copying this message. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature, unless a specific statement to the contrary is included in this message.
Thank you, Medical Mutual.


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Robert, Andrew | 23 Oct 19:04 2014

Question regarding disable of SSL3 in MQSeries 7.5.0.x - can it be done in the qm.ini

Hi everyone,

 

I  know that you can specify an environmental parameter to disable SSL3 by doing "GSK_PROTOCOL_SSLV3=OFF" but this becomes an all or nothing option for queue managers on the server.

 

This prevents taking a phased approach to cut over the queue managers.

 

Can this be done within the qm.ini?

 

If so, does anyone know the parameter to set?

 

Thanks,

 


Andrew Robert, MQ Architect
T: 617-954-5882  M: 508-330-7738  E: arobert-tT5qeM1EjDQ@public.gmane.org
MFS Investment Management
111 Huntington Avenue, Boston, MA 02119

 

 

MFS Mail Relay Service made the following annotation on 10/23/14, 12:49:19
---------------------------------------------------------------------------------------------------------------------------------------
This email communication and any attachments may contain proprietary, confidential, or privileged information. If you are not the intended recipient, you are hereby notified that you have received this email in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. The sender does not waive confidentiality or any privilege by mistransmission. If you have received this email in error, please notify the sender immediately, delete this email, and destroy all copies and any attachments. ==============================================================================
List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

How to authority check the q name, even if you provide the QM name

So I’m going along, carefully granting setmqaut rules for the app’s service account to only allow it the bare minimum it needs on QM1, the QM it connects to. Feeling pretty good, got this guy locked down tight. It can only get from its queues. It’s a Service Provider, so it replies to incoming requests by responding to the Reply To Queue and Reply To Queue Manager of the request message. So now we just grant this app on QM1 put access only to the specific reply queues we will allow.

 

And, roadblock. I don’t understand how to only allow this app on QM1 put access to the specific reply queues if its putting to a fully qualified Reply Q on Reply To QM. Its issuing an MQOPEN (MQPUT1) call that is providing the destination queue AND the destination QM.

 

The app will need to send replies to QM2, QM3……QM98, QM99. These QMs may be in the same MQ Cluster, or they may be reached via traditional SNDR/RCVR channels. In any event, the best I can do is restrict access for the app on QM1 to only being able to put to QM2, QM3……QM98, QM99 at the QM level, if I use ClusterQueueAccessControl=RQMName and setmqaut rules with -t rqmname, as described here:

http://www-01.ibm.com/support/docview.wss?uid=swg21586095

 

 

But that is pointless. I just allowed the app to put to every queue on every one of those QMs based on what the receiving channel on the destination QM to put to, which is every app queue on the destination QM. Why am I gonna kill myself restricting what apps queues the app can access on QM1 if I have to allow it access to every app queue on QM2 thru QM99?

 

Creating Alias Queue Definitions for the reply queues on QM1 won’t work – since the replying app is fully qualifying the MQOPEN/MQPUT1 and specifying the destination QM, QM1 will not even consider the locally defined Alias queue. And the Reply Queue is going to be the same name on multiple QMs anyway, so a single Alias queue for that name on QM1 doesn’t work anyway.

 

Now, I suppose I could change all my Receiver and Cluster Receiver channels to run with PUTAUT set to Context, so those channels do authority checking for each message as it arrives at the destination QM, and we go insane trying to manage profiles on every QM for every potential ID that may come across. No thanks. Let’s get back to reality.

 

 

What I need is for QM1 to do authority checking against the queue name in the MQOPEN/MQPUT1 call whether the MQOPEN/MQPUT1 call specifies a destination QM or not. Is there any way to make this happen?  MQ 7.5 by the way.

 

 

 

Peter Potkay

 

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information.  If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Coombs, Lawrence | 22 Oct 14:38 2014

Re: QSTATUS command - Interpretation

I had an incident yesterday that is simply driving me crazy.

 

Application:

Two AIX servers running MQ 7.0.1.2 receives requests into a cluster queue (one on each).

Responders are four JVMs running jboss and using MDBs to receive the requests, process them and place the results on another queue. Two JVMs connect to each  MQServer and read form the same cluster queue.

 

For a couple of hours I noticed that the QTIME (QSTATUS command) shot up to between 300000 – 700000 microseconds (which is 300 – 700 milliseconds). The QTIME is normally around 600 microseconds or less. The MSAGE would sporadically jump from 1 –to  as much as 9 seconds. I could see the queue depth increasing and the MDBs were not pulling the messages even though there were ample threads running (IPPROCS > 10). Then all of sudden the messages would get picked up and processed. The UNCOMM was always NO. I had the network folks, UNIX admins investigate and they found nothing.

 

I recycled the JVMs and even rebooted one of the AIX servers, no change. After a couple of hours everything went back to normal.

 

What would cause the QTIME to get so high? These messages are non-persistent and I did not observe any memory, I/O and the CPUs were almost idle.

Also, how can the MSAGE parameter jump to 9 seconds, yet the QTIME averages stayed between the 300 - 700 millisecond range?

 

Any insight would be appreciated.

 

This message, including any attachments, is the property of Sears Holdings Corporation and/or one of its subsidiaries. It is confidential and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it without reading the contents. Thank you.

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Paul Clarke | 21 Oct 18:45 2014

MO71 Version 8.0.1 available

Oh dear....for all of you who downloaded this version please accept my apologies. It seems a little bug has crept in which prevents it showing the horizontal scrollbar in dialogs. This was caused by a small change to fix a scrollbar clash. Anyway, if you download a fresh version from here http://www.mqgem.com/mo71_download.html you should find it fixed.

This will serve me right for making the version available immediately rather than having a Beta,

My thanks to those of you who pointed out the problem to me,

Cheers,
Paul.
 
Paul Clarke

MQGem Software Limited
www.mqgem.com

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Paul Clarke | 21 Oct 12:38 2014

MO71 Version 8.0.1 available

Hi,

 

I am pleased to announce that Version 8.0.1 of MO71 is now available at http://www.mqgem.com/mo71_download.html

 

This is a minor release which was only intended to contain one feature which has been requested by a number of customers and that is a password cache file. This allows the user to store their Queue Manager passwords in a cache file making accessing their Queue Managers much easier.

 

However, another of my customers, Peter Potkay, asked so nicely for the ability to view the attributes of multiple Queue Managers in a single window that that has also been added. This means that it is now easy to make queries such as ‘show me any Queue Managers which are MQ 7.1 or earlier’.

 

Anyone with a licence for a previous version of MO71 can download and start using the new version immediately at no additional cost.

 

If anyone would like to try out this version then please send a request to support-PvZknbXPofMAvxtiuMwx3w@public.gmane.org for a one month trial licence provided free with no obligation to buy.

 

Cheers,

Paul.

 

Paul Clarke

MQGem Software Limited
www.mqgem.com

List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

IBM MQ, SSL and the PODLE Attack

This just came out from IBM on how MQ is impacted by POODLE:

 

http://www-01.ibm.com/support/docview.wss?uid=swg21687433&myns=swgws&mynp=OCSSFKSJ&mync=E

 

 

Still waiting for the WMB TechNote on POODLE.

 

 

 

Peter Potkay

 

************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information.  If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

Lyn Elkins | 20 Oct 16:07 2014
Picon

MQ for z/OS V8.0 Wildfire workshop

Greetings all!
We have a new MQ for z/OS V8.0 Wildfire workshop coming to Chicago and Dallas in 2014, and starting to
schedule for 2015.

The two day FREE (yes FREE, no cost except your local transport) event covers the new features of MQ for z/OS
V8 with particular emphasis on above the bar bufferpools and new SMF data. You will get hands on
experience, using our system to test and explore this new release.

The dates for the events are:
Chicago - November 19 & 20
Dallas - December 10 & 11

Please contact your local IBM representative to get enrolled. We would love to see you there!

To unsubscribe, write to LISTSERV@... and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Gmane