WebSphere MQ Security Series, Part 1: SSL basics and configuring SSL in MQ

In the current world, networks have become an indispensable element. It makes it easy and quick to connect the previously inaccessible things. To make full use of the convenience brought by the network, more and more enterprises choose to publish information on the network. E-commerce, Iot, and cloud computing and services are all under planning and implementation. At the same time, the popularization of networks poses a challenge to information security. How to ensure the secure transmission of information in unreliable networks has become a top priority for enterprise IT implementation.

SSL is a Secure Socket Layer that is the most widely used security protocol. It provides a secure channel over TCP/IP to ensure data security in an insecure network environment. It supports various encryption algorithms, digital signatures, and digital certificates to defend against common network attacks. WebSphere MQ has good support for SSL to ensure secure transmission of messages over the network. This article describes in detail how to implement SSL-Based Secure Transmission in MQ based on the introduction of SSL. The examples in this article are mainly based on MQ 7.0.1.9 and will also introduce the changes in the new versions of MQ 7.1 and MQ 7.5.

Network attack types and Countermeasures

The network connects tens of millions of machines, and the environment is complex and changing. Therefore, network attacks are also rare. The impact of attacks on messages can be divided into three types: eavesdropping, tampering, and counterfeiting. These three attack methods undermine the privacy, integrity, and mutual trust of both parties. To address these attacks, SSL provides reliable defense policies.

Eavesdropping and Encryption

Eavesdropping means eavesdropping on others' conversations. On the internet, it means intercepting messages and peeking at the content. Therefore, to avoid listening to messages, you must encrypt the messages. In this way, even if the message is intercepted by attackers, they cannot easily learn the content.

