WMQ TOFU - it's not just for vegetarians anymore

[T.Rob]

Hi Listers,



I wanted to toss around some hypothetical ideas about cert management. It's
probably the biggest impediment I see to enabling TLS channels across the
board so I'd like to start mapping the territory by kicking off a dialog
about where the gaps are and in what form they might be filled.



One of the MQ enhancements I've been lobbying for is TOFU - Trust On First
Use. An example of this is the warning you get when using SSH or SCP when
it says something along the lines of "Hey, this is a new certificate. Here
are the details. Do you want to trust it?"



Of course, with WMQ there's no trusting the certificate without putting it
into the KDB and running REFRESH SECURITY TYPE(SSL) so I would not expect
that this process would be automatic for existing queue managers. It might
instead store the certificate in a temporary queue and an Explorer plug-in
or command-line utility would interrogate the queue to tell the admin what
certs are pending.



There are a few problems I'm trying to solve here. One is that deployment
of a new cluster should be easy to do with TLS enabled. WAS ND creates a
lightweight CA, generates certificates and distributes keys throughout the
cluster, all without user involvement. I'd like that level of simplicity in
WMQ clusters. For a new QMgr, it would be fairly easy to do since the cert
would be generated prior to the QMgr starting up - so no REFRESH SECURITY in
most cases. If the repository was also the CA, it would not need a REFRESH
SECURITY since it would not need the cluster member's cert, but rather just
the static signer. The certs would include the cluster name and the
repository's signer. If you had taken the trouble to provision a non-admin
user ID for the MCAUSER, the appropriate CHLAUTH rules and SSLPEER would be
added as well.



The other problem I'd like to solve is where you have a 3rd party interface.
The business partner can usually tell you their cert is Verisign (or
whatever) but not necessarily *which* signer chain and root cert. Then it's
up to you to hunt around for the right signer on the CA's web site. Good
luck with that. On the other hand, it would be possible to capture the
signer cert from the inbound connection and either display its attributes or
even load it directly to the KDB. There are, of course, a few issues with
loading whatever cert is presented. The first issue being that the root CA
certs are distributed with GSKit (and Windows, and Mozilla, and Safari,
etc.) for a reason. I could create a root CA signer cert with a
DN="VeriSign Class 3 Public Primary Certification Authority - G5" and a
signer with the appropriate DN. If I could get my QMgr between you and your
business partner, and if all you checked was the DN and not the fingerprint
or serial number, then you might trust *my* cert thinking it's Verisign.
Not good. If the cert you are accepting is expected to have been signed by
a commercial CA it would be best to fetch the signer chain from the source.
Or maybe to compare the one received to the ones distributed with GSKit so
you know you have a good one before loading it. After verifying that the
cert received is signed by a "known good" cert, the only thing left is to
make sure the Distinguished Name is the one you are expecting.



Finally, we are probably all familiar by now with the issue where the remote
site's certificate expires and the channels die. It's pretty tough to
diagnose this remotely and you get no warning. On the other hand, it's
possible to inspect the other side's cert during the TLS handshake and parse
the expiration date. With that information it would be possible to write an
error log entry, send a PCF event message, send an email or whatever,
notifying the local admin "hey the cert on the other side of channel X.Y.Z
expires soon!" This might avert an occasional outage, yes?



All of this can be automated to some degree or another. I'm curious how
useful people think it would be to do this. Assuming it is considered
useful, then what type of security controls would you need before, for
example, adding the remote cert signer chain to your KDB? Would you want
the information about the remote side's signer chain so you could manually
download and add the appropriate certs from the commercial CA? Would you
want the typical TOFU message (hey, I'm being presented with an unknown
certificate do you want to trust it?) followed by the utility adding the
cert signer chain for you? If so does that require an Explorer dialog,
command line utility or both?



All of this is hypothetical. There may or may not be similar functionality
planned for a future release, frankly I don't know. What I'm more
interested in is to map out the missing function and then flesh it out a bit
in terms of how it might be implemented. Then I'd like to stand up a
prototype that we could build on and which would get us even further down
the road. Anyone interested?



-- T.Rob




To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Neil Casey]

Hi T.Rob,

This is an interesting idea, which I will have to think about. It does
bring up the issue of the impact of refresh security type(ssl) though.
This is currently a significant impediment in large production
environments to TLS simplification.

