Securing MWA

Telnet Communication
Using Network Encryption

An Oracle White Paper

Updated May 2016
Contents
Executive Overview ................................................................................................................................................ 1
Introduction ........................................................................................................................................................... 1
How to Setup stunnel for MWA............................................................................................................................... 2
Configuration Considerations for Running stunnel ........................................................................................... 3
Running stunnel as applmgr ............................................................................................................................. 3
Server side setup........................................................................................................................................... 3
Client side SSL setup ..................................................................................................................................... 4
Testing the SSL setup......................................................................................................................................... 7
Creating a Self-signed SSL certificate ................................................................................................................ 7
Securing MWA Telnet Communication using SSH ................................................................................................. 7
SSH Client ........................................................................................................................................................... 8
SSH Server .......................................................................................................................................................... 8
Sample SSH Software .............................................................................................................................................. 8
SSH Mobile Clients .............................................................................................................................................. 8
SSH Servers ........................................................................................................................................................ 8
FIPS 140-2 .............................................................................................................................................................. 8
EXAMPLES .............................................................................................................................................................. 9
Example using SSH with PUTTY clients ................................................................................................................ 9
Securing connection for Smartphone Devices .................................................................................................... 13
Executive Overview
Oracle WMS and Oracle MSCA support connectivity to mobile devices using Telnet connections over TCP/IP,
with security being provided via basic user/password authentication, tied directly to standard Oracle
Applications menu security. Encryption using WEP or other schemes can be used to provide additional
protection of the through-air component of this traffic. However there is no encryption of the payload on the
(wired) network itself and there exists known vulnerabilities in the WEP encryption scheme. This has raised
concerns about security when using this technology.

The SSH (Secure Shell) open standards provide encryption and security of all traffic between the mobile device
and the application. This provides an equivalent security mechanism for Telnet traffic to that provided by
HTTPS. This document describes how to implement such a system.

Please note that this involves non-Oracle components, Oracle makes no warranty as to the effectiveness of this
solution.

Introduction
Oracle’s Warehouse Management and Mobile Supply Chain Applications enable most of the transactions to be
executed using the mobile devices connected by an RF network. Connectivity is provided using Telnet over TCP/IP
between a Telnet mobile client and the Oracle MWA Tenet Server. The user is required to login to the application,
and this then restricts access to a defined set of responsibilities using the standard Oracle Applications menu
security.

The traffic passing through the RF network may be protected using a variety of encryption schemes (such as
WEP2), which provide a level of protection. However, once the Telnet traffic passes beyond the RF network
decryption point it is “in the clear”. This includes the user and password used to sign on. This is analogous to
having no “HTTPS” support in the HTML world. An additional concern is that WEP encryption (including WEP2)
has known vulnerabilities to a concerted intrusion attack.

The result is that people have the potential to access data that travels across the network. When the data
includes sensitive and confidential information (such as logon information), it is desirable to make it
unintelligible to the unauthorized parties. It is also important to ensure that the data has not been modified,
either intentionally or unintentionally, during the transport.

There are various options available to make these wireless data transmissions more secure in both the
directions, from server to client and client to the server. This paper describes two encrypted tunneling
solutions that are highly effective in increasing the security of these data transmissions.

Securing MWA Telnet Communication Using Network Encryption Page 1

How to Setup stunnel for MWA
This section describes how to configure a stunnel SSL encrypted endpoint in front of the unencrypted MWA
server daemon.

stunnel is a daemon program that can be used as either a server or a client endpoint; stunnel ships with Linux
and Solaris and is available for many other Operating systems. See http://www.stunnel.org if you need the
source.

The default setup is as follows for MWA where traffic between the client and the MWA server is unencrypted

Client host Server host

+------------+ mwahost +------------+

| MWA client | -------------> :102000 | MWA server |
+------------+ +------------+

If your mobile telnet client supports SSL, the SSL encrypted setup will look like this:

Client host Server host

+-----------------+ mwahost +-----------------+

| MWA client w/SSL| =====> :11200 | stunnel server |
+-----------------+ +-----------------+
|
v
localhost +------------+
:10200 | MWA server |
+------------+

The stunnel process is running on the same host as the MWA server so the unencrypted traffic between the
stunnel proxy and the MWA server does not go on the network.

The number of MWA servers on a host is configurable and is controlled by the MWA configurations file.

By default the startup script will start 3 MWA servers listening for telnet connections on the following ports:
10200, 10202 and 10204. You can see the port numbers when starting the MWA server(s), for example:

