Secure Webulator/400 sessions
Encryption
This allows private conversations over the public Internet. Using Secured
Webulator/400 sessions, you are able to have a browser obtain information off
of your site that is encrypted. Even someone that can tap the wire between the
machines cannot understand the communications.
The same is true for data typed into the Webulator/400 screen.
Sensitive information such as user ids and passwords are
protected using strong encryption technologies.
Integrity
Secured Webulator/400 sessions essentially guarantees that the data sent between the
browser and server is unaltered during transmission. This would detect
both transmission errors due to noisy communication lines and malicious
modifications possibly made by someone in the middle of the server and
browser.
Authentication
Secured Webulator/400 sessions provide the visitors to your site confidence that they
have reached your site and not someone else's site trying to impersonate
your site.
Secured Webulator/400 Session Basics
In this section, a handful of concepts specific to doing secured
sessions over the World Wide Web are discussed. These concepts should
be clear to anyone administering a secure Web site. The following section
gets into more detail about how security is implemented.
Understanding these topics is not critical, however the entire picture
would be much more clear if these topics are also mastered.
Non Secured Webulator/400 sessions serve HTML forms using the
Hypertext Transport Protocol (HTTP). This protocol does not
perform encrypted transactions. The data sent between the browser and
server is sent "in the clear," meaning that anyone that can tap into the
wire connecting the two machines can eavesdrop on the conversation.
In addition to HTTP, Webulator/400 can also be configured to encrypt
the conversation by interfacing with the Secure Sockets Layer (SSL)
protocol. If both the server and browser are communicating through SSL,
then the HTTP conversation is done securely. The Secure Sockets Layer
encrypts data as it leaves one machine and decrypts it as it arrives at the
other.
There are three ways to set up Webulator/400 sessions. Webulator/400 can be
configured to serve non secured sessions. This means the HTTP
communications between the server and browser would not be
encrypted. Webulator/400 can also be configured for secured sessions which
means that all screens will be transmitted securely to the browser using SSL.
And lastly, Webulator/400 sessions can be configured as a SSL Signon session.
SSL Signon sessions can be thought of as a hybrid solution. Only signon
screens will be encrypted using SSL. All other screens will use the
standard HTTP protocol and will not be encrypted. You may want to consider
using this approach if are willing to spend the extra CPU require for
encryption to protect your user ids and passwords but do not consider the
extra CPU requirements necessary for all other AS/400 screens.
Configuring session security is done on a per-session basis using
the Allowed Protocols session based
configuration value.
Server Certificate
Every server implementing secured transactions requires a server
certificate. This is used to identify the Web site and to provide browsers
with the Web site's Public Key. The public key is used to provide
encryption, integrity, authentication and nonrepudiation. Server
certificates are obtained from a Certification Authority such as VeriSign,
Inc. A series of commands are provided to assist in the creation of a
server certificate for a Web site.
Keylist Database File
A Web site's security information is stored in the keylist database file.
This file is encrypted using a user-supplied password. The file is
reasonably protected by being encrypted, but it should also be physically
guarded as much as possible.
The server's certificate, public key, and private key are all stored in
this file. The public and private keys are very large numbers that are
used to perform the secure transactions. Only the private key needs to be
closely guarded. The server's certificate and public key can be freely
distributed.
The server certificate, public key and private key are all interrelated
and must be kept together in the same keylist database file. If a Web site
has more than one certificate, then multiple keylist database files will be
needed. This might be the case if a Web site is using Multi-home support
to host multiple secure Webulator sites on the same machine. Each instance of
the server could either share the same keylist database file (and
certificate) or use its own.
How Does Webulator/400 Do This?
The exact details of how secure electronic communications are done are not
important, but a few of the pieces can be helpful. The above listed
features of a trusted Web site are accomplished using 1) Server
Certificates, 2) Private and Public Keys, 3) Public Key Cryptography, and
4) Bulk Encryption Algorithms.
Server Certificates
Every Webulator/400 server requires a server certificate if you wish
to configure secured sessions. This is
used to both prove its identity and to exchange encrypted information with
browsers. The certificate contains a distinguished name of the server
which is used to uniquely identify the server to visitors, it contains
the server's public key, and it contains a digital signature of a
Certification Authority.
- Distinguished Name
- This consists of information that uniquely identifies your Web site.
Values such as the Internet host name of the machine, the company's name,
and the State and country of the company. The Certification Authority will
validate this information before providing a company their server
certificate.
- Public Key
- The public half of a Web site's encryption key. Visiting browsers use
this value to communicate securely with the server. This is described more
below.
- Certification Authority
- A Certification Authority (CA) provides server certificates. Before a
company can begin doing secure transactions, they need to request a server
certificate from a CA. The CA will verify the identity and validity of the
company's request for a server certificate and then provide a digitally
signed server certificate. The company will then install this certificate
into their Web server software.
- Digital Signature
- Using sophisticated mathematical algorithms, a digital signature of a
document can be created that proves the identity of the signer and verifies
the contents of the document. In the case of a server certificate, if the
CA digitally signs the distinguished name and public key portions of the
certificate, then anyone that trusts the CA can be confident that the
certificate has not been changed.
Private and Public Keys
Part of the process of generating a server certificate is generating a pair
of large numbers. One of these numbers, the public key, is shared with
everyone who wants to communicate with the Web site. The other number,
the private key, is only known to the Web site and its administrator(s).
The private key is held in the strictest of confidence. Webulator/400
stores this in its keylist database file, encrypted using a
user-supplied password.
Public Key Cryptography
Public Key Cryptography is used to do two things: exchange bulk encryption
keys and verify digital signatures. What is special about Public Key
Cryptography is that anyone who knows a person's public key can use it to
encrypt a message for that person that no one else can understand. The
only way to decrypt that message is using the private key half of the
public and private key. The opposite is also true: Something encrypted
with a private key can only be decrypted with the public key. This allows
two parties to communicate without previously exchanging a secret
password.
In terms of Web serving, the Web site's public key is provided to anyone that
wants to securely communicate with that server. This is done by sending
the server's certificate (which contains the public key) to a
browser that wants information from the server. The browser then uses the
server's public key to encrypt a password that will be used to encrypt the
rest of the communication between the server and browser. Since the server
is the only one that knows its private key that can decrypt something
encrypted with its public key, the server is the only one that can
successfully decrypt the password.
Public Key Cryptography is also used to verify digital signatures. When a
CA digitally signs a certificate, it is really encrypting a piece of the
certificate data using the CA's private key. When a browser wishes to
verify that signature, it decrypts the signature using the CA's public key
and compares it to the certificate data. If they match then the digital
signature is valid.
Bulk Encryption Algorithms
In the discussion on Public Key Cryptography, the browser encrypted a
password that would then be used by both sides to encrypt the rest of the
data. Public Key Cryptography could be used to do all the encryption
between the browser and server, but it has two disadvantages: This would
require that the browser also has a public and private key so the server
can securely encrypt data sent to the browser. And, Public Key
Cryptography is computationally very expensive.
Instead of using Public Key Cryptography for the entire transaction, only a
secret key, or password, is exchanged using this algorithm. Then this
secret key is used by both sides to perform simpler and faster bulk
encryption algorithms.