I think the justification for killing all TLS channels at the moment is
that the certificate provided for trust of any channel might have been
removed, so we have to force restart of all the channels in case they have
lost trust. This is fair enough from an initial viewpoint, but in my
experience, most changes to trust involve adding new certificates, not
removing old ones.

So it would be great to include an ability to add new trust without
impacting existing channels as part of this process of simplifying TLS
enablement. Maybe something like

refresh security type(addsslca)

which could add new trusted certs from the existing kdb but would not
allow a change of the kdb name, or removal of existing trust.

As to the rest of your suggestions as they stand at the moment...

I like the idea that on a failed TLS validation, the queue manager should
capture the certificates presented, and write a message capturing the
channel, and certificates. There would need to be an ability to prevent
repeated creation of identical messages (maybe publish as a retained
publication, with the topic name based on the channel name and certificate
CN?)

Topic: /system/ssl/trust/CHLNAME/CNvalue
Message Content PEM format certificates presented by the channel partner.

I don't think I would want the queue manager to try to add the trust to
the key store automatically. Even though GSKit 8 provides an ability to do
things like this from the mqm user, it strikes me as dangerous. I already
have instructions to set my entire ssl directory content to mode 500 after
setting up a key store, only altering them back to 700 while an actual
change to the key store is being performed. After the change, they get put
back to 500.

But a utility to extract certificates and DNs from a queue/topic and put
them into files which I could then use to add the certs into my CMS key
store would be really useful. It does leave a problem of how to determine
whether the certificates are valid or have been compromised though.

I am not sure that attaching a CA to a cluster repository is going to
work. I see lots of queue managers in more than one cluster (separating
security, or separating transmission queues, or separating pub/sub from
point to point messaging). Given that a queue manager only has one
certificate (not one per channel or one per cluster), it would be
difficult to extend a repository based CA configuration to many potential
topologies. Although I can see that it would make "secure out of the box"
easier, I think undoing the cluster repos based TLS structure in order to
implement a company wide managed CA basis for trust, which would be needed
on a more mature site, would be painful.

Thinking about reporting on upcoming certificate expiry is a really nice
idea. It looks like the current SSL reporting doesn't include this for
active channel statuses, so I think there is no way to implement this
using the current level of details exposed by MQ.



Regards

Neil Casey
Technical Consultant Messaging


Phone: [phone] | Mobile: [phone]
E-mail: ***@au1.ibm.com


c/- NAB 14/555 Collins St
Melbourne, Vic 3000
Australia







Disclaimer. All ideas and opinions expressed in this email are those of
the author, and do not represent anything from IBM.


From: "T.Rob" <***@IOPTCONSULTING.COM>
To: ***@listserv.meduniwien.ac.at,
Date: 11/06/2013 10:01
Subject: WMQ TOFU - it's not just for vegetarians anymore
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>



Hi Listers,

I wanted to toss around some hypothetical ideas about cert management.
It's probably the biggest impediment I see to enabling TLS channels across
the board so I'd like to start mapping the territory by kicking off a
dialog about where the gaps are and in what form they might be filled.

One of the MQ enhancements I've been lobbying for is TOFU – Trust On First
Use. An example of this is the warning you get when using SSH or SCP when
it says something along the lines of "Hey, this is a new certificate. Here
are the details. Do you want to trust it?"

Of course, with WMQ there's no trusting the certificate without putting it
into the KDB and running REFRESH SECURITY TYPE(SSL) so I would not expect
that this process would be automatic for existing queue managers. It
might instead store the certificate in a temporary queue and an Explorer
plug-in or command-line utility would interrogate the queue to tell the
admin what certs are pending.

There are a few problems I'm trying to solve here. One is that deployment
of a new cluster should be easy to do with TLS enabled. WAS ND creates a
lightweight CA, generates certificates and distributes keys throughout the
cluster, all without user involvement. I'd like that level of simplicity
in WMQ clusters. For a new QMgr, it would be fairly easy to do since the
cert would be generated prior to the QMgr starting up – so no REFRESH
SECURITY in most cases. If the repository was also the CA, it would not
need a REFRESH SECURITY since it would not need the cluster member's cert,
but rather just the static signer. The certs would include the cluster
name and the repository's signer. If you had taken the trouble to
provision a non-admin user ID for the MCAUSER, the appropriate CHLAUTH
rules and SSLPEER would be added as well.

