Janus Network Security

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Janus Network Security consists primarily of support for the SSL (Secure Sockets Layer) and the TLS (Transport Layer Security) protocols, which provide secure communications for users of Janus products. The TLS protocol, developed by the IETF Internet standards group, is a more secure extension to SSL. This topic will sometimes use "SSL" loosely to refer to SSL (V2 and V3) and TLS, and it will also use the terms "SSL-like" and "SSL/TLS."

These protocols are most typically used to encrypt and authenticate the communications of Janus Web Server applications. Used by web servers throughout the Internet, SSL and TLS are industry standard approaches to secured communications that enable users to transmit private information, such as credit cards, with the confidence that the encrypted data cannot be intercepted and that the authenticated recipient of the data is the intended one.

Secured communications can be valuable within an organizational intranet as well, protecting the integrity of information transmitted within the network. Even though an intranet protects an organization from attacks by outsiders, it is imprudent to ignore potential attacks by insiders, who may find such information even more valuable than outsiders.

About this topic

This topic introduces the key SSL concepts, and it addresses the use of SSL/TLS to provide secure communications for connections to your Janus Server sites via the Internet or via an organizational intranet, as well as for connections to SSL servers from your Janus Sockets clients. Once Janus Network Security is set up and tested, it operates quietly in the background, and little further effort is required to have fully secured communications.

Generally, Janus Network Security is installed as an addition to Janus Web Server. It is also possible to install it without Janus Web Server (for use with other non-web Janus products). For the sake of simplicity, this topic largely assumes that you will be using Janus Network Security with Janus Web Server.

Janus Network Security documentation

This introductory page provides a technical background for the rest of the Janus Network Security topics, whose pages guide you through the implementation of Janus Network Security at your site:

Notes:

For messages related to Janus Network Security, refer to MSIR. messages.
See the Model 204 release notes for information about Janus Network Security product changes and Model 204 feature support.
Much of the content of the Janus Network Security wiki pages is also reproduced in other HTML pages: The first time you connect to an Online using Janus Network Security, a default home page is displayed. In the introduction on that page, a link ("configure and manage Janus SSL support") leads to pages that restate much of this wiki document.

About SSL

SSL, the Secure Socket Layer, is a communication protocol that makes it possible to safely transmit secure information over a non-secure network. SSL accomplishes this primarily by encrypting communications. It can also enable authentication of the server and/or the client to ensure that each party is who they say the are. These three components are described below.

Encryption

The primary means by which SSL accomplishes safe communications is through encryption of the data that is sent between a client or browser and a server. This encryption makes it practically impossible (or at least extremely difficult) for anyone other than the intended recipient of the data to decrypt it, even if a third party has access to the complete contents of the communication. This is a way of defeating "snooping", the capturing and retrieval of passwords and other sensitive information from data packets transmitted over a network and intended for another machine.

The SSL protocol is typically layered over the TCP protocol and under the HTTP (web) protocol. Information that would normally pass between a web server and browser is encrypted by SSL before being sent over the network via TCP/IP. This means that communications over a public TCP/IP network can be more secure than that over a private VTAM network, because VTAM security depends on the security of the physical network while SSL security is based on mathematics. The cost of this extra security is the CPU processing that SSL requires, especially on the server side.

Authentication

In addition to encryption, SSL also provides "authentication." Authentication means either or both parties (client and server) can be confident that the other is indeed who they say they are.

Authentication of the server

SSL server authentication provides information to the client that can be examined by the end user to verify some basic information about the server.

SSL typically provides the country, state or province, city or town, organization name (Mega Industries, Hard Knocks University, Grand Duchy of Liechtenstein, etc.), organizational unit (Department of Obfuscation, Engineering, MIS, etc.) and a server name (Student Web Server, Parts and Supplies Ordering Server, Sensitive Information Server, etc.).

This authentication defeats "spoofing," the practice of

Setting up a server to intercept messages intended for another server, responding to them in such a way that the end user is convinced he or she is communicating with the correct server.
Capturing sensitive information such as passwords from the end user.

Spoofers sometimes simply pass information through to the correct server and back from the server to the client, recording sensitive information as it passes through. This technique is sometimes known as a "man-in-the-middle attack."

SSL authentication defeats all forms of spoofing, because it is practically impossible (or extremely difficult) for a spoofing server to send the correct SSL authentication information to the client.

Server authentication is enabled by way of certificates. Certificates are digital IDs that verify that a server has been certified by a publicly recognized authority as being who they say they are. A certificate is installed in the server and then recognized by client browsers.