Encryption refers to converting the original message (plaintext) into an unreadable ciphertext for the eavesdroppers according to certain rules (encryption algorithms. Both parties share the encryption rules, so the message receiver can convert the ciphertext to the readable plaintext. A key is a random string and an indispensable element for encryption and decryption. The sender uses the key pair for plaintext encryption, and the receiver uses the key pair for ciphertext decryption.

Both parties can share the same key for encryption and decryption. This is called symmetric encryption or secret key encryption. The advantage of this method is that it is fast, and the disadvantage is that it is difficult to transmit keys securely, especially when there are many communication objects. To securely deliver the key to the contact, you need to meet everyone. To solve this problem, asymmetric encryption or public key encryption occurs. In this way, each communication object has a key pair: public key and private key. The sender uses the recipient's public key for encryption, and the receiver uses its own private key for decryption. Because the public key is public, the key transfer problem is solved. However, it also causes some performance losses. In practical applications, asymmetric encryption is usually used to exchange keys and transmit data using symmetric encryption to avoid key transmission problems and ensure performance.

Encryption is a very important and active research area, with many encryption algorithms. For example, Data Encryption Standard (DES), Triple DES, RC2 and RC4.

Tampering and message Summary

Tampering refers to content intercepted and modified by attackers. Encryption cannot prevent the message from being modified, and the recipient cannot determine whether the message has been modified. Here, the Message Digest technology is used. A message digest is a fixed-length string that represents message features. It has two important features: irreversible and conflict resistance. Irreversible refers to the ability to calculate a message summary from a message, but it is basically impossible to obtain a message from the message summary. Conflict resistance refers to the difficulty of generating two messages with the same summary value. These two features enable the message digest to verify the integrity of the message. The sender uses the Digest algorithm to calculate the message digest and send it to the recipient along with the message. After receiving the message, the receiver calculates the digest Based on the message and compares it with the digest received. If the two are the same, the message is not tampered.

In practical applications, message digests are rarely used independently. They are usually used for digital signatures and message authentication codes (MAC ). The message authentication code is a message digest generated based on the message and key. It verifies the integrity and completes the user verification function to a certain extent. A digital signature is an encrypted message digest.

Counterfeit and digital certificates

Counterfeits are used to impersonate others for communication. The message authentication code can be used to verify the message sender. The digital signature goes further and is non-repudiation. Because digital signatures are message digests encrypted with the sender's private key, they can only be generated by the sender. All this seems perfect. encryption is used to prevent eavesdropping, summarization is used to prevent tampering, digital signatures are used to prevent counterfeiting, and no digital certificates appear to be required. Of course this is not the case. The following attack methods will collapse all the above lines of defense. This is man-in-the-middle attack ). When both parties exchange public keys, attackers intercept the public keys of both parties and send their own keys to both parties. In this way, both parties will use the attacker's key for encryption. In this case, all the encryption and signature are invalid. Details of man-in-the-middle attacks are shown in:

Figure 1. Man-in-the-middle attack

We can see that steps 1st, 2, 3, and 4 are the public key exchange process. In this process, attackers obtain the public key of the sender and receiver, and send their own public key to the communication. Steps 5th, 6, 7, and 8 are the process of sending messages. In this process, both the sender and receiver are encrypted with the attacker's public key, and the attacker intercepts the data and re-uses the public key to encrypt the data. This makes it difficult for both parties to detect the existence of the attacker.

To prevent man-in-the-middle attacks, you need to use a digital certificate. Here, a digital certificate is a certificate authorized by a specialized Certificate Authority (CA), called a CA certificate. The CA certificate binds the certificate owner Information and Public Key together. The Certificate Authority is responsible for verifying the identity information of the certificate applicant. Through a trusted third-party (CA), the communication party can prove to anyone its public key, and others can also verify the authenticity of its certificate through CA, which prevents man-in-the-middle attacks. CA certificates generally contain information such as the owner's public key, owner's private name, CA's private name for issuing the certificate, the date on which the certificate takes effect, and the certificate expiration date.

The self-signed certificate also corresponds to the CA certificate. Self-signed certificates are generally used in testing environments. In the subsequent sections, you will use self-signed certificates to implement SSL-based secure connections.

Back to Top

SSL handshake

SSL connections are implemented in two parts: SSL handshake and data transmission. The former uses the SSL handshake protocol to establish a connection, and the latter uses the record protocol to transmit data. Here, we mainly introduce the SSL handshake process. Handshaking is the process in which the SSL client and the SSL server complete authentication and determine the encryption key used for data transmission. Here, the SSL client is the end of the connection that actively initiates the connection. Do not confuse it with the MQ client. The SSL handshake process is as follows:

1. The SSL client sends a "Hello" message to the SSL server and lists the SSL versions, encryption algorithms, and digest algorithms supported by the client. In practice, encryption algorithms and digest algorithms are combined to form an encryption suite. At the same time, the client also sends a random number to generate an encryption key.
2. The SSL server responds to client connection requests. From the list of cipher suites provided by the client, select the cipher suite to use and generate another random number. At the same time, the server sends its own digital certificate to the client, which contains the authentication information and public key of the server. If the server needs to verify the client, it will also contain a request asking the client to provide a digital certificate in the message.
3. The client receives a response from the server. It first uses the CA certificate to verify the validity of the server certificate. In this process, the client checks the Certificate Signature, certificate authentication path, valid date, certificate status, and so on. After the verification is passed, the Public Key is extracted. The client generates another random number and uses the public key of the server to encrypt it and send it to the server.
4. If the server requires the client to provide a certificate, the client encrypts the random number with the private key and sends the certificate to the server. The server verifies the client certificate and decrypts the random number received by the client using the client's public key.
5. The server and client calculate the shared key for data encryption based on the preceding random number.
6. The client sends the MAC value of all handshake messages to the server, and the server also sends the MAC value of all handshake messages to the client. This is done to prevent attackers from tampering with the message content during the handshake process.
7. The client and the server use the encryption key generated during the handshake to exchange the handshake to end the message. The handshake ends and the SSL connection is established.

After an SSL connection is established, data is transmitted according to the record protocol.

WebSphere mq ssl configuration and management

WebSphere MQ supports Secure Socket protocol (SSL) and Transport Layer Security Protocol (TLS, which is a later version of SSL ). This chapter describes the attributes of the queue manager and the channel related to SSL/TLS. You can use the MQ Resource Manager to set these attributes or use the MQSC command.

MQ and GSKit

MQ supports SSL through the Global Security Kit. It provides the function libraries and tools necessary to implement SSL and is used in many IBM products.

In MQ 7.0 and earlier versions, the backend server is installed independently and the backend server is a private key V7.0. Start from MQ 7.0.1 and start with the introduction of corner stone V8.0 as the optional version. In subsequent versions of MQ, MQ 7.1 and MQ 7.5, the value of corner stone V8.0 completely replaces the value of corner stone 7.0 and becomes the default version and is integrated into the MQ installation package.

Compared with the company's V7.0, the company supports new, safer, hashed algorithm SHA-2, key reset in all Java environments, stricter FIPS authentication, and multilingual error output. For details, see the MQ Information Center documentation.

You can use the same system as the backend V7.0 and backend V8.0. You can use different backend managers to use different backend servers.

In addition, corner stone V8.0 also integrates the GSKCapiCmd command to manage keys, certificate requests, and certificates. You can also use the iKeyman (IBM Key Management) tool to implement the same functionality. Generally, iKeyman can be installed with MQ and has a GUI for ease of use.

Queue Manager attributes

In MQ, you can set SSL attributes, such as the keystore and certificate check information, based on the queue manager. From the MQ Resource Manager, open the "SSL" attribute Panel of the queue manager.

Figure 2. Queue Manager SSL Properties

You can edit this page to specify the location of the keystore for the queue manager. In addition, you can configure the encryption hardware, enter the certificate details, configure the Certificate Revocation check, and modify the OCSP Authentication Settings. In addition to the MQ resource manager, you can also use the MQSC command to edit these attributes.

Keystore (Queue Manager attribute: SSLKEYR): MQ stores certificates in the keystore. You can specify the keystore path here. Note that the path contains the name of the keystore, but does not contain the file extension.

Undo Name List (Queue Manager attribute: SSLCRLNL): For CA certificates, you can set the Undo name list. This list specifies the name of the revocation name list, which can contain a mixture of one or two types of authentication information objects: crl ldap authentication information objects, they store the connection information of the LDAP server that contains the Certificate Revocation List (CRL), the Online Certificate Status Protocol (OCSP) authentication information object, and the connection information of the OCSP Response Program. Based on this list, the queue manager can check whether the certificate of the remote connection is valid. This feature does not exist for self-signed certificates. This is why self-signed certificates are not recommended in the production environment.

Encryption hardware (Queue Manager attribute: SSLCRYP): to configure the encryption hardware, click Configure... in the "encryption hardware Settings" dialog box, and then enter the details of your encryption hardware.

SSL reset count (Queue Manager attribute: SSLRKEYC): number of unencrypted bytes sent and received during the SSL conversation before the key is re-negotiated, ranging from 0 to 999999999. Zero value indicates that the key will never be re-negotiated. If the value of this attribute is greater than 0 and the pulsating signal interval attribute value of the channel attribute is greater than 0, the key must be re-negotiated before sending or receiving message data after the pulsating signal of the channel.

Ssl fips is required (Queue Manager attribute: SSLFIPS): To specify that only FIPS-certified cryptographic algorithms can be used, select YES. to specify whether any cryptographic algorithms can be used, select No. FIPS stands for Federal Information Processing Standards and is a set of Standards that describe File Processing, encryption algorithms, and other Information technology Standards.

OCSP authentication: indicates the connection result when an "unknown" response is received from the OCSP call. If it is set to "required", MQ rejects the connection. If this parameter is set to "optional", the connection is successful. If this parameter is set to "warning", the connection is also allowed. MQ publishes a message of the AMQ9717 type to the error log. This setting does not have the corresponding Queue Manager attribute, but you can set the OCSPAuthentication attribute to implement the same function. For the queue manager, this attribute is stored in the SSL region of the file qm. ini or the Windows registry.

OCSP check Extension: This setting controls whether to use the details of the OCSP server in the AuthorityInfoAccess certificate Extension to perform the digital certificate revocation check. This attribute is OCSPCheckExtensions and is also saved in the queue manager configuration file or registry.

Ssl http Proxy name: it is the host name or network address of the HTTP Proxy Server. The HTTP Proxy server will be used for OCSP check by corner stone. You can select the port number enclosed in parentheses after the address. If no port is specified, the default HTTP port (80) is used ). The corresponding attribute in the MQ configuration file is SSLHTTPProxyName.