The other problem I'd like to solve is where you have a 3rd party
interface. The business partner can usually tell you their cert is
Verisign (or whatever) but not necessarily *which* signer chain and root
cert. Then it's up to you to hunt around for the right signer on the CA's
web site. Good luck with that. On the other hand, it would be possible
to capture the signer cert from the inbound connection and either display
its attributes or even load it directly to the KDB. There are, of course,
a few issues with loading whatever cert is presented. The first issue
being that the root CA certs are distributed with GSKit (and Windows, and
Mozilla, and Safari, etc
) for a reason. I could create a root CA signer
cert with a DN="VeriSign Class 3 Public Primary Certification Authority -
G5" and a signer with the appropriate DN. If I could get my QMgr between
you and your business partner, and if all you checked was the DN and not
the fingerprint or serial number, then you might trust *my* cert thinking
it's Verisign. Not good. If the cert you are accepting is expected to
have been signed by a commercial CA it would be best to fetch the signer
chain from the source. Or maybe to compare the one received to the ones
distributed with GSKit so you know you have a good one before loading it.
After verifying that the cert received is signed by a "known good" cert,
the only thing left is to make sure the Distinguished Name is the one you
are expecting.

Finally, we are probably all familiar by now with the issue where the
remote site's certificate expires and the channels die. It's pretty tough
to diagnose this remotely and you get no warning. On the other hand, it's
possible to inspect the other side's cert during the TLS handshake and
parse the expiration date. With that information it would be possible to
write an error log entry, send a PCF event message, send an email or
whatever, notifying the local admin "hey the cert on the other side of
channel X.Y.Z expires soon!" This might avert an occasional outage, yes?

All of this can be automated to some degree or another. I'm curious how
useful people think it would be to do this. Assuming it is considered
useful, then what type of security controls would you need before, for
example, adding the remote cert signer chain to your KDB? Would you want
the information about the remote side's signer chain so you could manually
download and add the appropriate certs from the commercial CA? Would you
want the typical TOFU message (hey, I'm being presented with an unknown
certificate do you want to trust it?) followed by the utility adding the
cert signer chain for you? If so does that require an Explorer dialog,
command line utility or both?

All of this is hypothetical. There may or may not be similar
functionality planned for a future release, frankly I don't know. What
I'm more interested in is to map out the missing function and then flesh
it out a bit in terms of how it might be implemented. Then I'd like to
stand up a prototype that we could build on and which would get us even
further down the road. Anyone interested?

-- T.Rob



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

[T.Rob]

Hi Neil,



I believe that the requirement around REFRESH SECURITY TYPE(SSL) has to do with security vulnerabilities if more than one copy of the KDB is loaded in memory at a time. The KDB is cryptographically integrity checked and so incremental operations such as "read a new cert into memory" would bypass that integrity check. It's possible to validate the cert independently, but the KDB itself is a single atomic object with its own crypto signature. So to load a new copy of the KDB requires first dumping the old one, then reading the new one in from scratch. Since it would be invalid to have a running channel using a copy of the "old" KDB the channels must be stopped.



Although I recognize it's a pain in the posterior, there are few scenarios that would support incremental addition of new certs that does not also result in either a) two KDBs resident at once; or b) channels running against a copy of a KDB that is no longer in memory. Both of these are worse from a security standpoint than the administrative headache of having to stop the channels, in my opinion.



I believe that MQIPT gets around this by running separate instances of the JVM. Depending on the prevalence of TLS deployed in the field, it may be a path for WMQ to follow as well. Not sure what that looks like, but I'm imagining spawning a new channel pooling process with the new KDB then deprecating all existing connections. If they ever stop, they restart under the newest pooling process. That's fairly deep code change so if something like that happens, I'd expect it to be based on wide adoption of TLS – which is my goal for this project.



