Hi Paul,
MQ uses TLS and does so in a way that is safer than HTTP servers. An HTTP
server is meant to be stateless so the TLS and actionable data arrive
together. That is why HTTP was susceptible to the SSL renegotiation exploit
and WMQ wasn't. As long as you use a good key length and a strong cipher MQ
should be no more susceptible to breaking the cipher than anything else, and
less susceptible than an HTTP server.
The Snowden reports say that the NSA have unencrypted access to traffic
going through the big providers. At the same time, those companies all deny
that the NSA have access to their servers. While these appear to be
contradictory, it makes perfect sense to me. NSA has been complaining that
the Internet is going dark. Not Google going dark or Skype going dark, but
the *Internet* going dark. They don't want to have to set up shop at every
big provider. They don't have funds to do that and even if they did it
would let all sorts of traffic through.
So let's say instead that the Patriot Act the US CAs into giving them access
to root or even an intermediate signer. Then all they need to do is set up
shop on the backbone servers such that the SSL and TLS sessions terminate
there, then proxy the connection back to the provider. Well, we already
*know* they are in the backbone servers. This news broke a decade ago. But
to make the scheme most effective, it'd be useful to consolidate the
certificates to be spoofed. One good way to do that would be to have all
the CAs deprecate the old certs in favor of the new ones. For example, NIST
might deprecate 1024 bit certs which in turn would influence policy across
the board and CAs would follow suit. Then as everyone moved to upgrade to
2048 and 4096 bit certs, the NSA's signer would be valid for not just folks
like Google and Facebook, but for banks and insurance companies and online
stores and anyone else using a commercial CA in the US. So if you see these
actions by NIST and the CAs you might wonder if. oh wait. too late. Already
happened.
The real weakness in TLS is the people managing the certs. As a group, we
suck at it. A couple assignments back I worked for a client who are a fund
manager and who have among the tightest security of all customers I've ever
assessed. Even this company were creating the private keys in one place,
them moving them out to the hosts where they would be used. Another company
I worked with had set up an internal CA. This is a very large consumer
lending company. Their CA did not assure unique DNs or serials, did not use
intermediate signers, and was on some guy's laptop which left the building.
Thanks to the CA Browser forum rules changing you can't have a CN=QMGRNAME
anymore and there's been a migration to self-signed certs. I have now had
two customers where I found them trusting self-signed certs that were
configured as root signers, and I expect this problem to grow for years
before it gets better.
With TLS and SSL you need only the signer of the remote node but with SMIME,
WMQ AMS, PGP and any scheme where you encrypt data at rest for a remote
recipient, you need their signer chain *and* their personal public key. As
more and more people begin to use these technologies, and as more and more
of them use self-signed certs, many more self-signed effective-root certs
will be lurking about in trust stores and KDBs. At that point the person
holding that cert can impersonate any other for SSL, TLS and signed
messages. Fortunately, for encrypted messages the public and private keys
can't be MITM'ed.
And as long as we have our tinfoil hats on, consider that a giant data
facility with yottabytes of storage probably doesn't exist to escrow the
world's traffic until it can be decrypted, as many have postulated. As a
rule, nobody attacks the protocol itself. It is so ingrained in security
folks that we not only don't defend against that, we don't generally
consider attacking the protocol as a valid approach. In particular, the
keyspace for RSA is so huge that brute force attacks are impossible and
computational attacks are infeasible. BUT if you could introduce subtle
weaknesses in pseudo random number generators, the effective keyspace could
be shrunk to a fraction of the possible space. The symptoms would include
many duplicate public keys in a system where that is statistically
impossible, but hell, nobody over looks at those. Until last year, that is,
when researchers scanned the internet and found a startlingly high rate of
dupe keys in use. And there were those pesky unconfirmed reports of the NSA
influencing the code base of certain open-source libraries. If in fact it
were possible to shrink the keyspace, a couple of yottabytes would be the
right size for the world's biggest rainbow table which, if you had such a
thing, would allow you to see all the traffic of even self-signed certs in
the clear in real time.
I would think the nefarious actors would generate a non-standard key size to
try to keep out of the rainbow table, then use something like Pidgin with
Perfect Forward Secrecy implemented rather than any commercial product. And
if they were worried about MITM, they'd use something like AMS or SMIME
which mitigates interception. WMQ AMS fits the bill in that respect but is
relatively untested compared to HTTP and other traditionally Internet-facing
servers. Furthermore, the product itself is still in transition from
open-by-default to secure-by-default and has a long way to go. (For
example, see my previous email about how the ability to use TLS connections
from MFT Explorer disappeared and nobody - either customer or lab - seems to
have noticed.) Nefarious actors would probably prefer to use something
which has been hammered on from a security perspective, which has a proven
effective secure-by-default posture, mature tools for penetration testing,
and a known secure baseline configuration. WMQ has a way to go on these as
well. When it does the issues with users not managing it correctly will be
mitigated to a great extent but they will remain the weak link.
-- T.Rob
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Meekin, Paul
Sent: Monday, September 16, 2013 3:55 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: NSA stuff and MQ
Well it's Monday morning and summer is definitely over [where I am] so I
thought I'd throw this one out there.
What do people think - is MQ compromised by NSA backdoors? Is it the sort of
thing they'd be interested in? If not, would it be a good way for the more
nefarious elements to communicate with each other?
_____
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