Strict Basic Constraint certificate verification: "strict"-level basic constraint certificate verification settings specify whether an intermediate CA certificate is required and whether the isCA flag must be included in BasicConstraints.

Standby activeit: WebSphere MQ provides SSL and TLS functions using the GSKit. You can download the enhanced version of the professional. If you want to use the downloaded version of this function, set this field to "yes ". In MQ 7.1 and the updated version, the default value is corner 8.0. Therefore, this attribute is deleted.

Channel attributes

To successfully establish an SSL connection, you must specify the encryption algorithm and digest algorithm to use. In MQ, the two are generally combined, called CipherSpec. Both ends of the mq ssl channel must use the same CipherSpec to establish a connection. The CipherSpec in MQ can be seen as part of the SSL/TLS cipher suite, which also contains key exchange and authentication algorithms, such as RSA, DH/DSS algorithms. Currently, MQ only supports RSA key exchange and authentication algorithms.

In addition, you can set the Certificate Name (Distinguished Name) to be verified in the channel attribute, and whether the client must provide the certificate.

Figure 3. Channel SSL attributes

This page mainly includes three channel attributes.

SSL CipherSpec (Channel attribute: SSLCIPH): Select The Name Of The CipherSpec used for SSL connection. The two ends of the WebSphere mq ssl channel must have the same value in the CipherSpec attribute. The CipherSepc selected in Figure 2 is DES_SHA_EXPORT, indicating that the encryption algorithm is DES and the Security Hash Algorithm (Summary algorithm) is SHA-1. Because of the weak security of SHA-1 algorithm, in MQ 7.1 and later versions, the support for SHA-2 hashing algorithm is added, and the data security is improved.

