Sterling Commerce

Technical Overview

Connect:Secure Proxy
Table of Contents

2 Introduction

3 Summary of Connect:Secure Proxy Features

4 Details of Core Security Features

4 Authentication
4 Data Integrity
4 Confidentiality
4 Access Control

4 Details of Extended Security Features

4 Session Break
5 Protection Against DOS Attacks
5 Protocol and Control Block Inspection
6 Accept or Reject Incoming Process Steps
6 Post-step Processing
7 Inbound Connection Routing
8 Logging and Diagnostic Capabilities
8 No File Staging in DMZ
8 Minimally-intrusive Implementation

9 Deployment Options

11 How Connect:Secure Proxy and Perimeter

Services Work Together
2 Connect:Secure Proxy Technical Overview

Introduction
More than ever before, securing computing networks and systems is of critical importance to
enterprises of all kinds. Organizations continue to extend their use of the Internet as a key IT
infrastructure component. International, federal, and state legislation has been enacted to increase
the privacy of information electronically transferred within and among enterprises. These trends have
raised investment in the auditing of computer networks, and have formalized perimeter security
requirements for Internet-based file transfers.

For years, organizations have used Connect:Direct® Secure+ in a multi-enterprise (B2B) context. The
typical deployment, however, has been two Connect:Direct servers with point-to-point connections
over a private network or a virtual private network over the Internet.

Now, many Connect:® customers are interested in migrating and adding significant new Connect:
Direct traffic over the Internet and enhancing their notion of assured delivery for such transfers. This
is happening in response to increased overall file transfer traffic as well as a desire to leverage the
Internet’s perceived lower cost as a ubiquitous global data transfer pipe.

The evolution toward leveraging the Internet for business critical file transfer has driven increased
attention to perimeter network security functions. Best practices for security are dictating the use of the
perimeter network as a trusted intermediary to assure communications between external and internal
systems. For file transfer, this has evolved into a collection of perimeter security capabilities for file
transfer application proxy servers. In addition, requirements vary by installation, so a proxy server must
offer flexible configuration options.

Some Connect:Direct installations have implemented a basic proxy capability by deploying a Connect:
Direct server in the perimeter and staging data there. This approach supports the notion of a session
break in the perimeter but adds a security exposure and performance impact through the staging of
data in a less trusted security zone.

To assist customers who desire to grow their Connect:Direct Internet traffic, Sterling Commerce has
introduced a new product called Connect:Secure Proxy which functions as application proxy for the
Connect:Direct protocol. Plans also exist to support other protocols in the future.

The target market for Connect:Secure Proxy is all existing Connect:Direct customers who have
requirements for advanced perimeter protection for Internet-based file transfers. The product is
differentiated from other solutions because of its unique capability to function as a proxy for the
Connect:Direct protocol. Secondarily, it provides a comprehensive collection of proxy services. Finally,
it is designed to be extensible to additional protocols, thereby in the future providing a strategic
perimeter security solution for all Internet file transfers.

The following table summarizes the major features of Connect:Secure Proxy.

©2006. Sterling Commerce, Inc.

