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 are U.S. patents, it is a patent violation to use SSLeay inside the U.S. without acquiring RSA’s commercial BSAFE library and linking SSLeay with it. Does that mean SSLeay is legal for non-U.S users? Not necessarily. The names of the ciphers, notably RC4, are trademarks, and trademark protections cross all borders. The SSLeay distribution now acknowledges this fact:
RC4 is a trademark of RSA Data Security, so use of this label should perhaps only be used with RSA Data Security’s permission.
These issues, compounded by the U.S. government’s prohibition on the export of strong cryptography, quite seriously complicate efforts to build tools that use SSL. It’s an odd situation. SSL technology is so prevalent, in inexpensive or free browsers and web servers, that people assume SSL itself is inexpensive or free, and that’s far from true. A BSAFE license is very expensive. Netscape and Microsoft have amortized the cost of licensing RSA’s technology across a large population of browsers and servers. That makes it easy to use SSL in the context of secure browsers and servers. But it’s not easy to use SSL in other tools that interoperate with secure browsers and servers.
One solution, on a Windows machine with MSIE installed, is to use MSIE’s licensed encryption components—for example, by way of the interface library WININET.DLL. That’s not ideal, though, because WININET isn’t a cleanly isolated system service like ODBC. It’s more like a browser-specific component. If you regard dhttp as a system service, you don’t want its security mechanism to depend on how the user configures the MSIE advanced preferences, as can happen if you depend on WININET.
Another solution, for a Windows or Unix machine with any browser installed, is to use a version of SSLeay that’s linked with RSAREF, a reference implementation of the patented RSA algorithms that RSA makes available for noncommercial use. But SSLeay/RSAREF isn’t readily available, it’s not easy to build it, and even if you did, it’s not completely clear what you are and are not allowed to do with it.
Let’s step back for a moment and ask: Why SSL? Largely because that’s how browsers do encryption, and we want dhttp to work with browsers. For server-to-server communication between dhttp nodes, another encryption technology—one unencumbered by patents and other legal issues—might work. To test this idea, I wrapped up a reference implementation of the Blowfish encryption algorithm (see Bruce Schneier’s http://www.counterpane.com/) in a Perl extension module. How? The details of Perl’s extension mechanism are beyond the scope of this book, and in any case I’m far from an expert on the subject. See the Perl documents perlxs and perlxstut for an introduction to Perl extension modules. Suffice it to say that it’s possible to outfit a robust scripting language—in my case Perl, but in yours, perhaps, Python or something else—with symmetric encryption and decryption functions. For example:
use Blowfish;
my $key = "*y)==.67Ab,XsQxa789{%^2";
Blowfish::initialize($key, length($key));
my $cleartext = "Hello, world";
my $ciphertext = Blowfish::encipher($cleartext, length($cleartext));
my $deciphered = Blowfish::decipher($ciphertext,length($ciphertext));That’s mildly interesting. It gets really interesting when you add the notion of a dhttp node that proxies requests on behalf of the local browser. Now we can see why a dhttp plug-in, such as the Jobs module, might want to specify a host and port as part of every URL that it generates. Suppose every URL were expressed in terms of the local machine, which handled local requests locally and proxied remote requests. To illustrate this idea, Table 15.4 expands the previous example yet again.
Table 15-4. Peer- Networking Matrix with Local Proxying
|
Operation |
Browser |
URL |
|---|---|---|
|
I use my database. |
mine |
http://my-dhttp/jobs_home?host=my-dhttp&user=me |
|
I use your database. |
mine |
http://my-dhttp/jobs_home?host=your-dhttp&user=me |
|
You use your database. |
yours |
http://your-dhttp/jobs_home?host=your-dhttp&user=you |
|
You use my database. |
yours |
http://your-dhttp/jobs_home?host=my-dhttp&user=you |
Now when the browser asks for a page from a remote dhttp node, it relays the request through the local dhttp node, which acts as a proxy server. When the destination is local, the proxy passes the request straight through to the local server. When the destination is remote, it performs the following steps:
Encrypt the request.
Create a new LWP HTTP request object.
Add to that object the HTTP header
Remote-Dhttp, whose value is the local machine’s hostname and port.Send the
Remote-Dhttpheader and the encrypted HTTP request to the remote node.
On the other end, the remote node handles requests from itself in the usual way. When encrypted requests arrive from a remote partner, it decrypts them.
This proxy scheme creates an encrypted browser-to-server channel that doesn’t use SSL. Of course, that channel can also be used noninteractively by local processes that communicate with remote nodes. How secure is it? As cryptography guru Bruce Schneier likes to point out, the security of any algorithm depends on the key. Methods of generating, distributing, and using keys are what make or break a cryptosystem. A network of dhttp nodes that uses only a single shared key, and that never changes that key, will be cryptographically weak. Even so, it will be more secure than a network of dhttp nodes that does no encryption at all. Computer espionage tends to follow the path of least resistance. An unlocked door is far more inviting to an intruder than one that is locked, no matter what the quality of the lock.