Regarding the other comments, forget about what WMQ does or does not provide at this time. I've already developed tools that fetch the certificate and signer chain from the remote QMgr. I'm just trying to figure out how to implement the UI. There was a week after leaving IBM and before I got a contract that I didn't have any work so I came up with a TLS cert fetch and parse tool. The tricky part was to fetch the certs without generating an FDC due to that whole "something connected to me that wasn't a channel so I'm going to cut an FDC which makes your monitoring raise an alert" thing. But I got that solved. Then I thought "hey, I could point this thing at a repository and then inventory all the certs in the cluster," which I did. Then I thought "why not just use the CONNAME from any SDR/SVR/RQSTR channel, too?" Done. So at this point I have a tool that can be run on the repository or other QMgr, gathers up all the CONNAMEs, fetches any certs from those CONNAMES and then saves them all either as PEM or into a KDB. The KDB can be a dummy store or the actual KDB but I'm thinking that for safety and security, the reasons you chmod your kdb, this one should be a dummy KDB if used at all. Otherwise PEM files in the filesystem or as messages in a temp queue or retained pub. (Although I don't like your topic structure since the KDB is a global resource at this point, but then that's why I asked for feedback.)



Of course, once you have the certs, it's a simple matter to do useful stuff with them such as scrape the expiration dates into a report, check self-signed certs to see if they have CA=YES set (Alert! Alert!), or compare the signer cert chain cert received to the ones in a newly populated KDB (or perhaps a KDB that's been customized with signers from a business partner CA such as that run by the Fed) to then report *which* signer chain to use and if the one received matches (or not) the "known good" ones in the reference KDB.



So, does knowing that this much of the tool is already implemented change your response? The remote cert expiry report, which you assessed as currently impossible, is actually the simplest requirement of the bunch since I didn't use WMQ functions to do it. Since it's just a reporting function, there are no messy issues about updating anything.



The result of all this will become an article which I'll submit first to dWorks or to GWC if dW doesn't want it. In any case, I'll probably open-source the scripts and post them to Git Hub, once I know how they need to work. I checked with my boss and he/I told myself this would be OK to do. ;-)



Anyone who wants these tools before they are published is welcome to hire me. I have availability as of Monday. Steep discounts for new clients in Hawaii. Otherwise, I hope to have these submitted to dW within a few weeks or less, depending on feedback here and whether I'm working or on the bench next week.



-- T.Rob



From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Tuesday, June 11, 2013 2:34 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: WMQ TOFU - it's not just for vegetarians anymore



Hi T.Rob,

This is an interesting idea, which I will have to think about. It does bring up the issue of the impact of refresh security type(ssl) though. This is currently a significant impediment in large production environments to TLS simplification.

I think the justification for killing all TLS channels at the moment is that the certificate provided for trust of any channel might have been removed, so we have to force restart of all the channels in case they have lost trust. This is fair enough from an initial viewpoint, but in my experience, most changes to trust involve adding new certificates, not removing old ones.

So it would be great to include an ability to add new trust without impacting existing channels as part of this process of simplifying TLS enablement. Maybe something like

refresh security type(addsslca)

which could add new trusted certs from the existing kdb but would not allow a change of the kdb name, or removal of existing trust.

As to the rest of your suggestions as they stand at the moment...

I like the idea that on a failed TLS validation, the queue manager should capture the certificates presented, and write a message capturing the channel, and certificates. There would need to be an ability to prevent repeated creation of identical messages (maybe publish as a retained publication, with the topic name based on the channel name and certificate CN?)

Topic: /system/ssl/trust/CHLNAME/CNvalue
Message Content PEM format certificates presented by the channel partner.

I don't think I would want the queue manager to try to add the trust to the key store automatically. Even though GSKit 8 provides an ability to do things like this from the mqm user, it strikes me as dangerous. I already have instructions to set my entire ssl directory content to mode 500 after setting up a key store, only altering them back to 700 while an actual change to the key store is being performed. After the change, they get put back to 500.

But a utility to extract certificates and DNs from a queue/topic and put them into files which I could then use to add the certs into my CMS key store would be really useful. It does leave a problem of how to determine whether the certificates are valid or have been compromised though.

I am not sure that attaching a CA to a cluster repository is going to work. I see lots of queue managers in more than one cluster (separating security, or separating transmission queues, or separating pub/sub from point to point messaging). Given that a queue manager only has one certificate (not one per channel or one per cluster), it would be difficult to extend a repository based CA configuration to many potential topologies. Although I can see that it would make "secure out of the box" easier, I think undoing the cluster repos based TLS structure in order to implement a company wide managed CA basis for trust, which would be needed on a more mature site, would be painful.

