SSL and S-STTP Compared

Although these two protocols attack the same set of problems, they use significantly different approaches. You can think of S-HTTP as a smorgasbord approach, with a large choice of options that are taken in any combination to make he meal of your choice. By contrast, SSL is something of a fixed-price menu, good wholesome food but a limited number of combinations.

One major advantage of S-HTTP is its ability to perform client authentication. This allows a truly secure client/server session to be established. The fact that this requires the client to have a public-key certificate limits the degree to which it may be applied, however.

The major advantage of SSL lies in its ease of use. The cryptography options are all have-coded into the browser and server code, so the Webmaster does not need to worry about specifying options in HTML or configuration files. Also, the domination of Netscape products in the World Wide Web makes SSL the clear choice for applications with a widespread client base.

You could, in theory, use both S-HTTP and SSL together, since one enhances the HTTP session flow and the other encapsulates it. The only thing preventing this in current implementations is the fact that the URL conventions (https: for SSL and shttp: for S-HTTP) are contradictory. However, it is difficult to imagine a situation in which combining the protocols would make any sense.