The Problem
On the internet, when a web server communicates with a browser, the data is broken up into smaller pieces ("packets") and each packet travels across an unspecified path involving any number of computers. Any one of these computers can examine ("sniff") the contents of a packet without the knowledge of the browser or server. This is why normal internet web traffic is considered insecure. Even within an intranet, there is still have exposure across the different computers within a company.
When accessing a protected web page, one that requires entering a userid and password, the browser sends the userid and password in an encoded, not encrypted form, to the server. This userid/password is easily decoded by anyone who has access to that packet. Thus, even if the web server uses z/VM security methods to protect its pages, valid passwords are exposed during the transmission by authorized users.
The Solution
zVWS solves this problem by incorporating industry standard Secure Sockets Layer (SSL) protocol.
SSL allows a browser user to:
- Authenticate the web server
By using digital certificates, the identity of the web server owner is verified in such a way that the user can be sure that the browser is communicating with a known web server owner and not with an imposter.
- Communicate privately
Data moving between the browser and zVWS is encrypted so that anyone spying on the communications link is unable to see or understand the data being transferred.
- Communicate without tampering
Data moving between the browser and zVWS is encoded in a way that enables detection of any alteration of the data. This ensures that the data arrives safely, and unmodified by any third-party.
Public Key cryptography
SSL uses public key cryptography standards (PKCS) to implement authentication. PKCS works with two mathematically related large numbers called the public key and the private key. The public key is made available to anyone, while the private key is kept secret. Data encrypted with a public key can only be decrypted using the associated private key and data encrypted with the private key is decrypted using the public key. The secrecy of the private key enables the browser user to trust the servers identity. A zVWS administration procedure is provided for generation of a key pair.
SSL passes the public key for the web server organization to the browser user inside a document called a certificate. The certificate includes such information as the website name, the company name, the company location, and the public key. Two types of certificates are used by zVWS. Self-signed certificates, generated by a zVWS utility, had limited trust, and are generally used only to test SSL. However, one might also be used in an intranet environment where access to the zVWS server is controlled.
In most cases, zVWS is directed to use a server certificate provided by a
third party, called a Certificate Authority. Such a certificate is decoded using
the public key of the Certificate Authority, so that one can be certain that the
Certificate Authority (or CA) actually issued the certificate. The authority
issues the certificate containing the public key of the organization running
zVWS, and essentially vouches for the fact that the public key belongs to the
organization. If the browser user trusts the Certificate Authority, then the
user can trust the identity of the organization running the web server.
Note: Both Internet Explorer and Netscape come pre-configured to trust Verisign,
the certificate authority used by and recommended by Velocity Software.
Three Levels of Security
Velocity Software will be providing three different levels of encryption to meet the current U.S. Export requirements (as we currently understand them). Based on our current status associated with export licenses, we will ship either SSL56, SSL for Export, or SSL Full Strength. These are defined below.
SSL involves different cyber suites. When the browser negotiates the secure session with the server, the highest level supported by both server and browser is agreed upon and used. The three levels as defined by zVWS are:
- SSL56
This will be our lowest level of encryption, using 40 bit and 56 bit level encryption in use with a 512 bit key exchange. There's only minimal legal requirements in exporting this level.
Key Exchange Cipher Message Digest RSA (512) ARCFOUR-40 MD5 RSA (512) DES-40 SHA RSA (512) DES (56) SHA
- SSL for Export
Using 128 bit encryption in conjunction with up to a 1024 bit key, there are some restrictions on to whom this can be exported. The cipher suites supported by this level are:
Key Exchange Cipher Message Digest RSA (512) ARCFOUR-40 MD5 RSA (1024) ARCFOUR-128 MD5 RSA (1024) ARCFOUR-128 SHA RSA (512) DES-40 SHA RSA (1024) DES (56) SHA
- SSL Full Strength
Available to U.S. and Canada, as well as U.S. subsidiaries, this supports tripleDES (168 bits) encryption and up to a 2048 bit key. The cipher suites supported by this level are:
Key Exchange Cipher Message Digest RSA (512) ARCFOUR-40 MD5 RSA (1024,2048) ARCFOUR-128 MD5 RSA (1024,2048) ARCFOUR-128 SHA RSA (512) DES-40 SHA RSA (1024,2048) DES (56 bit) SHA RSA (1024,2048) tripleDES SHA
- ARCFOUR-40 - is an algorithm equivalent to RC4 with a 40 bit key.
- ARCFOUR-128 - is an algorithm equivalent to RC4 with a 128 bit key.
- DES-40 - is the Data Encryption Standard algorithm with a 40 bit key.
- DES - is the DES algorithm with a 56 bit key.
- tripleDES - is the DES algorithm with a 168 bit key.
- MD5 - is the Message Digest 5 algorithm.
- SHA - is the Secure Hash Algorithm.
