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, you still have exposure across the different computers within your own company.
When you access a protected web page, one that requires you to enter a userid and password, your browser sends your 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 your web server uses VM security methods to protect its pages, valid passwords are exposed during the transmission by authorized users.
ESAWEB solves this problem by incorporating industry standard Secure Sockets Layer (SSL) protocol.
SSL allows a browser user to:
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.
Data moving between the browser and ESAWEB is encrypted so that anyone spying on the communications link is unable to see or understand the data being transferred.
Data moving between the browser and ESAWEB 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.
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. An ESAWEB 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 ESAWEB. Self-signed certificates, generated by an ESAWEB 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 ESAWEB server is controlled.
In most cases, ESAWEB 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 ESAWEB, 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 that both Internet Explorer and Netscape come pre-configured to trust Verisign, the certificate authority used by and recommended by Velocity Software.
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 ESAWEB are:
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 |
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 |
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 |