[applmgr@mwahost install]$ ./mwactl.sh start

MWA Telnet Server Release: 1.0.8.4 [December 12th 2002]
MWA Telnet Server Release: 1.0.8.4 [December 12th 2002]
MWA Telnet Server Release: 1.0.8.4 [December 12th 2002]
Created server socket : listening on port 10200
Server startup is successful.
Created server socket : listening on port 10202
Server startup is successful.
Created server socket : listening on port 10204
Server startup is successful.

The default number of servers and their port numbers is reflected in the configuration file examples below.
If your environment has a different number of servers or the portnumbers are different, adjust the
configuration files accordingly.

Page 2 Securing MWA Telnet Communication Using Network Encryption

Configuration Considerations for Running stunnel
The stunnel process can be run as root and started via the system boot scripts, or it can be run as the applmgr
user that runs the MWA server and other EBS processes.

When running as root, stunnel supports changing of the runtime user to another, less privileged user such as
nobody. stunnel will also perform a chroot operation if required.

The choice of user for running stunnel depends on whether the OS administrator or the EBS administrator is
appointed to manage the stunnel server.

Running stunnel as applmgr

Here is how to install, configure and run stunnel as the applmgr OS user, the user that owns and runs the EBS
code on the application tier.

It is assumed that stunnel is provided by an OS package and is on the PATH of the applmgr OS user.

Server side setup

Similar to any other SSL enabled server, the stunnel server will have to be configured with a private key and a
signed certificate. If the server already has a SSL/HTTPS enabled web server, you can use the web servers
key and certificate for the stunnel process.

If you wish to use a self-signed certificate see "Creating a self-signed certificate" later in this document.

In this case we will create an stunnel directory in applmgr's home directory and use that to hold the required
files (certificate file, configuration file and the runtime pid and log file).

$ umask 077
$ mkdir ~/stunnel

Copy the key and the certificate files to this directory.

$ cp key.pem cert.pem > ~/stunnel/

Concatenate the key and certificate into a single file as per stunnel requirement.

$ cd ~/stunnel
$ cat key.pem cert.pem > stunnel.pem

Create the stunnel config file for the MWA host.

$ pwd
/home/applmgr/stunnel

$ cat > mwa.conf <<!

# Sample stunnel configuration file for securing MWA's MSCA (server side)

# Use the next two only during setup/debugging

#foreground = yes
#debug = 7
output = $PWD/stunnel.log

Securing MWA Telnet Communication Using Network Encryption Page 3

pid = $PWD/stunnel.pid

# Provide the full path to your certificate-key pair file

cert = $PWD/stunnel.pem

# Avoid the "weak" ciphers that are enabled by default,

# pick safe ciphers that both client and server SSL
libraries support ciphers = AES256-SHA:AES128-SHA

# Configure our secured MWA server; listen on <port>+1000 ,

forward to <port>
[mwa1]
accept = 11200
connect = localhost:10200

[mwa2]
accept = 11202
connect = localhost:10202

[mwa3]
accept = 11204
connect = localhost:10204
!

Review the config file and fix hostname and port numbers as required.

Start the stunnel process:

$ stunnel /home/applmgr/stunnel/mwa.conf

and we're done with the server side (except for integration with the MWA start/stop scripts).

Client side SSL setup

Now that the server side accepts SSL encrypted connections, the client must be changed to also use SSL
encrypted connections.

Native SSL Client

Ideally the native terminal emulator on the device will be able to do this with proper configuration. The
client configuration may be as simple as specifying the hostname and encrypted port number and checking a
checkbox that says "Enable SSL."

Page 4 Securing MWA Telnet Communication Using Network Encryption

One example of a client known to work this way is the Wavelink TelnetCE terminal emulator with the
SSL_ARM module.

If you wish to enable verification of the SSL certificate on the client, the certificate must be signed by a
Certificate Authority trusted by the clients SSL library. If you used a self-signed certificate you must import the
cert.pem file into the client's trust-store.

No Native SSL Client

If the native client on the device does not support SSL encrypted connections, an instance of stunnel in client
mode can be launched before the (unencrypted) client. The gist of the configuration is the the client side
stunnel listens on a local port and forwards data to the remote, server side daemon over an encrypted
connection. If the client OS is Windows it may be possible to run stunnel as a Service and thus the tunnel
will be available whenever the device is is running.

The following example configures a linux host with stunnel in client mode, this can be used with a plain-text
telnet client to validate the server side setup.

Client side stunnel setup (no native SSL capable client)