Connect:Secure Proxy Technical Overview
Summary of Connect:Secure Proxy Features
Feature
1. Enforce a session break between external and internal
Connect:Direct servers.
2. Authenticate incoming connections using the SSL or TLS
protocol.
3. Insure that no data is staged in the DMZ.
4. Guard against denial-of-service attacks at the network
edge through simultaneous session limits and SSL/TLS
handshake in the perimeter.
5. Inspect and validate the Connect:Direct protocol and
control blocks. Configurable error handling for protocol
violations (terminate the process and log the violation, log
the violation only, or ignore the violation altogether).
6. Does not require inbound holes in the firewall.
7. Allow or disallow encryption algorithms or Connect:Direct
statements for a Connect:Direct session passing through
the proxy server.
8. Perform Netmap checking and optional IP address
checking in the proxy.
9. Optionally perform additional certificate checks by using
the Sterling External Authentication Server (such as
certificate revocation list checking and distinguished name
validation).
10. Support any SSL/TLS encryption algorithms that Connect:
Direct Secure+ supports.
11. Support any data integrity algorithms (signature and
message authentication codes) that Connect:Direct
Secure+ supports.
12. Provides access control to Connect:Secure Proxy
functions and configuration.
13. Optionally initiate post-step processing of files received
by the Snode by invoking a user-supplied script, program,
or Connect:Direct process on the Snode.
14. Routes inbound connections to the correct internal
Snode using either standard (1-to-1) or certificate-based
(dynamic) routing.
3
Benefit
Follows perimeter security best practices by preventing direct communications
between an external and internal application system. Direct connections make
attacks easier.
Helps assure the identity of an external system prior to any connection and
processing with a trusted zone Connect:Direct server.
Follows emerging perimeter security mandates. Provides an alternative to
Connect:Direct customers solutions that today are implemented by deploying a
Connect:Direct server in the perimeter as a proxy.
Helps ensure business continuity of the internal Connect:Direct network.
Helps prevent spoofing and the possibility of hacking of an internal
Connect:Direct server.
Supports firewall best practices where connections are made from zones of greater
security to those with less security.
Helps enforce system-wide security policies for multi-enterprise Connect:Direct
transfers. Examples: 1) the ability to prevent an external Connect:Direct from
issuing a Run Task request to an internal Connect:Direct server, 2) the ability to
require an internal Connect:Direct initiated process to use a specific encryption
algorithm
Provides a first line defense prior to the SSL/TLS handshake and any processing.
Helps mitigate denial of service attacks.
Provides additional post SSL/TLS handshake validation of the credentials
(certificate) submitted by the external Connect:Direct server.
Continuity with existing Connect:Direct Secure+ processes. Minimally-invasive to
existing Connect:Direct systems.
Continuity with existing Connect:Direct Secure+ processes and is minimally-
invasive to existing Connect:Direct systems.
Compromising of the proxy server would compromise the integrity of Connect:
Direct transfers.
Provides enhanced application integration by the internal Connect:Direct server
(allows certain post-processing applications to be centrally configured). Eliminates
the potential security exposure inherent in allowing an external Connect:Direct
server to initiate a Run Task on the internal Connect:Direct server.
Provides a basic alias capability for connecting to internal Connect:Direct servers.
Certificate-based routing routes to a specific internal Connect:Direct based on
the identity of the external Connect: server. The value of this “dynamic routing”
feature is reduced configuration management.
©2006. Sterling Commerce, Inc.
4 Connect:Secure Proxy Technical Overview

Details of Core Security Features

The core security features of Connect:Secure Proxy are described in detail in the following sections.

Authentication
The first level of authentication support available with Connect:Secure Proxy is the Secure+
protocol based on SSL/TLS. During the SSL/TLS handshake, certificates are exchanged between
Connect:Secure Proxy and a Connect:Direct node and handshake messages are validated using
public key cryptography.

If the SSL/TLS handshake is successful, Connect:Secure Proxy can further authenticate the Connect:
Direct node by invoking the Sterling External Authentication Server for additional validation of the
certificate presented during SSL/TLS handshake. Sterling External Authentication Server can perform
CRL checking as well as perform LDAP queries to verify that the user represented by the certificate
exists and is valid. It can also return attribute values from LDAP entries associated with the certificate.

Data Integrity
The SSL/TLS toolkit generates digital signatures during the SSL/TLS handshake and Message
Authentication Codes (MACs) for each buffer transmitted on the communications link. Should a
message be altered in transit, the receiver will detect it through the operation of verifying the
signature or MAC.

In addition, Connect:Secure Proxy will verify the content of control blocks exchanged between the
Connect:Direct Pnode and Snode. Correct field names, lengths and data types are verified. Also
verified is the correct sequence of control blocks that are exchanged, which is the Connect:Direct
protocol itself.

When an invalid control block, field, or protocol exchange is detected, Connect:Secure Proxy can
terminate the connection and log an error message, log a warning message only or simply ignore the
error. The Connect:Secure Proxy administrator determines what action should be taken by Connect:
Secure Proxy in these circumstances.

Confidentiality
Confidentiality of information flowing between Connect:Secure Proxy and Connect:Direct nodes is
provided through encryption by the SSL/TLS support. Information flowing between Connect:Secure
Proxy and the Pnode is encrypted with one SSL/TLS session and set of cryptographic parameters and
the information flowing between Connect:Secure Proxy and the Snode is encrypted with a different
SSL/TLS session and parameters.

Access Control
Connect:Secure Proxy enforces access control to its configuration and functions through the use
of user IDs and passwords. Only authorized users may configure Connect:Secure Proxy or invoke
its functions.

Details of Extended Security Features

This section describes the details of the extended security features of Connect:Secure Proxy.

Session Break
Standard connections between Connect:Direct nodes are point-to-point through a network as depicted
in the following diagram.

©2006. Sterling Commerce, Inc.