Accept only certificates whose private names match these values (Channel attribute: SSLPEER): specify the value of "private name" on the certificate, from the peer queue manager or client at the other end of the channel. When the channel is started, the value of this attribute is compared with the "private name" on this certificate.

Authentication of the initiator (Channel attribute: SSLCAUTH): Specifies whether the channel receives and authenticates the SSL certificate from the SSL client.

So far, SSL-related concepts and MQ settings have been basically introduced. In the next section, we will use an instance to demonstrate how to implement SSL connections step by step.

Use a self-signed certificate to establish an SSL connection from the client to the server

This chapter details how to establish an SSL connection from the MQ client to the server. Here, the client uses the sample program AMQSPUTC and AMQSSSLC and CCDT for connection. The SSL client and the server use self-signed certificates respectively. In addition, a self-signed certificate is generated to act as a CA, which helps readers understand the process of CA certificate application and receipt.

Prepare the certificate on the queue manager

1. Create the certificate library key. kdb to be used by the queue manager.
2. Generate a self-signed certificate SIGNERCA to simulate the CA signing process.
3. Export the public key file signerca. cer of the certificate generated in step 2 for use by the client.
4. Create a certificate request for ibmwebspheremqqmssl. The file is qmgrcertreq. arm. The naming rule for the certificate label is the string "ibmwebspheremq" plus the lower-case Queue Manager name.
5. Use the signed certificate generated in step 2 to sign the certificate request generated in Step 4 to generate the signed certificate qmgrcert. arm.
6. Receive the signed certificate qmgrcert. arm.
7. Copy the signerca. cer certificate generated in step 3 to the client machine.
8. Add the public key certificate generated by the client to the certificate store.

The command is as follows:

List 1. Queue Manager certificate generation command

 runmqckm -keydb -create -db key.kdb -pw password  -type cms -expire 365 – stash  runmqckm -cert -create -db key.kdb -pw password  -label SIGNERCA -dn "CN=SIGNER,O=IBM,OU=AIM,C=CN" -size 1024        runmqckm -cert -extract -db key.kdb -pw password  -label SIGNERCA -target signerca.cer       runmqckm -certreq -create -db key.kdb -pw password  -label ibmwebspheremqqmssl -dn "CN=QMSSL,O=IBM,OU=AIM,C=CN"   -size 1024 -file qmgrcertreq.arm  runmqckm -cert -sign -file qmgrcertreq.arm -db key.kdb  -pw password -label SIGNERCA -target qmgrcert.arm -format binary -expire 300         runmqckm -cert -receive -file qmgrcert.arm -db key.kdb  -pw password -format binary         runmqckm -cert -add -db key.kdb -pw password -label  ibmwebspheremqxinpozh -file client.cer

