NETSRV security considerations

NETSRV can support both secure and non-secure connections. You must meet the following minimum requirements to establish a secure connection:

On the initiating (client/sending) node side, SECURE=YES must be coded on the socket statement that is associated with the listening (server/receiving) NODE.
On the listening (server/receiving) node side:
- A NETSRV or equivalent must exist that can accept secure connections from a remote JES2 node.
- If the listening (server/receiving) node is a JES2 node, you must use the following settings:
  - SECURE=YES on the local node socket that is associated with the NETSRV statement.
  - SECURE=YES on the remote node socket or sockets that the connections will be initiated from.

Note: Meeting the previous requirements ensures that a successful secure connection is established only when started from the initiating (client/sending) node. See Figure 1 for an example of this configuration.

Figure 1. Secure connection from client node

The previous configuration, Figure 1, can initiate a secure connection only when started from node NEWYORK1. To enable a secure transmission, the PORT name/number must match between the local socket on the listening side (WASHDC2) and corresponding remote socket on the sending node (NEWYORK1). Using LOCALTLS allows JES2 to automatically utilize the default port for secure transmission.

To establish a secure connection from either node, the following symmetrical configuration of the sockets at both ends is required:

Each node must have a local NETSRV with the associated socket statement specifying SECURE=YES.
Each node must have a defined socket for the remote node also specifying SECURE=YES.

See Figure 2 for an example of this configuration.

Figure 2. Secure connection from either node

The previous configuration, Figure 2, can initiate a secure connection when started from either side. To enable a secure transmission, the PORT name or number must match between the local socket on the listening side (WASHDC2) and corresponding remote socket on the sending node (NEWYORK1). Using LOCALTLS allows JES2 to automatically utilize the default port for secure transmission.

You can also define a NETSRV that can tolerate both secure and non-secure connections, depending on which sockets are utilized in starting the NETSRV connection. See Figure 3 for an example of this configuration.

Figure 3. Secure and non-secure connections

In Figure 3, if node NEWYORK1 issues a $SN,SOCKET=WASHDC2A request, a secure connection would be established. However, if node NEWYORK1 issues a $SN,SOCKET=WASHDC2B request, a non-secure connection would be established via conventional secure port 2252.