Connect:Secure Proxy Technical Overview 5

Internal External

Connect:Direct PNODE Connect:Direct SNODE

In the following figure, Connect:Secure Proxy acts as the secure intermediary between the Pnode and
the Snode. Connect:Secure Proxy maintains a separate, secure connection with the Pnode and with
the Snode. The Pnode first connects to Connect:Secure Proxy and Connect:Secure Proxy validates the
connection. Connect:Secure Proxy then connects to the Snode and the logical connection between the
Pnode and the Snode is established.

DMZ

Connect:Secure
Proxy

External Internal

2
1

PNODE SNODE

Protection Against DOS Attacks

Connect:Secure Proxy protects the internal network from malicious connection attempts. Before
a connection is ever made to the internal network, Connect:Secure Proxy fully authenticates the
incoming connection through SSL/TLS handshaking and optional invocation of Sterling External
Authentication Server to further validate the certificate from the remote Connect:Direct node. In
addition, Connect:Secure Proxy will terminate inbound connections if either the user-configurable
timeout value or the limit on concurrent connections has been reached.

Protocol and Control Block Inspection

In order to further secure connections between the Connect:Direct Pnode and Snode, Connect:Secure
Proxy helps insure that control blocks and data flowing between it and the Connect:Direct nodes flow
according to correct Connect:Direct protocol. If an unrecognized control block is encountered or a
control block that is sent out of sequence, Connect:Secure Proxy will log an error and terminate the
connection if it has been configured to do so.

Also, Connect:Secure Proxy checks each control block it receives to insure that it is indeed a recognized
control block and that it has only correct fields within it. Connect:Secure Proxy will also validate each
field to assure that the data type and length are correct. As with protocol inspection, Connect:Secure
Proxy can be configured to log an error and terminate the connection when an invalid field is detected.

Connect:Secure Proxy validates control blocks by first converting the native control block consisting
of named fields in XDR format into XML. The corresponding XML document is parsed with standard
XML tools using a predefined schema specific to the control block being inspected. The following
figure illustrates this conversion using partial representations of an XDR-format control block and the
corresponding XML and schema definitions.
©2006. Sterling Commerce, Inc.
6 Connect:Secure Proxy Technical Overview

Accept or Reject Incoming Process Steps

Connect:Secure Proxy can be configured to accept or reject Process steps received from the Pnode.
For example, some enterprises have security policies that disallow Run Task statements from being
executed on internal nodes that are initiated by partner enterprises. All four Connect:Direct process
steps can be individually configured to be accepted or rejected by Connect:Secure Proxy.

Post-step Processing
Connect:Secure Proxy has a further capability of “injecting” extra Connect:Direct process statements
into the session with the Snode. The purpose of this feature is to provide a mechanism to execute a
user-provided script, program, or Connect:Direct process to further process the file that has just been
received. Information about the file such as source file name, destination file name, process number,
process name, are copied to a temporary file on the Snode for use by the user script, program or
Connect:Direct process.

Numerous variables are available to make each invocation of this mechanism unique by substituting
values into the Process steps that are injected into the Snode session. Examples of variables are file
name, path, extension, time, date, process name, process number and so forth.

The following figure shows the message flow to insert these extra process steps into the Snode stream.

External DMZ Internal

PNODE1 Connect:Secure Proxy SNODE1

1 Copy Data

2 Exchange CTRs
1

Inject copy to transmit meta-information 3

Inject Run Task, Run Job, or

Submit within Process to file 4

Next Process step 5

©2006. Sterling Commerce, Inc.

Connect:Secure Proxy Technical Overview 7

Step Description
1 The Pnode sends a file to the Snode.
2 Copy Termination Records are exchanged.
3 Connect:Secure Proxy injects a Copy statement to transmit meta-information about the data
file just transferred.
4 Connect:Secure Proxy injects either a Run Task, Run Job or a Submit-within-Process
statement to trigger further processing of the file.
5 Execution proceeds with the next Process step from the Pnode.

Inbound Connection Routing

There are two ways to route incoming connections from external Connect:Direct nodes to the correct
internal Connect:Direct node: standard routing and certificate-based routing.

With standard routing, an individual Connect:Secure Proxy adapter is configured for each internal
Connect:Direct node to be contacted from external nodes. Incoming connection requests are routed to
this single internal Snode. The following figure illustrates this.

External Proxy Network

1 Connect:Secure
Proxy

Pnode
Name

Connect:Direct 3
PNODE A 2