Thinking about reporting on upcoming certificate expiry is a really nice idea. It looks like the current SSL reporting doesn't include this for active channel statuses, so I think there is no way to implement this using the current level of details exposed by MQ.



Regards


Neil Casey
Technical Consultant Messaging


_____



Phone: [phone] | Mobile: [phone]
E-mail: <mailto:neilc-***@public.gmane.org> Neil.Casey-***@public.gmane.org

IBM

c/- NAB 14/555 Collins St
Melbourne, Vic 3000
Australia



Certified for WebSphere





Disclaimer. All ideas and opinions expressed in this email are those of the author, and do not represent anything from IBM.


From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 11/06/2013 10:01
Subject: WMQ TOFU - it's not just for vegetarians anymore
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

_____




Hi Listers,

I wanted to toss around some hypothetical ideas about cert management. It's probably the biggest impediment I see to enabling TLS channels across the board so I'd like to start mapping the territory by kicking off a dialog about where the gaps are and in what form they might be filled.

One of the MQ enhancements I've been lobbying for is TOFU – Trust On First Use. An example of this is the warning you get when using SSH or SCP when it says something along the lines of "Hey, this is a new certificate. Here are the details. Do you want to trust it?"

Of course, with WMQ there's no trusting the certificate without putting it into the KDB and running REFRESH SECURITY TYPE(SSL) so I would not expect that this process would be automatic for existing queue managers. It might instead store the certificate in a temporary queue and an Explorer plug-in or command-line utility would interrogate the queue to tell the admin what certs are pending.

There are a few problems I'm trying to solve here. One is that deployment of a new cluster should be easy to do with TLS enabled. WAS ND creates a lightweight CA, generates certificates and distributes keys throughout the cluster, all without user involvement. I'd like that level of simplicity in WMQ clusters. For a new QMgr, it would be fairly easy to do since the cert would be generated prior to the QMgr starting up – so no REFRESH SECURITY in most cases. If the repository was also the CA, it would not need a REFRESH SECURITY since it would not need the cluster member's cert, but rather just the static signer. The certs would include the cluster name and the repository's signer. If you had taken the trouble to provision a non-admin user ID for the MCAUSER, the appropriate CHLAUTH rules and SSLPEER would be added as well.

The other problem I'd like to solve is where you have a 3rd party interface. The business partner can usually tell you their cert is Verisign (or whatever) but not necessarily *which* signer chain and root cert. Then it's up to you to hunt around for the right signer on the CA's web site. Good luck with that. On the other hand, it would be possible to capture the signer cert from the inbound connection and either display its attributes or even load it directly to the KDB. There are, of course, a few issues with loading whatever cert is presented. The first issue being that the root CA certs are distributed with GSKit (and Windows, and Mozilla, and Safari, etc
) for a reason. I could create a root CA signer cert with a DN="VeriSign Class 3 Public Primary Certification Authority - G5" and a signer with the appropriate DN. If I could get my QMgr between you and your business partner, and if all you checked was the DN and not the fingerprint or serial number, then you might trust *my* cert thinking it's Verisign. Not good. If the cert you are accepting is expected to have been signed by a commercial CA it would be best to fetch the signer chain from the source. Or maybe to compare the one received to the ones distributed with GSKit so you know you have a good one before loading it. After verifying that the cert received is signed by a "known good" cert, the only thing left is to make sure the Distinguished Name is the one you are expecting.

Finally, we are probably all familiar by now with the issue where the remote site's certificate expires and the channels die. It's pretty tough to diagnose this remotely and you get no warning. On the other hand, it's possible to inspect the other side's cert during the TLS handshake and parse the expiration date. With that information it would be possible to write an error log entry, send a PCF event message, send an email or whatever, notifying the local admin "hey the cert on the other side of channel X.Y.Z expires soon!" This might avert an occasional outage, yes?

