Socket Overview
TCP/IP is a set of protocols used for communication between different types of computers and networks. TCP/IP refers to two of the protocols in the suite: the Transmission Control Protocol and the Internet Protocol. The User Datagram Protocol (UDP) is a member of the IP suite supported by PRO/5. PRO/5 and VPRO/5 (except VPRO/5 for Netware) support sockets with TCP/IP or UDP protocols.
These protocols utilize sockets to exchange data between machines. The TCP protocol requires that the machines communicate with one another in a reliable, ordered stream. Therefore, all data sent from one side must be received in correct order and acknowledged by the other side. This prevents data from getting dropped or lost. UDP, however, simply sends out the data without requiring that the data be received.
For TCP/IP and UDP socket aliases in PRO/5, bbxname must begin with "N" and realname must be "tcp" for TCP sockets or "udp" for UDP sockets. TCP sockets give an error 2 (EOF) when the socket has been closed; an error 3 (IO error) when the OS-level socket reports an error. Note that a TCP server socket can actually report multiple error 2s (EOFs) because it controls multiple socket connections to client, each of which can be closed independently.
For information about TCP/IP and UDP protocol impacts on PRO/5 commands, see the CLOSE, OPEN, READ and READ RECORD, WRITE and WRITE RECORD verbs, as well as the IND(), KEY() and KEYF() functions.
For syntax guidelines, see Data Server Syntax.
TCP/IP Examples
TCP/IP Client Example
config.bbx:
alias N0 tcp "" NODELAY
alias N1 udp ""
0010 OPEN (1,MODE="host=192.168.1.33,port=12000")"N0"
0020 INPUT "String to send: ",I$
0030 LET I$=I$+$0D0A$; WRITE RECORD(1)I$
0040 GOTO 0020
TCP/IP Server Example
config.bbx:
alias N0 tcp "" NODELAY
alias N1 udp ""
0005 BEGIN
0010 OPEN (1,MODE="port=12000")"N0"
0015 LET IN$=""
0020 READ (1,ERR=0025)X$; PRINT X$; LET IN$=IN$; GOTO 0020
0025 PRINT ERR
0030 PRINT "Connection closed."
0040 GOTO 0020
UDP/IP Example
config.bbx:
alias N0 tcp "" NODELAY
alias N1 udp ""
0010 REM Possible options are
0010: "HOST=","PORT=","REUSEADDR","DONTROUTE","BROADCAST"
0020 LET UDP_CHAN = UNT
0030 LET TIMEOUT = 300
0040 OPEN (UDP_CHAN,MODE="PORT=2048") "N1"
0050 GOSUB PARSE_KEYF
0100 REM 100
0110 LET SIZE=10
0120 GOSUB READ_ACK
0130 LET port$ = STR(NUM(message$))
0200 REM 200
0210 LET key$ = "localhost:" + port$
0220 LET message$ = "GOODBYE "
0230 GOSUB WRITE_ACK
0999 END
1000 REM 1000
1010 PARSE_KEYF:
1020 LET str$ = KEYF(UDP_CHAN)
1030 LET p = POS(";" = str$)
1040 LET ip$ = str$(1,p-1), str$ = str$(p+1)
1050 LET p = POS(";" = str$)
1060 LET port$ = str$(1,p-1), str$ = str$(p+1)
1070 LET host$ = str$
1080 RETURN
SSL Overview
In the release of BBj 4.0 and PRO/5 5.0, BASIS enables developers to encrypt communication between virtually all BASIS products, communicate securely to third party products, and utilize industry-standard encryption technologies.
Why Use SSL?
When data moves between computers, new previously inapplicable risks arise. The medium on which the data travels is susceptible to eavesdropping. A program that communicates sensitive information, either to the file system or to the user's display, then puts the data at risk of compromise. SSL lessens the threat of a malicious attacker gaining access to a customer's sensitive information.
Configuring BBj Components to Use SSL
In BBj, the Enterprise Manager gives the user access to the configuration of the servers susceptible to eavesdropping, including the Filesystem Server, the SQL Engine Server, the PRO/5 5.0 DS Server, the Administration Server, and the Thin Client Server. By connecting to a running server and clicking on the BBjServices node in the configuration tree, one can view the list of servers and their SSL status shown below.
By double-clicking the BBjServices node, a user may configure the SSL status of the servers listed above, which then displays the dialog shown below.
After selecting one of the configurable servers, simply toggle the Use SSL checkbox as shown. After restarting BBjServices, that server only accepts connections from SSL-enabled clients.
Currently, the Thin Client Server allows only one non-SSL server and one SSL server. In the future, Enterprise Manager will support configuring multiple Thin Client Servers of each type.
Several of the servers shown do not have an option to enable SSL. With the exception of the Bridge Server, these servers all listen to connections from localhost only, and are not susceptible to eavesdropping. The Bridge Server does not currently support SSL, but will support it in a future release of BBj.
Configuring the PRO/5 Data Server to Use SSL
In UNIX environments, the only configuration required by the PRO/5 Data Server is to add the command line option -e. For example, the following command runs an encrypted PRO/5 Data Server:
pro5.server -e {other options}
In the Windows NT/2000/XP operating system, configure the NT Data Server by clicking on the PRO/5 Data Server applet in the Windows Control Panel. This displays the dialog shown below. Clicking on the SSL checkbox enables or disables SSL in the NT Data Server.
Secure File Access
To connect from a PRO/5 or BBj program that opens a file on a Data Server with SSL enabled, simply add an ssl option to the data server syntax. For example:
open(channel)"/<fileserver,port=2100,ssl>/u1/data/DATA01"
In BBj, the JDBC driver may also connect to an SSL-enabled SQL Engine Server. To access via the SELECT or SQL verbs, add the option ssl=true to the connect string of all the databases an SSL-enabled SQL Engine serves.
Connecting to an SQL Engine Server from an ODBC driver also requires configuration in order for the connection attempt to succeed. To navigate to the ODBC Data Sources in Windows 2000 and later, go to the Administrative Tools folder. In versions prior to Windows 2000, go to the Control Panel. Click on the appropriate icon, then configure the various data sources in the displayed dialog. To configure a data source that uses the BBj ODBC Driver, select an appropriate data source, then click the Configure button. When the dialog below appears, select the Use SSL checkbox to enable or disable SSL.
The configuration of a client must match the configuration of the server to which it connects. For instance, if a PRO/5 session connects to an SSL-enabled PRO/5 Data Server, the PRO/5 session must specify the ssl mode in the open syntax. If the BBj ODBC driver connects to an SSL-enabled SQL engine, configure the ODBC driver to use SSL.
Secure Thin Client Access
In BBj, the display for an interpreter may appear on a different computer than the one actually running the program. Many times, the data displayed on a user's screen is just as sensitive as the data in a file. For this reason, BASIS also allows SSL connections from the Thin Client to the Thin Client Server. If the secure Thin Client Server is running on the default port (2103), the user may simply add the -SC option to the command line of BBj as follows:
bbj -cconfig.bbx -SC -RHbigiron program1.bbj
The -RH option specifies the remote host to which BBj Thin Client should connect. To connect to a different port, specify the -RP option:
bbj -cconfig.bbx -SC -RHbigiron -RP 3103 program1.bbj
Using SSL in Programs
In addition to allowing users to protect the communications between BASIS components, BASIS provides SSL to the programmer. Using SSL as a client is very straightforward. The following configuration and program examples allow the administrator to test whether the SSL is functioning properly:
Configuration in config.bbx
ALIAS N5 SSL ""
Program
REM ' Open a connection tohttps://www.basis.cloud/
REM ' Standard httpsport is 443
OPEN(1,MODE="HOST=www.basis.cloud,PORT=443")"N5"
REM ' Write the request to the server
write(1)"GET /index.html", $$
REM ' Read server response
while 1
read(1,end=LOOP_DONE)A$
print A$
continue
LOOP_DONE:
break
wend
close(1)
Defining the ALIAS in the config.bbx tells BBj or PRO/5 to open the network channel named N5 using SSL. Specify both the HOST and PORT option in the MODE string on the OPEN when making a client connection to an SSL server. Now the developer can use the open channel exactly as any other channel. This program prints the HTML source for BASIS home page.
Creating an SSL server is slightly more involved. SSL requires the use of certificates to verify to a client that it is connecting to the correct computer. A server may have a certificate that verifies its authenticity. The client verifies that certificate by checking to see if a trusted Certificate Authority (CA) issued the certificate. If a CA owns the signature on the certificate, the client will continue accepting the connection. Otherwise, the client may choose to disallow connecting to that server.
Obtaining a certificate issued by a well-known CA is usually somewhat expensive. If a casual SSL user chooses to forego this step, the server may use a "self-signed" certificate. Keep in mind, the client only validates self-signed server certificates that appear in the client's list of trusted certificates.
When PRO/5 acts as an SSL client, PRO/5 does not verify the server's certificate. The advantage is that clients can connect to servers that use certificates not signed by a CA. However, PRO/5 is vulnerable to a "man in the middle attack" where a computer, pretending to be the server, participates in the SSL key negotiation, decrypts and re-encrypts the data, and forwards the re-encrypted data to the real server. A "man in the middle attack" requires tampering with components such as routers, DNS servers, DHCP servers, and wiring, and is more difficult to accomplish than a packet-sniffing or eavesdropping attack. Future versions of PRO/5 may provide a way to specify a list of trusted certificates.
When PRO/5 acts as an SSL server, it uses a built-in self-signed certificate so there is no need to generate a server certificate for PRO/5. Future versions of PRO/5 may provide a way to specify a user supplied server certificate.
For BBj, the keytool command that ships with the Java SDK provides the requisite functionality to produce the needed keys and certificates. The Java documentation has information to aid one in learning how to use this command. The server requires one keystore that contains a private key, the signed certificate (which may be signed by a CA or self-signed), and the public key. The client requires another keystore that contains the same certificate and public key. This sample command generates a keystore file that contains a self-signed server certificate:
keytool -genkey -dname "o=BBjTest, c=US" -alias test -validity 7000\
-storepass serverpwd -keystore serverks
These three commands generate a client keystore file that includes the server's certificate on a list of trusted certificates for the client:
keytool -export -alias test -storepass serverpwd -keystore serverks\
-file client.cer
keytool -import -alias test -storepass clientpwd -file client.cer\
-keystore clientks
delclient.cer
With the server keystore in place, the following syntax will open a server socket with the given certificate and key:
open(1,MODE="PORT=11000,KEYSTORE=serverks,PASSWORD=serverpwd")"N5"
On the client, similar syntax with a different keystore file (and optionally a different password) will connect to the desired port on the server:
open(1,MODE="HOST=sslserv,PORT=11000,KEYSTORE=clientks,\
PASSWORD=clientpwd")"N5"
With minimal effort, a developer achieves a much higher degree of confidence in the inaccessibility of their data, regardless of the use and location of the clients. The myriad of methods available to developers to tighten security of their communications provides a great deal of flexibility with the structure and design of their application.
Using STARTTLS in Programs (BBj specific)
In addition to SSL capability, BBj 15.0 and higher also allows users to start with an unencrypted connection and later switch the connection to be encrypted using STARTTLS functionality using the CHANOPT() verb. As with SSL, the server is more complicated than the client and while BBj uses a default keystore, the user can specify their own using KEYSTORE and PASSWORD options in CHANOPT. In addition, switching a connection into an encrypted mode clearly only applies to a single connection, by default this is the last connection that server read from. However, the simplest way to just initiate STARTTLS on a connection using the defaults is very easy. CHANOPT(1)”STARTTLS” Customers should be aware that most protocols supporting STARTTLS functionality have some security issues surrounding it and therefore they need to read the protocol documentation carefully for correct usage.