MQ client certificate preparation

1. Create the certificate library key. kdb to be used by the client. If the client does not have a certificate management tool, you can create a certificate and certificate library on another machine, and then copy it to the machine on which the MQ client runs.
2. Create the client's self-signed certificate ibmwebspheremqxinpozh. The name of the client self-signed certificate is the string "ibmwebspheremq" with the username of the client program running in lowercase.
3. Export the Public Key Certificate client. cer of the certificate and copy it to the server.
4. Add the certificate signerca. cer generated on the server to the certificate store.

The command is as follows:

List 2. client certificate generation command

 runmqckm -keydb -create -db key.kdb -pw password -type  cms -expire 365 – stash runmqckm -cert -create -db key.kdb -pw password -label  ibmwebspheremqxinpozh-dn "CN=Client,O=IBM,OU=AIM,C=CN" -size 1024  runmqckm -cert -extract -db key.kdb -pw password -label   ibmwebspheremqxinpozh -target client.cer   runmqckm -cert -add -db key.kdb -pw password   -label SIGNERCA -file signerca.cer

Establish a connection from the client to the queue manager

There are multiple methods to establish a connection from the MQ client to the server, such as MQSERVER environment variables, CCDT, or mqclient. ini files. The MQSERVER and mqclient. ini files cannot be used to define an SSL channel. Therefore, to establish a secure connection using SSL or TLS, you can use CCDT or specify the relevant parameters in the MQCONNX function. In this article, use the CCDT table to define the client connection channel. The specific steps are as follows:

1. On the queue manager side, use the MQSC command to define the server connection channel SERVERSSL and the corresponding client connection channel, and define and start the LISTSSL listener. The specific command is as follows: Listing 3. queue manager object definition

    DEFINE CHANNEL(SERVERSSL) CHLTYPE(SVRCONN) TRPTYPE(TCP) SSLCIPH(NULL_SHA) DEFINE LISTENER(LISTSSL) TRPTYPE(TCP) PORT(1433) START LISTENER(LISTSSL)   DEFINE CHANNEL(SERVERSSL) CHLTYPE(CLNTCONN) CONNAME('9.119.129.23(1433)') TRPTYPE(TCP) QMNAME(QMSSL) SSLCIPH(NULL_SHA)

   On Windows and Linux platforms, you can also perform these operations through the MQ Resource Manager.

2. When defining the client channel in step 1, the corresponding CCDT file amqclchlorophyll. TAB is generated at the following locations in the queue manager. For example:

   Windows: C: \ Program Files (x86) \ IBM \ WebSphere MQ \ Qmgrs \ QMSSL \ @ ipcc

   UNIX:/var/mqm/qmgrs/QMSSL/@ ipcc

   Copy the CCDT file to the client and set the environment variables MQCHLLIB and MQCHLTAB. For example, on Windows, the settings are as follows:

   Listing 4. MQCHLLIB and MQCHLTAB settings

    SET MQCHLLIB=C:\var\ccdt     SET MQCHLTAB=AMQCLCHL.TAB

3. Set the environment variable MQSSLKEYR on the client to point to the location of the client certificate library, and check the queue manager attribute SSLKEYR to confirm that it points to the correct location of the certificate library. Listing 5. MQSSLKEYR settings

    SET MQSSLKEYR=C:\var\SSL\key

4. Use the sample program AMQSPUTC or AMQSSSLC to test the SSL connection. For details, see MQ Information Center.

This topic describes how to create a certificate on the client and queue manager, and how to establish a connection between the two. Because the self-signed certificate is used in the example, the client and the server need to exchange public keys. If you use the CA certificate, you can ignore this step. Instead, you only need to install the CA root certificate and their respective CA certificates on the client and server respectively.

Summary

This section describes common network attack types and related encryption, digest, digital signature, and digital certificate technologies. On this basis, the principle and process of establishing an SSL connection are described in detail, and combined with the SSL-related features of MQ, step by step demonstrates how to use a self-signed certificate to establish an SSL connection from the MQ client to the queue manager in the form of an instance