All of this can be automated to some degree or another. I'm curious how useful people think it would be to do this. Assuming it is considered useful, then what type of security controls would you need before, for example, adding the remote cert signer chain to your KDB? Would you want the information about the remote side's signer chain so you could manually download and add the appropriate certs from the commercial CA? Would you want the typical TOFU message (hey, I'm being presented with an unknown certificate do you want to trust it?) followed by the utility adding the cert signer chain for you? If so does that require an Explorer dialog, command line utility or both?

All of this is hypothetical. There may or may not be similar functionality planned for a future release, frankly I don't know. What I'm more interested in is to map out the missing function and then flesh it out a bit in terms of how it might be implemented. Then I'd like to stand up a prototype that we could build on and which would get us even further down the road. Anyone interested?

-- T.Rob




_____

<http://listserv.meduniwien.ac.at/archives/mqser-l.html> List Archive - <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> Manage Your List Settings - <mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries> Unsubscribe

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


To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[T.Rob]

Oddly, there was more discussion of MQ TOFU in the halls at NYNJMQUG yesterday than here on-list. The gist of it was that the reporting functions sound great but nobody I spoke with wanted the tool to put any certs into the QMgr’s KDB, a dummy KDB or pretty much any other KDB. So unless I hear otherwise, I’ll have something that will pick up the CONNAMES from TLS channels, fetch the certs and display any that expire with a threshold. There will probably be options to run the tool against a specific CONNAME, in which case it will provide detailed attributes of the subject cert and signer chain.



Regarding the proposed function to fetch a business partner’s cert chain to see who signed it, one person said that, instead of installing the chain or checking against the “known good” ones in a default KDB, the tool should provide the URL at the CA where the signer chain could be found. Where that’s in the cert I’ll print it. I might add function to create your own lookup table so that you can add CAs not in IBM’s default list, if there’s interest.



Since it’s not loading any certs, I can’t call it TOFU anymore. Darn. Kinda liked the name.



-- T.Rob



From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Tuesday, June 11, 2013 3:31 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: WMQ TOFU - it's not just for vegetarians anymore



Hi Neil,



I believe that the requirement around REFRESH SECURITY TYPE(SSL) has to do with security vulnerabilities if more than one copy of the KDB is loaded in memory at a time. The KDB is cryptographically integrity checked and so incremental operations such as "read a new cert into memory" would bypass that integrity check. It's possible to validate the cert independently, but the KDB itself is a single atomic object with its own crypto signature. So to load a new copy of the KDB requires first dumping the old one, then reading the new one in from scratch. Since it would be invalid to have a running channel using a copy of the "old" KDB the channels must be stopped.



Although I recognize it's a pain in the posterior, there are few scenarios that would support incremental addition of new certs that does not also result in either a) two KDBs resident at once; or b) channels running against a copy of a KDB that is no longer in memory. Both of these are worse from a security standpoint than the administrative headache of having to stop the channels, in my opinion.



I believe that MQIPT gets around this by running separate instances of the JVM. Depending on the prevalence of TLS deployed in the field, it may be a path for WMQ to follow as well. Not sure what that looks like, but I'm imagining spawning a new channel pooling process with the new KDB then deprecating all existing connections. If they ever stop, they restart under the newest pooling process. That's fairly deep code change so if something like that happens, I'd expect it to be based on wide adoption of TLS – which is my goal for this project.



Regarding the other comments, forget about what WMQ does or does not provide at this time. I've already developed tools that fetch the certificate and signer chain from the remote QMgr. I'm just trying to figure out how to implement the UI. There was a week after leaving IBM and before I got a contract that I didn't have any work so I came up with a TLS cert fetch and parse tool. The tricky part was to fetch the certs without generating an FDC due to that whole "something connected to me that wasn't a channel so I'm going to cut an FDC which makes your monitoring raise an alert" thing. But I got that solved. Then I thought "hey, I could point this thing at a repository and then inventory all the certs in the cluster," which I did. Then I thought "why not just use the CONNAME from any SDR/SVR/RQSTR channel, too?" Done. So at this point I have a tool that can be run on the repository or other QMgr, gathers up all the CONNAMEs, fetches any certs from those CONNAMES and then saves them all either as PEM or into a KDB. The KDB can be a dummy store or the actual KDB but I'm thinking that for safety and security, the reasons you chmod your kdb, this one should be a dummy KDB if used at all. Otherwise PEM files in the filesystem or as messages in a temp queue or retained pub. (Although I don't like your topic structure since the KDB is a global resource at this point, but then that's why I asked for feedback.)



Of course, once you have the certs, it's a simple matter to do useful stuff with them such as scrape the expiration dates into a report, check self-signed certs to see if they have CA=YES set (Alert! Alert!), or compare the signer cert chain cert received to the ones in a newly populated KDB (or perhaps a KDB that's been customized with signers from a business partner CA such as that run by the Fed) to then report *which* signer chain to use and if the one received matches (or not) the "known good" ones in the reference KDB.



