- Standard secure proxy through use of the CONNECT verb
- Make it possible for the proxy to see the entire conversation
- Decrypt the stream
- Emulate the server's identity (man in the middle)
- Self-signed certificates
- Intermediate certificate authority (CA)
- Virtual services
- Downloadable resources
- Related topics
Use SSL with Rational Integration Tester
Part 2. Configure the HTTP proxy server to record and virtualize endpoints
This content is part # of 2 in the series: Use SSL with Rational Integration Tester
This content is part of the series:Use SSL with Rational Integration Tester
Stay tuned for additional content in this series.
IBM® Rational® Integration Tester, included in the IBM® Rational® Test Workbench, makes it possible to do integration testing of highly complex applications. Rational Integration Tester is a desktop solution that helps address the challenges of testing legacy or modern architectures. With it, you can visualize connections and dependencies between services and components, create stubs for services that are unavailable for testing, and automate all aspects of integration testing.
One component of the Rational Integration Tester Platform Pack is an HTTP proxy server that can observe and redirect the interactions that take place between a client application and the system under test. This proxy server can also handle SSL-based traffic so that it can be observed and re-routed in exactly the same way as for plain text communications.
This second in this series of articles on using SSL with Rational Integration Tester, describes how to configure the HTTP proxy server and how to make configuration changes to an application to set up the ability to record and virtualize endpoints that communicate over a secure channel.
Standard secure proxy through use of the CONNECT verb
With standard HTTP proxies, secure communications are established through
the use of the
CONNECT HTTP verb. A client application opens
communication with the proxy and, using this verb, asks the proxy to make
an onward connection to the intended host on its
behalf. Once the onward connection has been established the proxy then
relays traffic between the client and the remote server.
As shown in Figure 1, the proxy makes the connection and makes it possible for the two parties to carry out the normal SSL handshake and subsequent conversation with each other by relaying the streams of data between the two parties.
Figure 1. Standard proxy through use of the CONNECT verb
A standard proxy has no key material or knowledge of what the subsequent interactions between the client and the server are. The data is considered to be opaque and can even be non-HTTP traffic.
Part One of this series explains that a trust relationship has to be configured in the client, and can optionally be configured within the server.
Make it possible for the proxy to see the entire conversation
To support virtualization, the Rational Integration Tester proxy needs to
be able to record and reroute traffic. To do so, it needs to be able to
analyze the entire conversation and not just the initial
CONNECT request. This can be done using one of two
- Decrypt the stream
- Emulate the server's identity, known as man in the middle
Decrypt the stream
It is possible to decrypt the stream if you can get the symmetric key (based on the master-secret) used for the session. In the majority of SSL-based servers, this key is exchanged using the Rivest-Shamir-Adleman (RSA) algorithm, in which the key is derived from the pre-master-secret, which the client has encrypted with the server's public key. Using this knowledge of the algorithm, you only require access to the server's private key and the encrypted data to repeat the same steps to decrypt the data.
In a test situation, access to systems might be more relaxed than in a production setting. However, in most other situations, the goal is to protect a private key by using asymmetric keys. This concept is enforced by applications and operating systems that add constraints such as marking them as non-exportable. These constraints prevent easy access to the material.
Even if you have access to the servers' key material, you still might not have access to the symmetric key. Within SSL there are different algorithms you can use to generate and exchange the symmetric key. One of these, Diffie-Hellman, ensures that subsequent access to, and usage of, the private key does not result in the ability to access the symmetric key used.
The second approach is to act as a man in the middle. This is where the proxy emulates the server's identity before it forwards any subsequent interactions.
Emulate the server's identity (man in the middle)
With this approach, the Rational Integration Tester proxy handles the
secure connection and, as part of the SSL handshake, presents the client
application with a certificate that describes the proxy as being the
intended server (whose address is expressed in the
CONNECT request), as shown in Figure 2.
Figure 2. Rational Integration Tester HTTPS proxy
The certificate that is presented to the client is generated by the proxy and represents the endpoint that the client intends to connect to. As described in the first part of this article, the certificate needs to be accepted by the client application and therefore, the certificate needs to be signed by an appropriately trusted certificate authority.
The key material that represents this certificate authority can be obtained from various sources as described in the following sections. It is configured in the registration.xml file that is installed with the proxy server.
The simplest approach is to use a self-signed certificate because it creates a single, independent certificate authority whose purpose is to support the test activities. You can create a self-signed certificate with a number of different products or tools but for simplicity, the proxy ships with a certificate and key pair and is by default configured to use these.
Although the default key and certificate that are supplied are fine to use,
you might prefer to generate a new key and certificate for additional
security. As an example, you can use OpenSSL, which assumes that the
demoCA area of the OpenSSL installation is set up correctly. The
CA.pl script installed with OpenSSL can help with this.
First, as shown in Listing 1, create a private key and a certificate request. Enter an appropriate passphrase when asked.
Listing 1. Create a private key and certificate request
>openssl req -new -keyout proxy.key.pem -out proxy.req.pem -subj "/CN=HTTPS-PROXY-FOR-TESTING/O=My Org/ST=State/C=UK" Generating a 1024 bit RSA private key ..........++++++ .++++++ writing new private key to 'proxy.key.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase:
In this example, the subject (specifically the common name) clearly indicates that this certificate is used as part of the proxy approach. The certificate, key, and password are all present within the installed configuration of the proxy server.
Use the request to generate a self-signed certificate.
Note: Include a
v3_caextension so that
certificates signed by this one are accepted by client applications.
Again, provide the passphrase when asked, as shown in Listing 2.
Listing 2. Sign the certificate request
>openssl ca -create_serial -out proxy.cert.pem -days 3650 -md sha1 -keyfile proxy.key.pem -selfsign -extensions v3_ca -infiles proxy.req.pem Using configuration from C:\Dev\OpenSSL\bin\openssl.cfg Enter pass phrase for proxy.key.pem: Check that the request matches the signature Signature ok Certificate Details: ... ... X509v3 Basic Constraints: CA:TRUE Certificate is to be certified until Jan 1 12:32:57 2024 GMT (3650 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated
The final use of OpenSSL is to convert the certificate and key pair into a format that can be used by the proxy server, in this case PKCS12, as shown in Listing 3.
Listing 3. Convert the certificate and key pair into an appropriate format
>openssl pkcs12 -export -in proxy.cert.pem -inkey proxy.key.pem -out proxy.p12 -name proxy Enter pass phrase for proxy.key.pem: Enter Export Password: Verifying - Enter Export Password:
At this point, as shown in Listing 4, you can use the output to update the relevant section in the proxy's registration.xml file:
Listing 4. Update the relevant section in the registration.xml file
<https-proxy keyStoreFile="proxy.p12" keyStoreType="pkcs12" keyStoreAlias="proxy" keyStorePassword="password" ... />
Make sure the alias matches the
–name argument and the
password is the value set on the Export Password command used in Listing
Intermediate certificate authority (CA)
If your organization already has a suitable public key infrastructure in place, client applications probably have a trust relationship with the company's CA certificate. In this scenario it is possible to create an intermediate CA for use by the proxy and have this signed by the root CA or by one of its intermediate CAs. The certificate that has been generated needs to be configured for use by the proxy server in the same way as described for the self-signed certificate.
This approach can be beneficial, because it means that there is no need to have an additional certificate added to the trust stores of applications that are to connect through the proxy. However, take care to ensure that the private key is suitably protected.
It's all about the trust
Regardless of how the certificate authority key material is obtained or generated it will be used to sign dynamically generated certificates that will then be presented to connecting client applications. This means that those applications need to trust a potentially large number of certificates, which are consistently changing or they need to trust the certificate authority that signed them and is configured for use within the Rational Integration Tester proxy.
Because each application can be configured differently this article does not cover the specific details. (For more details, see the Configuring Rational Integration Tester Platform Pack section of the information center.) Typically, each application requires changes to command line settings or changes entered through the application's user interface.
When the system under test is configured to require mutual authentication, this requirement of identity and trust also applies to the Rational Integration Tester proxy. In this scenario, the server application needs to trust the proxy. This condition can be satisfied by configuring the proxy with a suitable identity, as shown in Listing 5.
Listing 5. Configure the proxy with a suitable identity
<https-proxy ... outboundKeyStoreFile="greenhat.jks" outboundKeyStorePassword="passphrase"> </https-proxy>
The registration.xml file describes the location of a Java™ key store that contains a private and public key pair that represents the identity of the proxy. This information is used in two ways.
First, it can reference the same resource that is used as part of the signing process. In this case, the server application needs to be updated in the same way as the client application, so that the server also trusts that certificate.
The second way is to provide an identity that has been generated and is already trusted by the server application.
After all of the infrastructure changes are in place, application traffic starts flowing through the proxy server. It is then possible, in Rational Integration Tester, to model an endpoint to interact with. From this artifact, you can record the interactions that take place and use them to create a virtual service.
To set up this model, you need to create a physical transport. The configuration of the transport is used to construct the conditions to use to make routing decisions within the proxy. When the condition is matched, the traffic is rerouted to the stub, rather than to the real server, as shown in Figure 3.
Figure 3. Rational Integration Tester HTTPS proxy routing traffic
Because the virtual service can handle requests that come directly from a real consumer and requests that have been redirected from the proxy, it uses a secure connection that needs to be configured with a suitable key pair, as described in Part One of this series.
Most errors are a result of misconfiguration of the key material used by the proxy. This misconfiguration can occur in both the inbound or outbound settings. The proxy startup is fail fast with many of its configuration settings. Invalid certificates, aliases, and passwords do cause an exception to be raised and stop the proxy from starting, rather than allowing the proxy to start and then fail when an application subsequently connects to it.
java.io.IOException: Keystore was tampered with, or password was incorrect
This error message indicates that the password specified is incorrect and the file containing the key material cannot be opened. Check that the value specified in the registration.xml file matches the one used to protect the file.
java.security.UnrecoverableKeyException: Cannot recover key
This error message typically occurs when the key in the key store is accessed with the wrong password. When it looks for key material in the outbound store, the proxy needs to use the same password for the key as is used for the store.
When you use the Java key tool to create and manage your keys, the key store password is usually the same as the key password. However, if you import keys from a PKCS#12 type key store, the password of the key store can be easily set to a different value.
This article provides an overview of the HTTPS proxy that is part of the IBM Rational Integration Tester Platform Pack. It describes how the proxy provides the ability to record and virtualize endpoints by using the man in the middle approach, which requires that the client, and potentially the server applications need to be configured to trust the certificates that are generated.
- Rational Integration Tester information center
- Stubs made easier with Rational Integration Tester
- Use Rational Integration Tester to test WebSphere MQ test message interactions