SSL essentially provides encryption to sensitive data to prevent it from being read by the casual observer on the Internet.  SSL is far from being totally secure, due in part to the limitations on the export of keys of over 40-bits in length.  However, within the United States these keys may be up to 128-bits long.

Because SSL, among other related technologies, is considered so vital to the continued growth of Internet commerce, some companies offer SSL hosting services.  For a fee, anywhere between $15 and $20 a month, they will provide a secure order form for your customers to protect sensitive data such as credit card numbers of personal information.

SSL is an open, non-proprietary security protocol developed by Netscape Corporation. It is layered between application protocols such as telnet, ftp, or HTTP and TCP/IP. Because it is an open protocol, there may be many vendors each providing their own implementation. However, all implementations must conform to a rigid set of standards. A draft of those standards is available at http://home.netscape.com/eng/ssl3/index.html.

SSL works on top of TCP/IP but beneath web-enabled applications such as HTTP, FTP, and telnet.  The following diagram, taken from http://nestroy.wi-inf.uni-essen.de/Lv/ibis1/ws9798/folien/09-21.html, shows where SSL lives in relation to the other components of TCP/IP.

SSL Handshake Protocol

The SSL handshake protocol is similar to the TCP component of TCP/IP.  It governs the overall connection between a client and a secure server.  The various data is passed to the SSL Record Protocol for message formatting and direct communication with TCP/IP.

According to version 3.0 of the draft SSL standard, the handshake between client and server is used to:

SSL Record Protocol

The record layer takes data from the higher-level layers and fragments it into records.   An extremely long message may be split into multiple records while several shorter messages may be merged into a single "packet."  However, SSL does not synchronize these packets; if they get out of sequence, the entire batch must be discarded and re-sent.  In this sense, the SSL record protocol is like the IP component of TCP/IP; it provides the point-to-point connectivity between secure servers.

SSL packets are 2^14 or 16384 bytes or less.  SSL also uses lossless compression to minimize packet size where possible.

In general, the only major change is that the web-page be prefixed by "https" rather than the normal "http."  This enables secure sockets if the server supports them.  Frequently, the server uses different ports for secure transactions than for unsecured ones.  The following table illustrates the most common ports and their associated secure applications:

There is also a secure form of FTP although there is conflict with an existing name of SFTP (simple file transfer protocol).  Currently no one has proposed an FTPS application, but some companies are using port 990/tcp until an official port is registered through IANA (Internet Assigned Numbers Authority).

More information about this algorithm is available at http://www.rsa.com/.

The RSA algorithm is used to share secrets between the client and server.  These secrets are essentially symmetric keys such as those used by the DES algorithm.  Thus the security of RSA is invoked to share keys, but the efficiency of DES is used for the actual communication between client and server.

Secure sockets can use a 128-bit encryption key, but only within the United States.   This length key is illegal for export.  Instead, only the 40-bit key may be exported from the country calling into question the security of applications relying on SSL.  This limitation may prevent secure sockets from being a primary source of security for world-wide transactions such as those required by banking and security institutions.

This site, http://pauillac.inria.fr/~doligez/ssl, contains an interesting article about how SSL was broken.  Essentially an individual used 120 low-end PCs in parallel to crack a single SSL session.  The algorithm would take a maximum of 15 days with a mean time of 8 days.

It is important to note, as the author points out, that SSL was not broken in this experiment, merely a single session of SSL.  If another session is to be broken it would require, one average, another 8 days of computing time.  This means that SSL is perfectly adequate for all transactions involving time-sensitive data: by the time the session is "cracked" the data may be of limited value.

Interestingly enough, very few of the groups who have successfully "hacked" an SSL session feel that this ability should adversely affect the future of Netscape or of SSL.  One author points out that people are continually giving their credit-card number, expiration date, etc. to clerks in stores and think nothing of it, despite the fact that they are leaving a hard-copy of that data that may pass through multiple hands.   However, one possible result of this experiment may be that vendors such as Microsoft or Netscape try to persuade the government to allow for the export of the full 56-bit DES algorithm.

The author also provides the source code.  This code is provided as is and with no guarantees.  It is split into two separate files:

• master
• slave

Instructions for compiling and running the programs is given at http://pauillac.inria.fr/~doligez/ssl/sources.html.

This was designed, but the ISP does not support a secure-socket connection on their servers.  No doubt this is to discourage would-be entrepreneurs from using their server as a staging area for a money-making venture.

However, he site http://walpole.booklink.com:8000/test/security/security.htm provides a section on "testing security."  This allows you to connect to various types of server to determine what security your browser supports.  For instance, both the 40-bit and 128-bit version of SSL are available.

A draft of the SSL Version 3.0 protocol is available at http://home.netscape.com/eng/ssl3/index.html.   This draft provides detailed information on how the SSL protocol is to be implemented.  It includes information governing everything from the datatypes to be used to the algorithms required to ensure privacy to the sequence of steps required to perform handshaking.