The example assumes a unix user called handheld, and the stunnel files are stored in ~handheld/stunnel.

$ mkdir ~/stunnel
$ cd ~/stunnel

Get the self-signed cert from the server

Securing MWA Telnet Communication Using Network Encryption Page 5

$ scp applmgr@mwahost:stunnel/cert.pem .

Create the stunnel config file for the MWA client

$ pwd
/home/handheld/stunnel

$ umask 77

$ cat > mwa_client.conf << !

# Sample stunnel configuration file for securing MWA
# (client side)

# Use the next two only during setup/debugging (otherwise

check /var/log/secure)
#foreground = yes
#debug = 7
# Provide the full path to your servers certificate file
# (trust it)
CAFile = $PWD/cert.pem
# verify the servers cert
verify = 2

# Path to pid file

pid = $PWD/stunnel.pid

# Enable client mode

client = yes

# Configure our secured MWA client (match portnumbers with

# those on server)

[mwa1]
accept = localhost:10200
connect = mwahost.example.com:11200

[mwa2]
accept = localhost:10202
connect = mwahost.example.com:11202

[mwa3]
accept = localhost:10204
connect = mwahost.example.com:11204
!

Review the config file and fix hostname and port numbers as required.

Start the stunnel process:

$ stunnel /home/handheld/stunnel/mwa_client.conf

Page 6 Securing MWA Telnet Communication Using Network Encryption

Testing the SSL setup
Now the MWA server on MWAHOST:10200 can be accessed encrypted from the client as follows

$ telnet localhost 10200

Creating a Self-signed SSL certificate

This example creates a self-signed certificate (and private key) and saves them to key.pem and cert.pem.