So, does knowing that this much of the tool is already implemented change your response? The remote cert expiry report, which you assessed as currently impossible, is actually the simplest requirement of the bunch since I didn't use WMQ functions to do it. Since it's just a reporting function, there are no messy issues about updating anything.



The result of all this will become an article which I'll submit first to dWorks or to GWC if dW doesn't want it. In any case, I'll probably open-source the scripts and post them to Git Hub, once I know how they need to work. I checked with my boss and he/I told myself this would be OK to do. ;-)



Anyone who wants these tools before they are published is welcome to hire me. I have availability as of Monday. Steep discounts for new clients in Hawaii. Otherwise, I hope to have these submitted to dW within a few weeks or less, depending on feedback here and whether I'm working or on the bench next week.



-- T.Rob



From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Tuesday, June 11, 2013 2:34 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: WMQ TOFU - it's not just for vegetarians anymore



Hi T.Rob,

This is an interesting idea, which I will have to think about. It does bring up the issue of the impact of refresh security type(ssl) though. This is currently a significant impediment in large production environments to TLS simplification.

I think the justification for killing all TLS channels at the moment is that the certificate provided for trust of any channel might have been removed, so we have to force restart of all the channels in case they have lost trust. This is fair enough from an initial viewpoint, but in my experience, most changes to trust involve adding new certificates, not removing old ones.

So it would be great to include an ability to add new trust without impacting existing channels as part of this process of simplifying TLS enablement. Maybe something like

refresh security type(addsslca)

which could add new trusted certs from the existing kdb but would not allow a change of the kdb name, or removal of existing trust.

As to the rest of your suggestions as they stand at the moment...

I like the idea that on a failed TLS validation, the queue manager should capture the certificates presented, and write a message capturing the channel, and certificates. There would need to be an ability to prevent repeated creation of identical messages (maybe publish as a retained publication, with the topic name based on the channel name and certificate CN?)

Topic: /system/ssl/trust/CHLNAME/CNvalue
Message Content PEM format certificates presented by the channel partner.

I don't think I would want the queue manager to try to add the trust to the key store automatically. Even though GSKit 8 provides an ability to do things like this from the mqm user, it strikes me as dangerous. I already have instructions to set my entire ssl directory content to mode 500 after setting up a key store, only altering them back to 700 while an actual change to the key store is being performed. After the change, they get put back to 500.

But a utility to extract certificates and DNs from a queue/topic and put them into files which I could then use to add the certs into my CMS key store would be really useful. It does leave a problem of how to determine whether the certificates are valid or have been compromised though.

I am not sure that attaching a CA to a cluster repository is going to work. I see lots of queue managers in more than one cluster (separating security, or separating transmission queues, or separating pub/sub from point to point messaging). Given that a queue manager only has one certificate (not one per channel or one per cluster), it would be difficult to extend a repository based CA configuration to many potential topologies. Although I can see that it would make "secure out of the box" easier, I think undoing the cluster repos based TLS structure in order to implement a company wide managed CA basis for trust, which would be needed on a more mature site, would be painful.

Thinking about reporting on upcoming certificate expiry is a really nice idea. It looks like the current SSL reporting doesn't include this for active channel statuses, so I think there is no way to implement this using the current level of details exposed by MQ.



Regards


Neil Casey
Technical Consultant Messaging


_____



Phone: [phone] | Mobile: [phone]
E-mail: <mailto:neilc-***@public.gmane.org> Neil.Casey-***@public.gmane.org

IBM

c/- NAB 14/555 Collins St
Melbourne, Vic 3000
Australia



Certified for WebSphere





Disclaimer. All ideas and opinions expressed in this email are those of the author, and do not represent anything from IBM.