Netmap
Connect:Direct
SNODE 1

Step Description
1 The PNODE passes its Connect:Direct node name in the initial control block.
2 Connect:Secure Proxy looks for a matching entry in its Netmap.
3 If the Pnode is defined in the Netmap, Connect:Secure Proxy uses the connection
information configured in the adapter to connect to the Snode.

With certificate-based routing, the target Connect:Direct Snode is selected based on the certificate
presented by the Pnode.

©2006. Sterling Commerce, Inc.

8 Connect:Secure Proxy Technical Overview

External Proxy Network

1 Connect:Secure
Proxy

Subject: A
DN: A
Connect:Direct 7 Connect:Direct
PNODE A 6 SNODE 1

2 5

Netmap

Connect:Direct
SNODE 2

3 4
Routing Name:
R_SNODE2 DN: A

LDAP

Step Description
1 The PNODE passes a certificate during an SSL/TLS session. This certificate includes subject
and distinguished name (DN).
2 Connect:Secure Proxy sends a Certificate Validation Request along with the certificate from
the Pnode to Sterling External Authentication Server. The request also specifies that Sterling
External Authentication Server return routing names associated with the certificate user and
possibly other attributes as well.
3 Sterling External Authentication Server attempts to match the query attributes on the LDAP
server and requests that LDAP return the routing names and other attribute values.
4 LDAP returns the query results to Sterling External Authentication Server.
5 Sterling External Authentication Server passes the return attribute values to
Connect:Secure Proxy.
6 Connect:Secure Proxy finds the first Netmap node entry that has a routing name that
matches a routing name in the Sterling External Authentication Server response.
7 Connect:Secure Proxy then routes the PNODE connection to the SNODE defined by the
Netmap entry.

Logging and Diagnostic Capabilities

Through its logging facility, Connect:Secure Proxy can provide diagnostic information in the event of
difficulties with its execution. The logging facility can be set to display information about the messages
exchanged between Connect:Secure Proxy and Connect:Direct. The logging level can also be set to
display all messages including detailed diagnostic messages about program execution.

No File Staging in DMZ

Files transferred between the Connect:Direct Pnode and Snode do not have to be staged in the DMZ
and transferred to the internal network in a separate Copy operation. File data flows directly from one
Connect:Direct to the other through Connect:Secure Proxy without staging of file data. In this way the
confidentiality of data is preserved because it is not accessible in the DMZ.

©2006. Sterling Commerce, Inc.

Connect:Secure Proxy Technical Overview 9

Minimally-intrusive Implementation
Connect:Direct remains virtually unchanged in its configuration and execution characteristics when
it communicates through Connect:Secure Proxy. The configuration changes that are required on a
Connect:Direct node involve the Netmap and Secure+ Parmfile.

Netmap entries must be changed to “point” to Connect:Secure Proxy rather then the ultimate
destination Connect:Direct node. The Secure+ Parmfile must be updated with one or more root
certificates to validate system certificates received from Connect:Secure Proxy during the SSL/TLS
handshake.

Otherwise, Connect:Direct processes, for example, do not have to change, Secure+ cryptographic
algorithms do not have to change, and other aspects of Connect:Direct security do not have to change.

Deployment Options
There are three main ways to deploy Connect:Secure Proxy. The first is to deploy Connect:Secure Proxy
entirely within the DMZ. In this scenario, Perimeter Services executes in “local mode” as part of the
entire Connect:Secure Proxy environment. For more information about Perimeter Services, please see
the later section which describes Perimeter Services and how it works with Connect:Secure Proxy.

External DMZ Internal

PNODE 1 SNODE 1
Perimeter Perimeter
Services Services

PNODE 2 SNODE 2

Connect:Secure Proxy

PNODE 3 SNODE 3

©2006. Sterling Commerce, Inc.

10 Connect:Secure Proxy Technical Overview

The second deployment option is to deploy Perimeter Services within the DMZ and Connect:Secure
Proxy with a local implementation of Perimeter Services within the internal network. This deployment
isolates the Connect:Secure Proxy database and other configuration information from the DMZ.
It also eliminates the need to open extra ports in the internal firewall to access Sterling External
Authentication Server and LDAP servers.

External DMZ Internal

Perimeter
PNODE 1 SNODE 1
Services Perimeter
Services

SNODE 2
PNODE 2
Connect:Secure
Proxy

PNODE 3 SNODE 3

