HTTP security solutions

When using HTTP-based message protocols – AS2, secure file, ebXML, web services, Rosettanet – security considerations are similar to hosting a web server. There are industry-standard solutions to make this type of communication secure. Solutions recommended for Activator are described in the following topics.

• HTTP (embedded) server
• External staged HTTP server

HTTP (embedded) server

You can configure Activator to accept incoming HTTP connections directly from trading partners by adding an inbound delivery exchange that uses the embedded HTTP server. The following is a list of safety options to use in conjunction with the embedded server. The options are numbered from lowest to highest security.

Option 1. Message-level security

It is safe to allow inbound connections directly to the embedded HTTP server if your message validation rules require messages (payloads) to be signed and encrypted (the default). This is true even if Activator is running on a machine within your protected network, because the embedded server rejects any message that was not signed with the partner’s private key.

This level of security is sufficient for most applications.

Advantage: High level of security with minimal per-partner maintenance overhead.

Disadvantage: Does not protect against denial-of-service attacks.

Option 2. Firewall filtering

An additional level of security can be achieved by configuring rules on your firewall to allow only inbound connections from known-partner IP addresses. You also can allow connections only to designated ports (for example, 4080 and 1443).

This level of security, in combination with requiring signed and encrypted payloads, is very high and should be sufficient for virtually all applications.

Advantage: Protects against denial-of-service attacks.

Disadvantage: IP address filtering requires updating firewall rules when a partner is added or removed.

Option 3. SSL

If receiving any unencrypted messages, you should require your partners to connect using HTTPS (SSL) so no one on the Internet can eavesdrop on the contents.

Advantage: Eavesdroppers are thwarted even if messages are not encrypted.

Disadvantage: Extra CPU load introduced by SSL (but see option 5). The user cannot configure the encryption algorithm for HTTPS. It is better to require message-level security because the encryption algorithms are stronger.

Option 4. Client-authenticated SSL

With SSL, an additional level of security called client authentication can be configured. This option is selected by default when you define an SSL embedded server in Activator. Client authentication requires your partner to present a certificate before the inbound connection can be accepted. This is similar to the concept of requiring payloads to be signed.

If you choose to allow unsigned payloads, it is highly recommended that you require client-authenticated SSL to prevent connections from being accepted from unknown parties.

Advantage: Unwanted connections are refused as early as possible, before any part of the payload is received.

Disadvantage: Within Activator you must maintain a list of trusted SSL client-authentication certificates for each partner. This is in addition to the list of partner certificates you must maintain for encrypting messages and verifying signatures.

Option 5. Hardware SSL

Options 3 and 4 describe SSL and client-authenticated SSL in terms of the embedded HTTPS server. But the best performance and highest security can be achieved with a hardware device in the DMZ to terminate SSL connections.

Your existing load balancer may be able to do this or you may be able to purchase an add-on SSL module. Alternatively, some vendors offer SSL accelerator cards that can be installed in a server to terminate SSL connections.

Advantage: Off-loads CPU-intensive SSL processing from Activator to the hardware device. Connections are refused in the DMZ before they reach Activator. Very high resistance to denial-of-service attacks.

Disadvantage: Requires external hardware device or card. If client-authenticated SSL is used, requires a list of trusted SSL client-authentication certificates to be maintained outside of Activator using software included with your hardware device.

Summary of options

In summary, most users choose one of the following levels of security when employing the embedded HTTP server.

• High security – The default behavior of Activator in requiring payloads to be signed and encrypted affords a very high level of security right out of the box, even if connections are terminated within your private network by the embedded HTTP server. This level employs the security described in option 1.
• High security and denial-of-service resistance – Adding IP and port filtering rules to your firewall prevents connections from being accepted even before the payload has been examined. This level combines the security described in options 1 and 2.
• Maximum security – The highest possible interoperable level of security can be achieved by using firewall rules in combination with client-authenticated SSL, terminated by a hardware device in your DMZ. In this case, payloads do not need to be signed or encrypted, but can be if an additional level of security is desired. This level combines the security described in options 1 and 2 in addition to either option 4 or option 5.

External staged HTTP server

A staged HTTP server usually resides in your DMZ, accepts incoming connections and stages incoming messages to disk. A servlet installed on the external HTTP server allows Activator to poll for inbound files that have been dropped off by partners. Functionally, the interaction of Activator with a staged HTTP server is similar to the way it interacts with an FTP server. Commonly used HTTP servers include Tomcat, WebLogic and WebSphere.

The following topics describe advantages and disadvantages to this transport.

Advantages

1. Some argue that an external HTTP server provides better security than the embedded server. This is because the external server terminates inbound connections from the Internet in the DMZ. It also does not allow any inbound connections all the way through to the protected network, since Activator polls the embedded server for new files.
2. However, the better security argument is more a matter of perception than fact, as state-of-the-art levels of security can be achieved with the embedded HTTP server, as described in HTTP (embedded) server.
2. If Activator is shut down, inbound messages queue on the external server, allowing maintenance to be performed without causing partners to experience connection errors. However, it should be noted that partners generally would employ retries to deal with connection errors.
3. Under peak load conditions messages queue on the external server if Activator is too busy to process them, reducing the chances of partners receiving 503 (busy) errors.

Disadvantages

1. Some argue that staging the files to a file system that is accessible from the DMZ introduces security risks. However, this argument is questionable if the payloads are encrypted. After all, the encryption was good enough when the files were passing through the Internet.
2. Having to poll the external server introduces latency that is not present with the embedded server.
3. Adding an external server increases the total complexity of the system, increasing the number of things that could break or introducing security holes.