Practical Internet Groupware

Secure dhttp

If you implement local HTTP service using a conventional web server, as of course you can, your security options are as follows:

IP address restriction

This technique, which all web servers support, can be used to reject all but a specified set of hosts. It’s of dubious value when the users you want to support present different addresses at different times. That can happen when they log in variously from desktop machines behind the firewall or ISP-connected home machines outside the firewall. It can also happen when they log in from desktop machines that receive dynamically allocated IP addresses.

Basic or cookie authentication

Every method in the dhttp system is a kind of CGI call. With basic authentication you can require name/password credentials for every call. With cookie authentication you can allow those credentials to persist on client machines across sessions.

SSL encryption

Basic or cookie-style credentials are very weak forms of security when used on a cleartext channel. They’re much stronger when the channel is encrypted using SSL. Moreover, an SSL channel encrypts not only credentials, but all data flowing through it.

Encryption is the most attractive solution. How might dhttp do that? One option appears to beSSLeay, the open-source implementation of SSL. But the legal issues surrounding the use of SSLeay are complex and unresolved. First, there are the patents that RSA Data Security holds on the encryption algorithms used in SSL ciphers. Because these ...