Janus Network Security comes with an initial certificate, provided by Rocket Software specifically for use by your organization (Rocket has certified the organization's identity). You can also arrange to purchase a certificate through widely recognized companies, called Certificate Authorities, if it is important for your users to know that your server's identity has been certified by such an organization.

Authentication of the client

SSL can also provide client authentication. Using techniques like those used for server authentication, it is possible for a server to verify the identity (more or less) of the client with which it is communicating, without the use of a password database on the server.

Janus Network Security supports client certificates, which establish the identity of the client. These are acquired like server certificates and installed on client machines — typically browsers but possibly a Janus SSL CLSOCK machine, for example. Not required by most web servers, these certificates are requested and sent during the initial connection negotiation between client and server, or during a subsequent connection renegotiation.

For more information about Janus support for client certificates, see Verifying a client certificate.

In addition, client authentication of a sort can be achieved by requiring a user to enter a valid userid and password (as defined in the online in which Janus Web Server is running) when connecting to a protected resource.

This optional feature, which can be set for all or for specific applications on a server, is described in Installing and configuring Janus Network Security. Because of SSL/TLS encryption of communications, such passing of userids and passwords over the network is secure.

When should SSL be used?

The obvious answer is whenever secure data is to be transmitted. Unfortunately, a myth has developed around SSL and security in general, that one need only be concerned about it when communicating over the Internet, home of socio-pathic hackers and criminal geniuses whose days are spent trying to wreak havoc and steal information from your system.

Threats from company insiders

The reality is that there is generally more opportunity and motivation to steal information inside a company than outside. Who, after all, is more interested in personnel records than corporate insiders? Who is more interested in the personal e-mail of a supervisor than the supervisor's subordinates?

Furthermore, intranets tend to be made up of one or more LAN segments where packets are transmitted freely for all to see. This is a much easier environment in which to steal data by capturing packets than the Internet, where it is now fairly difficult to capture packets not intended for your local network.

Finally, it doesn't take a criminal genius or a hacker to steal data sent over a local network. Any moderately skilled individual (someone who can use a spreadsheet) armed with a network diagnostic tool (which incidentally has a legitimate purpose) can capture any and all information sent over a local network.

Protecting transmission of passwords

The bottom line is that SSL should be used on any connection over which sensitive data is to be transferred. Perhaps the most important sensitive data in any Model 204 system is passwords. Since passwords are used to protect other resources, access to a password will compromise the security of all resources protected by that password. Even worse, certain passwords such as system manager passwords can be used to gain access to any resource in a Model 204 region.

A good rule of thumb, therefore, is that any connection over which a password will pass should use SSL. Janus Web Server actually issues a warning if you try to define a JANUS WEB rule that would result in a password being transmitted over a non-SSL connection. This would happen with any JANUS WEB ALLOW rule that has a USER clause in it, since the USER clause indicates a user login, hence userid/password are required for access to the URL specified by the JANUS WEB rule.

Protecting weak links

A dangerous fallacy is that if a resource is only slightly private — that is, while you want to limit access to the resource, it's not that big a problem if someone gets access to it — you don't need to use SSL. Remember, even if the resource you are protecting is not that important, the password of the userid accessing that resource is likely to be important. Even worse, once a userid/password is used to access any URL on a non-SSL Janus Web Server port, that userid/password combination will be sent by the browser (unencrypted) for all other URLs on that port (just in case these require a login). Thus by allowing a password to be transmitted unencrypted for a single URL on a non-SSL port, that password might be sent, unencrypted, hundreds of times over the network.

Once again, a good basic rule of thumb is that if a login is required to access a resource or URL, always force access to that resource or URL to go through SSL.

About Your SSL port

This section introduces some of the ways that Janus Network Security can be configured to provide different access controls for your users and applications. It briefly describes how to make such configurations, as well as how to make a connection from a web browser.

Security alternatives

Janus Network Security is flexible and able to provide a variety of levels of security to suit your needs. This section describes the different approaches available to you for securing (or not securing) ports for your Janus Web Server applications.

Before proceeding, it may be useful to clarify the term "port." A port is a defined entrance into your server, which can permit entry by one or more users. You can have more than one port on a server.

Secured and unsecured ports allowed on same server

You can choose to force SSL-protected communications on all ports on your server, or you could enable it only on specific ones. That means you could have a web site which provides some documents that are served only on secured ports while allowing other documents to be served on unsecured ports.

Many alternatives for restricting or permitting access

Several choices are available to you in restricting or permitting access to your secured ports, both in terms of applications and users. These choices are set by the configuration of the server port, described later in this document but outlined briefly below.

Controlling access by application on a secured port:

On a given secured port you can decide whether to require SSL-enabled communications for any or all applications served on that port. That means you can implement tighter security for one application that you may for another.

Controlling access by user validation:

For any or all applications, you can limit access by requiring that users log in with a valid userid and password as defined in the Model 204 online in which Janus Web Server is running. (Note that you can instead permit access by users without userids, as described below.)

By configuring the port to require client validation, the user would be prompted when connecting to a web page or application defined for such access control. This choice of access control would mean that only users who are defined in the online and who log in with a valid password would be able to access the application.

Restricting access to one, several, or a group of users:

Having been validated, access can then further be restricted to one user, a list of them, or a defined group of them. The group of users would be defined in the configuration of Janus Web Server.

Permitting access to all web users:

Alternatively, you can permit any and all users on the Internet (or intranet) to connect to an application, without requiring any log in at all. This approach is common on most commercial web sites using SSL for secured communications. In such a case, communications is still secured, but you do not expect to know in advance the identity of all users who may be connecting to your server (nor must you create logon IDs and passwords for them in the Model 204 Online.)

Configuring the server port

The use of SSL is a characteristic of a TCP/IP server port. That is, either all communications to a given server port uses SSL, or none of it does. (As described above, you can define multiple ports on a server, so some can be secured while some are not.) The use of SSL on a port is specified on the JANUS DEFINE subcommand.

Janus commands are entered in the Model 204 Online in which Janus Web Server is running, generally by a system manager. They define how a server port is to be configured, and they are described further in the Janus Web Server pages.

For example, the following command defines a port that is to use SSL on port number 443:

JANUS DEFINE WEBSSL 443 WEBSERV 10 SSL JANSSL MYCERT

The SSL keyword is followed by the name of a file and a procedure in that file that contains a certificate and private key to be used by SSL for the port being defined.

Further information on port configuration is provided in Define and start an SSL port.

More information about certificates and private keys is available in About keys and certificates.

Defining private key decryption subtasks

If you use SSL ports under MVS, you may want to configure one or more private key decryption subtasks. These are real MVS subtasks which are devoted to decrypting SSL private keys, a CPU intensive process. Moving this work to real subtasks increases Model 204 maintask availability for other work. These subtasks do not depend on the MP/204 feature, and they can be used whether or not you have MP/204.

For a complete description of the decryption subtask parameters, see MAXRDS and ACTRDS.

How a browser should connect

Browsers decide whether to use SSL based on the scheme or service part of the URL to which they are connecting. More specifically, if the service indicates http as in

http://rocketsoftware.com/football/scores

then SSL will not be used. If the service indicate https as in

https://rocketsoftware.com/personnel/salaries

then SSL will be used.

This does not mean that a user can gain unsecured access to a secured resource simply by specifying http rather than https. On the contrary, if the browser and the server are in disagreement over whether SSL is to be used, a communication error will occur.

When a web browser connects to an SSL-secured port, the browser displays an image of a connected key at the bottom of the screen. Depending on the browser and how it has been configured, the user may also receive a message upon transmitting data to the server that indicates that their communication is secured.

Specifying a particular port

When a port is defined for either secure or non-secure web server access, a number is associated with it, called the port number. The default port number for non-SSL web (HTTP) service is 80. When attempting to connect to a web server at its default address, you need not specify the number in the URL. To access a non-SSL web server port defined with a number other than 80, you must indicate the number of that port on the URL.

Similarly, the default port for SSL web (HTTPS) service is 443. Just as it is possible to make a connection to a specific port when not using SSL, it is also possible to do so using SSL. For example, the following URL indicates an attempt to open SSL communications on port 1776:

https://rocketsoftware.com:1776

About keys and certificates

In order to provide for secure communications and authentication, SSL employs several features, including public and private keys for encryption, and certificates and digital signatures for authentication. Each of these is described in this section, which concludes with a discussion of how to obtain and use certificates.

Public key/private key cryptography

An important component of SSL security is "public key/private key" cryptography. Such cryptography depends on the existence of pairs of large numbers that can be used as inputs to a formula or program for the purposes of encryption and decryption. The actual nature of the formula and numbers is beyond the scope of this document. Furthermore, knowledge of the details of the public key/private key algorithms is unnecessary for use of SSL.

Some important features of public and private keys are useful to keep in mind, however:

Something encrypted with a public key can only be decrypted with the private key.
Something encrypted with a private key can only be decrypted with the public key.
It is (practically) impossible to derive the private key from the public key.
If something correctly decrypts with the public key, it must have been encrypted with the private key.

Given these four features, it is then possible to assert that the holder of a private key can freely distribute the corresponding public key, and can be sure that only he or she could decrypt anything encrypted with that public key. This, of course, depends on the private key being protected from access by anyone other than its owner.

Certificates

One application of public/private key cryptography is the creation of certificates, which authenticate the authority of a client or server. A certificate is the formatted structure in which a public key is typically distributed. This structure also contains some basic information about the holder of the private key associated with the public key.

Server certificates used by SSL typically contain the country, state or province, locality (city, town, village, etc.), organization, and organizational unit of the holder of the private key. In addition, SSL server certificates contain the TCP/IP host name of the server that holds the private key.

The information in a server certificate can normally be viewed in a client application such as a browser, so an end user can be sure that he or she is communicating with the correct server.

Note: An SSL client will automatically verify that the host name in a server certificate matches the name of the host to which it is connecting.

A server may also request a sender's client certificate for authentication. The certificate contains information about the user, in addition to a unique private-public key pair. Client certificates, like server certificates, are obtained from a trusted source, and they are stored on the sending computer and accessible from some certificate management tool.

Digital signatures

One issue that arises is how to be sure that the information in a certificate does, in fact, correctly reflect the holder of the private key. It would seem that anyone could create a private and public key, package the public key in a certificate with phony information, and pass his or herself off as another server owned by another company. This problem is virtually eliminated by the use of digital signatures.

A digital signature for a certificate is a hash of the certificate encrypted with a private key. Digital signatures have the following characteristics:

The hash function must be well-known and not reversible. That is, it should not be possible to start with the hash and work back to a certificate. The well-known hash function usually used in SSL is MD5.
The public key associated with the private key used to create the digital signature must be known by the receiver of the certificate. If a certificate is to work with many different clients, it is helpful for this public key to be "well known."
The private key used to create the digital signature must be well protected, so only the private key's holder can digitally "sign" a certificate.
The holder of the private key used for signing (sometimes called a certifying authority, or CA) makes an effort to verify that the information in the certificate correctly identifies the holder of the associated private key. For example, a CA should verify that the organization name in a certificate actually matches the name of the organization that holds the associated private key.

Certifying authorities

There are several certifying authorities whose public keys are shipped with most browsers. Chief amongst these is VeriSign, Inc., at http://www.verisign.com. A certificate digitally signed by VeriSign has these benefits:

The holder of the private key associated with the certificate is almost certainly correctly identified by the certificate.
Almost every SSL client will be able to verify the signature on the certificate (because the VeriSign public key is so widely known).

Most browsers have a mechanism for adding a new CA to their database of valid CAs. This makes it possible to use certificates signed by non-standard CAs.

Self-signed certificates

Some browsers accept a server's "self-signed" certificate. That is, the private key used to sign the certificate is the private key associated with the public key in the certificate.

Self-signed certificates have some problems associated with them:

Since the certificate is self-signed, there is no way to be certain from just the certificate that the certificate correctly describes the holder of the associated private key. Fortunately, there are often other means to validate this information.
Some browsers don't accept self-signed certificates, and those that do, often require extra user interaction to use the self-signed certificate (as they should).

Nevertheless, non-standard CAs and self-signed certificates can be useful for testing and for establishing secure connections before a certificate signed by a standard CA has been obtained.

For example, the Janus Web Server application for generating a request for a certificate signature (to VeriSign, Inc., or some other standard certifying authority) should be run in secure mode, that is, over an SSL connection. What certificate should be used to secure the connection the first time this application is run? The answer is a self-signed certificate provided by Rocket Software with the Janus Network Security support. (This is also referred to elsewhere in this document as the "internal certificate".)

Certificate acquisition

Getting a valid certificate and private key typically involves a multi-step process like the following:

You generate a private key and an associated certificate request.
You send the certificate request to the certifying authority (CA).
The CA digitally signs the certificate and sends it back to you.
You receive the signed certificate, associating the signed certificate with the private key.

With its Certificate Management Application (aka JANSSL), described in detail in Implementing a server certificate, Janus Network Security helps you through this process. It provides an application for generating private keys and certificate requests, and an application for receiving signed certificates from a certifying authority. It also provides an application for signing certificate requests.

The last of these applications is useful if a site wants to have a local certifying authority. For more about this, see Acting as an Organizational Certifying Authority, which is implemented as the JANSSL subsystem.