From: "T.Rob" <t.rob-CkT6zf+urXSzW/GOMZKyElesiRL1/***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 11/06/2013 10:01
Subject: WMQ TOFU - it's not just for vegetarians anymore
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>

_____




Hi Listers,

I wanted to toss around some hypothetical ideas about cert management. It's probably the biggest impediment I see to enabling TLS channels across the board so I'd like to start mapping the territory by kicking off a dialog about where the gaps are and in what form they might be filled.

One of the MQ enhancements I've been lobbying for is TOFU – Trust On First Use. An example of this is the warning you get when using SSH or SCP when it says something along the lines of "Hey, this is a new certificate. Here are the details. Do you want to trust it?"

Of course, with WMQ there's no trusting the certificate without putting it into the KDB and running REFRESH SECURITY TYPE(SSL) so I would not expect that this process would be automatic for existing queue managers. It might instead store the certificate in a temporary queue and an Explorer plug-in or command-line utility would interrogate the queue to tell the admin what certs are pending.

There are a few problems I'm trying to solve here. One is that deployment of a new cluster should be easy to do with TLS enabled. WAS ND creates a lightweight CA, generates certificates and distributes keys throughout the cluster, all without user involvement. I'd like that level of simplicity in WMQ clusters. For a new QMgr, it would be fairly easy to do since the cert would be generated prior to the QMgr starting up – so no REFRESH SECURITY in most cases. If the repository was also the CA, it would not need a REFRESH SECURITY since it would not need the cluster member's cert, but rather just the static signer. The certs would include the cluster name and the repository's signer. If you had taken the trouble to provision a non-admin user ID for the MCAUSER, the appropriate CHLAUTH rules and SSLPEER would be added as well.

The other problem I'd like to solve is where you have a 3rd party interface. The business partner can usually tell you their cert is Verisign (or whatever) but not necessarily *which* signer chain and root cert. Then it's up to you to hunt around for the right signer on the CA's web site. Good luck with that. On the other hand, it would be possible to capture the signer cert from the inbound connection and either display its attributes or even load it directly to the KDB. There are, of course, a few issues with loading whatever cert is presented. The first issue being that the root CA certs are distributed with GSKit (and Windows, and Mozilla, and Safari, etc
) for a reason. I could create a root CA signer cert with a DN="VeriSign Class 3 Public Primary Certification Authority - G5" and a signer with the appropriate DN. If I could get my QMgr between you and your business partner, and if all you checked was the DN and not the fingerprint or serial number, then you might trust *my* cert thinking it's Verisign. Not good. If the cert you are accepting is expected to have been signed by a commercial CA it would be best to fetch the signer chain from the source. Or maybe to compare the one received to the ones distributed with GSKit so you know you have a good one before loading it. After verifying that the cert received is signed by a "known good" cert, the only thing left is to make sure the Distinguished Name is the one you are expecting.

Finally, we are probably all familiar by now with the issue where the remote site's certificate expires and the channels die. It's pretty tough to diagnose this remotely and you get no warning. On the other hand, it's possible to inspect the other side's cert during the TLS handshake and parse the expiration date. With that information it would be possible to write an error log entry, send a PCF event message, send an email or whatever, notifying the local admin "hey the cert on the other side of channel X.Y.Z expires soon!" This might avert an occasional outage, yes?

All of this can be automated to some degree or another. I'm curious how useful people think it would be to do this. Assuming it is considered useful, then what type of security controls would you need before, for example, adding the remote cert signer chain to your KDB? Would you want the information about the remote side's signer chain so you could manually download and add the appropriate certs from the commercial CA? Would you want the typical TOFU message (hey, I'm being presented with an unknown certificate do you want to trust it?) followed by the utility adding the cert signer chain for you? If so does that require an Explorer dialog, command line utility or both?

All of this is hypothetical. There may or may not be similar functionality planned for a future release, frankly I don't know. What I'm more interested in is to map out the missing function and then flesh it out a bit in terms of how it might be implemented. Then I'd like to stand up a prototype that we could build on and which would get us even further down the road. Anyone interested?

-- T.Rob




_____

<http://listserv.meduniwien.ac.at/archives/mqser-l.html> List Archive - <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> Manage Your List Settings - <mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries> Unsubscribe

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



_____

List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe <mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

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


To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html