openssl req -new -keyout key.pem -nodes -x509 -days 365 -out cert.pem
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]:Washington
Locality Name (eg, city) [Newbury]:Seattle
Organization Name (eg, company) [My Company Ltd]:Example Inc
Organizational Unit Name (eg, section) []:Example Security Team
Common Name (eg, your name or your server's hostname) []:mwahost.example.com
Email Address []:ssl@example.com

Securing MWA Telnet Communication using SSH

The key components of this solution are an SSH Server, which resides next to the application server and a SSH
Client which resides on the mobile device. Traffic is passed by the Telnet application on the mobile device to
the SSH client also running on the mobile device. This then performs the encryption before sending on the
data out of the mobile device and to the network (RF and wired). The traffic is then received by the SSH
Server which decrypts the data before passing it to the MWA and WMS/MSCA applications. Traffic going in
the other direction is handled in the same way.

The following architecture diagram illustrates this process.

Securing MWA Telnet Communication Using Network Encryption Page 7

SSH Client
This is a client component that resides that on the same telnet client device/machine and uses SSH protocol to
transmit data to SSH Server. As both the Telnet Client and SSH Client reside on the same device/machine, the
communication between these components is not open for eavesdropping and need not be secured. The
primary function of the SSH Client is to acquire the data from the Telnet Client and transmit the same to the
SSH Server through a secured mechanism and vice-versa.

SSH Server
This is the server side component that resides on the same device/machine as the MWA Server. As both the
SSH Server and MWA Server reside on the same device/machine, the communication between these
components is not open for eavesdropping and need not be secured. The primary function of this component
is to acquire the data from the MWA Server and transmit the same to the SSH Client mthrough a secure
mechanism and vice-versa.

The communications between SSH Client and SSH Server will be secured.

SSH (Client) and SSH Deamon (Server) are together a replacement for telnet, rlogin etc and are available on all
the LINUX and UNIX servers by default and require no additional licensing costs. SSH port forwarding is a
feature of ssh where in the normal telnet, ftp, pop3, imap, net8 or any TCP/IP protocols could be routed
thruough ssh secure session. SSH port forwarding would simply forward the incoming connection to the target
port specified (could be Dispatcher or any TCP/IP port).

The only disadvantage is that IP address mapping will not work as all the clients would have to connect to the
same IP address (SSHD Server IP).

Sample SSH Software

SSH Mobile Clients
http://www.dejavusoftware.com/pocketty/
http://www.movsoftware.com/products/sshce/sshce.htm
http://www.pragmasys.com/

SSH Servers
http://www.foxitsoftware.com/wac/server_intro.php
http://www.jfitz.com/tips/ssh_for_windows.html
http://www.bitvise.com/winsshd.html

FIPS 140-2
This approach, while highly secure for most commercial applications, does not conform to all of the
requirements for military applications as defined by the US Department of Defense FIPS 140-2 standards. For
information regarding how to implement this highly stringent level of security, please contact your hardware
provider. The major suppliers of RF equipment for industrial uses have developed FIPS 140-2 compliant
solutions. The following are some references and helpful links.

http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
Symbol Offers Mobile Computing Wireless Security for Government ...

Page 8 Securing MWA Telnet Communication Using Network Encryption

Fortress Technologies - Press Releases
http://www.why-war.com/news/2004/03/22/intermec.html

EXAMPLES
Example using SSH with PUTTY clients
MWA telnet client connection can be made more secured using SSH Port Forwarding. Any telnet client that
support SSH Port forwarding & VT100 Telnet Protocal can be used for this purpose.

The following are the four simple steps to make your MWA telnet client connection secure on a desktop using
PUTTY Telnet Client

Assumption: It is assumed that the server running MWA Telnet Server also supports SSH sessions

Step1 : Specify the SSH Server

Host Name and Port Number
( 22 is the default SSH port).

Securing MWA Telnet Communication Using Network Encryption Page 9

Step 2 : Select Connection -> SSH ->
Tunnels. Specify the port information
Under “Add new forwarded port”. Source
port could anyport on the local host that
will later be used by the Telnet Client to
connect to the MWA Application.
Destination is the actual MWA Telnet
Server Hostname and port in
“host:port” format.

Step 3 :Login to the SSH Session

Page 10 Securing MWA Telnet Communication Using Network Encryption

Step 4 : Launch any telnet Client that
supports VT100 protocol and connect
to the source port on the localhost
specified in Step 2 to make a secure
connection to the MWA Telnet Server

The following screenshots show the various attributes that are configurable on SSH using PUTTY client.

Options controlling
SSH Connections.

Securing MWA Telnet Communication Using Network Encryption Page 11

Form to specify authentication
parameters.

Setting the Workarounds

for the SSH Server bugs.

Page 12 Securing MWA Telnet Communication Using Network Encryption

Securing connection for Smartphone Devices
This is the initial setup page for the Oracle MSCA mobile app.

Please specify the URL with the MWA server and port number (Ex: http://xyz.abc.com:portnumber). For the
MSCA mobile app, please use the port number on which the MWA server is running. If the port is a SSL port,
then the user has to specify https instead of http.

To Start an SSL port on MWA server, please following the steps listed below -

1. A java keystore needs to be created with all the relevant certificates. Typically, this involves series of
steps
a. Create a private key and keystore
(Ex: keytool -genkey -alias <instancename> -keyalg RSA -keysize 2048 -keystore
<instancename>.jks)

b. Create a CSR (Certificate Signing Request)

(Ex: keytool -certreq -alias <instancename>-keyalg RSA -file < instancename>.csr -keystore
<instancename>.jks)
 c. Send the CSR to CA (Certificate Authority) for getting the certificate
d. Install the certificate(s) into keystore created in step a. (Along with the main certificate, you
may also receive additional certificates (Public Primary root CA and Intermediate CA))
(Ex: keytool -import –keystore< instancename>.jks -alias CA_VTN -trustcacerts -file
VTN-PublicPrimary-G5.pem )

2. Copy the java keystore into $MWA_TOP/install/admin directory on MWA server.

3. Uncomment the following lines in $MWA_TOP/install/admin/mwa.cfg
# mwa.Security.SSLSocket=TRUE

# mwa.Security.KeyStore=

# mwa.Security.KeyStorePassword=

# mwa.Security.Protocols=TLSv1

#mwa.Security.CipherSuites=SSL_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_
DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_3DES
_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SH
A

4. Specify the keystore name and password

(Ex: mwa.Security.KeyStore= <instancename>.jks , mwa.Security.KeyStorePassword=changeit)

5. If the java version is 1.7 and above, then set mwa.Security.Protocols to TLSv1.2
(Ex: mwa.Security.Protocols=TLSv1.2)

6. Start the MSCA port

Page 14 Securing MWA Telnet Communication Using Network Encryption

Securing MWA Telnet Communication Using Network Encryption
September 2012, Updated May 2016
Authors: Madhu Punuganti, Erik Graversen
Contributing Authors: Anil Johnson, Puneet Sood, Sulekha Metta

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.

Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com

Oracle Corporation provides the software

that powers the internet.

Oracle is a registered trademark of Oracle Corporation. Various

product and service names referenced herein may be trademarks
of Oracle Corporation. All other product and service names
mentioned may be trademarks of their respective owners.

Copyright © 2016 Oracle Corporation

All rights reserve