The third deployment option is to deploy the external instance of Perimeter Services in the outermost
secure zone or DMZ. Connect:Secure Proxy itself is deployed in the second (more trusted) DMZ and the
internal instance of Perimeter Services is deployed within the internal network itself. This configuration
provides the greatest security against unauthenticated connections reaching the internal network.

External DMZ 1 DMZ 2 Internal

PNODE 1 SNODE 1

PNODE 2 SNODE 2
Perimeter Connect:Secure Perimeter
Server 1 Proxy Server 2

PNODE 3 SNODE 3

©2006. Sterling Commerce, Inc.

Connect:Secure Proxy Technical Overview 11

How Connect:Secure Proxy and Perimeter Services Work Together

Perimeter Services is a technology which allows multiple communication sessions to traverse a firewall.
Perimeter Services accomplishes this by listening for and initiating communications on a remote
machine and then multiplexes the sessions together in a single communications session between it and
Connect:Secure Proxy. The multiplex connection is always initiated by the element in the more trusted
zone, allowing the communication to take place with only an outgoing port opened in the firewall.

In terms of essential function, there is a similarity between Connect:Secure Proxy and Perimeter
Services. Both create a session break between two communicating entities. But in reality, Connect:
Secure Proxy and Perimeter Services complement each other to help provide the full capabilities of
Connect:Secure Proxy.

Connect:Secure Proxy uses Perimeter Services for the following reasons:

1. Perimeter Services enables the various deployment options described previously.
2. A permanent connection between the internal network and Perimeter Server is only made from the
internal network. Perimeter Server never connects to the internal network. Each time an inbound
connection from an external Connect:Direct node is received, Perimeter Server requests a new
connection from the internal network over the permanent control channel. This new connection is
used to transfer information from and to the external Connect:Direct node.
3. Only a single (outbound) port must be opened in the firewall protecting the internal network.

The following figure taken from the Perimeter Services Technical Overview shows the architecture of
Perimeter Services.

With regard to Connect:Secure Proxy, the “Counterparties” in the diagram represent remote Connect:
Direct nodes and the adapters represent instances of Connect:Secure Proxy.

Counterparty
Host U1

FTP Adapter

Perimeter
Counterparty
Perimeter Server Services
Host U2
Framework HTTP Adapter

Connect:Direct
Counterparty Adapter
Host U3

Process

Gentran Integration Suite secure JVM

Counterparty
Host U4

Bridging
Network

Firewall Bridge Firewall Bridge

Front Back

Untrusted Network Demilitarized Zone Trusted Network

©2006. Sterling Commerce, Inc.

www.sterlingcommerce.com
inquiry@stercomm.com
Connect:Secure Proxy Technical Overview 12

Sterling Commerce Offices

in the Americas:
About Sterling Commerce
United States – Dublin, Ohio For over 30 years, Sterling Commerce has demonstrated leadership and expertise in extending
Corporate Headquarters
Phone +1 614 793 4041 processes beyond the edge of the enterprise to enable visible business with suppliers, customers,
Toll-Free +1 800 299 4031 partners and employees. A subsidiary of AT&T Inc. (NYSE:T), the company is one of the world’s largest
Brazil – São Paulo providers of multi-enterprise collaboration solutions. With more than 29,000 customers worldwide,
Phone +55 11 5508 3700 Sterling Commerce builds collaborative, multi-enterprise communities for customers in the retail,
Canada – Toronto consumer packaged goods, manufacturing, financial services, healthcare and telecommunications
Phone +1 416 756 3000 industries. For detailed, up-to-date information on Sterling Commerce and its solutions, visit
Mexico – Mexico City www.sterlingcommerce.com
Phone +52 55 9171 1786

Europe:

France – Paris
Phone +33 1 55 23 60 00

Germany – Düsseldorf
Phone +49 211 43848-0

Italy – Milan
Phone +39 02 3030 221

Netherlands – Amsterdam
Phone +31 20 560 5600

Norway – Oslo
Phone +47 22 99 6123

Sweden – Stockholm
Phone +46 8 622 4100

Spain – Madrid
Phone +34 91 749 80 79

United Kingdom – London

Phone +44 20 8867 8000

Asia Pacific:

Australia – Sydney
Phone +61 2 9966 2500

Japan – Tokyo
Phone +81 3 5408 8500

Singapore
Phone +65 6549 5222

©2005, Sterling Commerce, Inc.

All rights reserved. Sterling Commerce and the Sterling
Commerce logo are trademarks of Sterling Commerce, Inc.
or its affiliated companies.

SC0404 1/06