Secure Sockets Layer (SSL) concepts
SSL is a protocol that provides privacy and integrity between two
communicating applications using TCP/IP.
The data going back and forth between client and server is encrypted using a symmetric algorithm such as DES or RC4. A public-key algorithm—usually RSA—is used for the exchange of the encryption keys and for digital signatures. The algorithm uses the public key in the server’s digital certificate. With the server’s digital certificate, the client can also verify the server’s identity. Versions 1 and 2 of the SSL protocol provide only server authentication. Version 3 adds client authentication, using both client and server digital certificates.
Secure Sockets Layer (SSL) protocol enables two parties to communicate with privacy and data integrity. The Secure Sockets Layer (SSL) provides an industry standard protocol for transmitting data in a secure manner over an insecure network. SSL defines methods for authentication, data encryption, and message integrity for a reliable transport protocol, usually TCP/IP. SSL uses both asymmetric and symmetric cryptography techniques. Refer to the following web site for a complete description of the SSL protocol: http://wp.netscape.com/eng/ssl3/. An SSL connection is initiated by the caller application, which becomes the SSL client. The responder application becomes the SSL server. Every new SSL session begins with an SSL handshake, as defined by the SSL protocol.
MQ v7 Security, page 19 [29/175].
In any SSL communication path, we must make sure that each side of the
communication channel:
- has a personal certificate, and
- possesses the signing certificate that corresponds to its peer's personal certificate.
Encryption is only one tool that can be used in security, and usually it’s not the encryption that’s the weak point. There’s not much point in encrypting traffic when there’s no authentication of the client or server.
SSL handshake
CipherSpec, SSLCIPH and TRIPLE_DES_SHA_US
The CipherSpec identifies the combination of encryption algorithm and hash
function used by an SSL or TLS connection.
CipherSpec name = TRIPLE_DES_SHA_US ;
Hash Algorithm = SHA ;
Encryption Algorithm = 3DES ;
Encryption bits = 168 ;
Glossary
- CA = certificate authority
- CRL = certificate revocation list
- Cryptographic strength : messages and certificates make use of cryptographic hashes to verify integrity. The two hash types currently in use are MD5 and SHA1 algorithm.
- Keyring = the set of files that hold the certificates and keys used for SSL. The QMgr uses a CMS key database. Things that are based on Java use a Java KeyStore or JKS keyring. The type used by a particular client app depends on the platform the app was written in. The good news is that you can use GSKit to convert one to the other as needed.
- SSL = Secure Socket Layer
The SSL key repository
We use the general term key repository to describe the store for
digital certificates and their associated private keys.
The location of the key repository depends on the platform you are using.
On Windows and UNIX systems the key repository is a key database file. The name of the key database file must have a file extension of .kdb. For example, on UNIX, the default key database file for queue manager QM1 is /var/mqm/qmgrs/QM1/ssl/key.kdb. If MQ is installed in the default location, the equivalent path on Windows is C:\Program Files\IBM\WebSphere MQ\Qmgrs\QM1\ssl\key.kdb.
On Windows and UNIX systems each key database file has an associated password stash file. This file holds encrypted passwords that allow programs to access the key database. The password stash file must be in the same directory and have the same file stem as the key database, and must end with the suffix .sth, for example /var/mqm/qmgrs/QM1/ssl/key.sth
MQ Clients and SSL
Specifying that an MQI channel uses SSL
For an MQI channel to use SSL, the value of the SSLCipherSpec
attribute of the client-connection channel must be the name of a
CipherSpec that is supported by WebSphere MQ on the client platform.
You can define a client-connection channel with a value for this attribute in the following ways :
- When a WebSphere MQ client application issues an MQCONNX call.
- Using a client channel definition table.
One or more entries in a client channel definition table can specify the name of a CipherSpec. For example, if you create an entry by using the DEFINE CHANNEL MQSC command, you can use the SSLCIPH parameter on the command to specify the name of a CipherSpec.
SSLCIPH(string) CipherSpec used on the channel. The maximum length is 32 characters. This parameter is valid on all channel types. The SSLCIPH values must specify the same CipherSpec on both ends of the channel. Accepted values : NULL_MD5, NULL_SHA, RC4_MD5_EXPORT, RC4_MD5_US, RC4_SHA_US, RC2_MD5_EXPORT, DES_SHA_EXPORT, RC4_56_SHA_EXPORT1024, DES_SHA_EXPORT1024, TRIPLE_DES_SHA_US, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, AES_SHA_US, TLS_RSA_WITH_DES_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, FIPS_WITH_DES_CBC_SHA, FIPS_WITH_3DES_EDE_CBC_SHA. - Using Active Directory on Windows.
MQ v7 Clients, page 96 [106/159]; MQ v7 MQSC, page 203 [213/629].
Renegotiating the secret key
During an SSL handshake a ’secret key’ is generated to encrypt data between
the SSL client and SSL server. The key can be renegotiated periodically to
minimize the amount of encrypted data that can be decrypted if the secret key is
discovered. By default, clients do not renegotiate the SSL secret key. You can
make a client renegotiate the key by using the KeyResetCount field in the MQSCO
structure on an MQCONNX call or by using the environment variable MQSSLRESET.
Both these variables can be set to an integer in the range 0 through 999 999
999, representing the number of unencrypted bytes sent and received within an
SSL conversation before the SSL secret key is renegotiated. Specifying a value
of 0 for MQSSLRESET or for KeyResetCount indicates that SSL secret keys are
never renegotiated.
SSL setup how-to
What do we need to setup a SSL-secured client connection to a queue manager ?
T. Rob's checklist(s)
Implementing SSL with self-signed certificates requires the administrator to:
- Create a key database for the client and generate the corresponding certificate.
- Create a key database for the server and generate the corresponding certificate.
- Extract public keys from each of the certificates.
- Import the public key of the client into the server's key database.
- Import the public key of the server into the client's key database.
- Enable SSLCIPH and set SSLCAUTH(REQUIRED) on the channels between the client and server.
- Create a key database for the client and generate a certificate signing request (CSR).
- Create a key database for the server and generate a CSR.
- Submit the CSRs to the CA for authentication and obtain the signed results.
- Import the CA root certificate, if it does not already exist in the trust store of the client or the server.
- Receive the client certificate into the client's key database.
- Receive the server certificate into the server's key database.
- Enable SSLCIPH and set SSLCAUTH(REQUIRED) on the channels between the client and server.
- Set SSLPEER on the server to a string that matches the client certificate.
- Remove all other CA signers from the trust store.
Sam's steps
From 4140
RedPaper chapter 2.
- I. On the client machine in a selected directory do this:
- 1. Create keydb.
- 2. Create the certificate request and send it to CA to sign
- 3. Receive the signed certificate
- 4. Add the CA certificate (assumed you have CA cert)
- II. On the QMgr machine(Server) do this (on Unix directory:
"/var/mqm/qmgrs/QMgrName/ssl):
- 1. Create keydb.
- 2. Create the certificate request and send it to CA to sign
- 3. Receive the signed certificate
- 4. Add the CA certificate (assumed you have CA cert)
- III. Alter qmgr on Qmgrserver for key repository alter qmgr SSLKEYR('/var/mqm/qmgrs/QMgrName/ssl/keydb')
- IV. Create the SVRCONN/ CLNTCONN channels and export the CHLTAB onto the Client Machine. For SSL to implement, the client should use CHLTAB to connect to QMgr and not the SVRCONN channel. Need to install the gskit also.
- V. On both SVRCONN/CLNTCONN, you need to select same Cipherspec.
This is, the iKeyMan toold or "IBM Key Management" icon inside the Websphere MQ folder.
Or use OpenSSL to create a full Root CA and Intermediate CA chain.
Details
The steps we shall follow are :
- Set up a non-SSL WebSphere MQ client.
- Verify the non-SSL client connectivity.
- Set up a one-way SSL channel connection.
One-way means that only the queue manager (in SSL terms, the server) presents a certificate, which the client authenticates. - Convert the SSL connection to two-way, that is, mutual authentication between the client and queue manager.
- Setting up a non-SSL WebSphere MQ client SET GESTOR=SSLQM @echo Create queue manager (%GESTOR%). crtmqm -u SSLQM.DLQ %GESTOR% @echo Start queue manager amqmdain qmgr start %GESTOR% @echo Create listener @echo DEFINE LISTENER('LISTENER.TCP') TRPTYPE(TCP) PORT(33333) CONTROL(QMGR) | runmqsc %GESTOR% @echo def ql(SSLQM.DLQ) | runmqsc %GESTOR% @echo def ql(Q1) | runmqsc %GESTOR% @echo def chl(SSL.CLIENTS) chltype(SVRCONN) | runmqsc %GESTOR% @echo START LISTENER('LISTENER.TCP') | runmqsc %GESTOR%
- Verify the non-SSL client connectivity
- 2.1.- Using WebSphere MQ server set MQSERVER=SSL.CLIENTS/TCP/192.168.1.64(33333) amqsputc Q1 SSLQM amqsgetc Q1 SSLQM
- 2.2.- Using channel tables
- a. Create a client connection channel on the queue manager machine (this creates the channel table).
- b. Transfer the channel table file to the client machine.
- c. Set up the appropriate environment variables on the client machine.
- d. Test the WebSphere MQ client with channel tables.
- (a) enter set mqchl to verify we do not have the channel table environment variables set
- (a) def chl(SSL.CLIENTS) chltype(CLNTCONN) conname('192.168.1.64(33333)') replace | runmqsc SSLQM
- (a) as a result, you see a file called AMQCLCHL.TAB in your queue manager's @ipcc directory
- (b) copy FTP binary the AMQCLCHL.TAB file to the client machine, let's say the directory C:\MQCLIENT\
- (c) set up the environment variables :
- set mqchllib=C:\MQCLIENT
- set mqchltab=AMQCLCHL.TAB
- set mqserver=
- (d) amqsputc Q1 SSLQM
- (d) amqsgetc Q1 SSLQM
- 2.1.- Using WebSphere MQ server
- Set up a one-way SSL channel connection - SSL server authentication
With SSL server authentication, the queue manager must have a certificate,
which it presents to the client, so that the client knows it is connecting to
the right server. This is what happens when you shop online and your URL starts
with https:. The browser asks for a certificate, so you know you are
giving your credit card details to the right company, but the server (the online
shop) does not ask for a certificate from you.
There are a number of ways to obtain a certificate for your queue manager:
- You can create self-signed certificates.
- You can have an in-house certification authority.
- You can request a certificate from a certification authority.
- a. Create a key repository for the queue manager.
- b. Create a self-signed certificate for the queue manager.
- c. Add the certification authority certificate to the client. (The client needs this to decode the queue manager's certificate.)
- d. Test the SSL server authentication.
- (a) On the queue manager machine, open a Windows command prompt and enter strmqikm. This starts the IBM Key Management (iKeyman) GUI.
- (a) Create a key repository for the queue manager :
Select Key Database File -> New.
Select "Key database type" := "CMS" ; "File Name" := "key.kdb" ; "Location" := "<MQdir>\Qmgrs\SSLQM\ssl" ;
Select a password for this key repository.
The password is encrypted and saved into file key.sth. - (b) click "New Self-Signed Certificate" (bottom-right corner)
- (b) fill in the certificate attributes (Key Label must be ibmwebspheremq
followed by the queue manager name in lowercase)
Now the queue manager has a certificate. The queue manager presents this
certificate to the WebSphere MQ client when the client connects. To validate the
queue manager's certificate, the client needs the certification authority (CA)
certificate.
- (c) to extract the CA certificate, click Extract Certificate (bottom-right
corner), and enter filename (sslqm.arm) and directory.
This creates a file called sslqm.arm in
C:\<MQDir>\Qmgrs\SSLQM\ssl\. You now must transfer the CA Certificate file
to the client's key repository.
- (c) Create c:\MQCLIENT\ if it does not exist, and copy (or FTP ASCII) the CA certificate file (sslqm.arm).
- (c) on the client machine, run strmqikm
- (c) create a key repository for the client :
select Key Database File -> New
Select "Key database type" := "CMS" ; "File Name" := "key.kdb" ; "Location" := "C:\MQCLIENT" ;
Select a password for this key repository.
Click Add (top-right corner)
Select "Certificate file name" := "sslqm.arm" ; "Location" := "C:\MQCLIENT\" ; We created a certificate store for the MQ client in C:\MQCLIENT, but we have not told the client where to find it. To do this, set the MQSSLKEYR environment variable
set mqsslkeyr=C:\MQCLIENT\key - (d) Change the client connection and server connection channel definitions
for SSL : echo alter chl(SSL.CLIENTS) chltype(svrconn) sslciph(triple_des_sha_us) sslcauth(optional) | runmqsc SSLQM
The change to the client connection channel updates the channel table (file AMQCLCHL.TAB) in your queue manager's @ipcc directory. Copy the channel table (or FTP binary) to the client directory (C:\MQCLIENT) in the client machine. - (d) Verify connection works : set mq mqchllib=C:\MQCLIENT mqchltab=AMQCLCHL.TAB mqsslkeyr=C:\MQCLIENT\key amqsputc Q1 SSLQM amqsgetc Q1 SSLQMIf the programs run successfully, it means that the client channel works with SSL.
- Convert the SSL connection to two-way
SSL client authentication means that the client has a certificate assigned,
which it presents to the server when the channel starts. To set up client
authentication, we need to perform the following steps:
- a. Create a self-signed certificate for the client.
- b. Add the certification authority certificate to the queue manager.
- c. Change the server connection channel to request client authentication.
- d. Re-test.
- (a) to create a self-signed certificate for the client, on the client
machine, run strmqikm
This is the same as creating a self-signed certificate for the queue manager. The only difference is that we run it from the client machine. - (a) click the Open icon (or select Key Database File -> Open).
- (a) provide the following values : "Key database type" := "CMS" ; "File Name" := "key.kdb" ; "Location" := "C:\MQCLIENT" ; enter the password.
- (a) viewing Personal Certificates, click New Self-Signed Certificate (bottom-right corner).
- (a) fill in the certificate attributes, as "Key Label" := "ibmwebspheremq"
followed by the lowercase user ID.
In our case: ibmwebspheremqemir Now the MQ client has a certificate, which it presents to the queue manager when the client connects. To validate the client's certificate, the queue manager needs the certification authority (CA) certificate.
- (b) click Extract Certificate (bottom-right corner).
Provide "File Name" := <user ID>.arm, in our case: emir.arm; "Location" := "C:\MQCLIENT\" ; Now, you must transfer the CA Certificate file to the queue manager's key repository.
- (b) copy (or FTP ASCII) the CA certificate file (
.arm) from the client's C:\MQCLIENT directory to the queue manager's ssl directory. This is <MQdir>\Qmgrs\SSLQM\ssl. - (b) on the queue manager machine, run strmqikm
- (b) click the Open icon (or select Key Database File -> Open).
Open the key.kdb file in <MQdir>\Qmgrs\SSLQM\ssl. Switch to viewing Signer Certificates. Click Add (top-right corner).
Select "Certificate file name" := <user ID>.arm; "Location" := <MQdir>\Qmgrs\SSLQM\ssl\ ;
Enter a label for the certificate, as the client's user ID ("emir"). - (c) to enable client authentication, the server connection channel must
specify SSLCAUTH(REQUIRED). echo alter chl(SSL.CLIENTS) chltype(svrconn) sslcauth(required) | runmqsc SSLQM
- (d) run set mq mqchllib=C:\MQCLIENT mqchltab=AMQCLCHL.TAB mqsslkeyr=C:\MQCLIENT\key amqsputc Q1 SSLQM amqsgetc Q1 SSLQMIf amqsputc fails with MQCONN ended with reason code 2393 or MQCONN ended with reason code 2059, stop and start the queue manager.
A more detailed list could be :
Mine (untested) :
- MQ Server machine with MQ Server installed and a queue manager
- MQ Client machine with MQ Client installed
- SVRCONN channel definition
- CLNTCONN channel definition => MQCHLTBL moved from MQ Server machine to MQ Client machine
- create a key repository (or key database) on MQ Server machine : runmqckm
- create and distribute the CA certificate
- create the queue manager certificate
- set SSLKEYR on queue manager
- get client certificates and store them into the keystore
- client keystore : /tmp/pkiuser.kdb
- environment variables setup on MQ Client machine :
- MQSSLKEYR - this variable specifies the location of the key repository that holds the user’s digital certificate, in stem format.
aix-client# export MQCHLTAB=AMQCLCHL.TAB aix-client# export MQCHLLIB=/tmp aix-client# export MQSSLKEYR=/tmp/pkiuser
{bestp}
Emir's "gotchas" : impresionant ! MQ SSL common mistakes and
how to avoid them
- CSQX630E Channel requires SSL
- CSQX642E No SSL certificate for channel
- Certificate not signed
- CSQX686E SSL private key error
- CSQX632I SSL certificate has no associated user ID
- Certificate corrupted after FTP to z/OS
- No need to restart the CHINIT
- Key repository not found
- Wrong type of key repository
- CSQX631E/AMQ9631 CipherSpecs do not match
- Corrupted certificates
- Expired certificates
- Duplicate certificate serial numbers
- GSKit GUI and command line differences
- Add or receive?
- AMQ9660 or AMQ9657
- Problems using makecert
- gsk6cmd, gsk7cmd or runmqckm?
- Problems migrating from V5.3 to V6.0 on Windows
- Password not stashed
url.
SSL @ T400
Advice
- delete all the default certificate authorities when you create a new keyring
These cause your client or server to trust any certificate ever issued by Verisign, RSA or Thawte.
\\MQ\Seguridad\T-Rob\SSL\Define_Keyring_and_Delete_Default_CAs.cmd
- test DEFINITELY the reverse cases
- adequate people can connect
- the rest of the people can NOT connect
MO04 - SSL wizard
java –jar wmqsslwizard.jar
Converting between gsk7cmd and gsk7capicmd is pretty easy. You just make sure that the gsk7capi command folder and library folder are both in your PATH and replace all gsk7cmd with the string gsk7capicmd in your scripts. You can then make minor changes to the command line options to include the signing algorithm or enable FIPS mode. Get the manual here.
Maybe we need to convert the commands from MO04 from gsk7cmd to gskcapicmd and specify the signature algorithm as a command line option.
Flecos
Port
sniffer to demo the encryption aspects of MQ. From SSL tutorial.
T42:\\MQ\Eines\SSL_and_Sniffer, T42:\\MQ\Presentacions,
T42:\\MQ\Seguridad
- setmqaut
- dspmqaut
- dmpmqaut
Security, SC34-6079-01
Points to clarify
- are you using self-signed certificates or CA-signed certs ?
Make sure to use one CA or self-signed certs. Discourage mixing these methods or trusting multiple CA's. - if one CA is chosen ...
- carefully consider the certificate distinguished names.
- be prepared to implement CRL functionality. Using a CA without a CRL is strongly NOT advised.
- to sign the certificates, shall we use MD5 algorithm or SHA-1 ?
Strongly steer to SHA-1 and away from MD-5. - what kind of testing are we gonna run ?
Tools
nssl - netcat-like program
with transparent SSL support.
stunnel : allows you to encrypt arbitrary TCP connections inside SSL. Use it for tunnelling any traffic through SSL.
ssldump : SSLv3/TLS network protocol analyzer. Use it for sniffing and decrypting SSL traffic.
OpenSSL : command-line utility, a swiss army knife for encryption protocols. Use it for far more than just generating keys and connecting to SSL servers. Can also act as an ad hoc SSL client :
openssl s_client -connect www.example.com:443
The above lets you connect via SSL to a web server and manually type HTTP
commands just like you can with non-SSL web servers using plain old netcat and
telnet.
nmap : scanner able to identify SSL services (via the “–sV” scan option)
Nessus : scanner that has the capability of checking SSL services on arbitrary ports, and report weak ciphers
Dubtes
- Authentication information objects contain authentication information for LDAP servers that hold Certificate Revocation Lists (CRLs). When transporting SSL-encrypted data, the queue manager accesses the CRLs to authenticate certificates that it receives.
- With that many remote sites, I expect you will use CA-signed certificates. Be sure to e a certificate revocation list in that case.
- RACF - security exit at channel, user by queue/resource
The MCAUSER helps with authorization only. The SSL will provide
authentication. Combine these and you have meaningful security.
Links
- MQ V6, MB
V6, and SSL {4140 RedPaper, by Saida, Emir and Vicente}
- Planning
for SSL on the WebSphere MQ network
- Secure
Sockets Layer Introduction and iKeyman User’s Guide
- SupportPacs
: MH03:
SSL Configuration Checker, MO04:
SSL Wizard.
- Securing connections between WebSphere Application Server and WebSphere MQ :
part
1, part
2.
- Configuring
SSL Connections between (JMS) Clients and MQ (JMS Provider)
- SSL
configuration of the Websphere MQ Java/JMS client
This article shows you how to configure an Secure Sockets Layer (SSL) connection from a Java™/JMS client to an IBM® WebSphere® MQ Queue Manager.
- MD5 is irretrievably broken. It's not quite as bad as not bothering to
implement SSL - but almost. url "ssl
spoofing.
- GSK7
cAPI cmd user's guide
- Testing for
SSL-TLS (OWASP-CM-001)
- MQ
Security in an Enterprise Environment [SG24-6814, T42:\MQ\BOOKS\Security]
- T. Rob :
- Enabling
SSL in an existing MQ cluster
- Emir Garza articles in AIM IC Repository :
- SSL channels on Windows: a step-by-step guide
- Deploying an SSL infrastructure: a guide for z/OS, AIX, Windows
- Wiki
