eries of protocols and applications with the ability to penetrate firewalls, that won't solve the two real problems:
Problem #1:
There are no safe protocols
.
If you think HTTP is benign, think again. Simson Garfinkel, author of
Practical UNIX and Internet Security
, sketches out several ways to attack a firewall that's permeable only to HTTP. Here's one: Convince people to download a Netscape plug-in that silently relays secrets to a rogue server outside the firewall. "The plug-i
n could do anything at all, even run a packet-sniffer on your LAN," says Garfinkel.
Problem #2:
There are too many doors
.
A perfect firewall is not the answer. Just about any Mac, PC, or Unix workstation can bypass the firewall by dialing the Internet directly. You can't police them all. Insiders, sometimes knowingly, represent the worst threat.
Beyond Firewalls: The Virtual Private Network
IPsec, now in gestation, looks like a good answer. It's a secure form of TCP/IP, encrypted from end to end. The first crop of implementations, built by firewall vendors, are now entering the interoperability test phase. They will enable secure use of any standard IP application for business-to-business networking. Why is that important? The Web is hot, but there is much more to distributed computing -- sockets, remote procedure calls (RPCs), Internet inter-ORB protocols (IIOPs). You would like to be able to do all these things safely on the public Internet.
Fi
rewall-based secure IP will not, however, deter deliberate or accidental sabotage from behind any of the firewalls participating in this kind of virtual private network. What would? Desktop-based secure IP. The kind of end-to-end encryption that's available now at the application level -- between secure Web servers and Web browsers, or between Notes servers and Notes clients -- could, in theory, migrate down into the TCP/IP stack on your workstation. Any IP application could then communicate securely within and across corporate boundaries. But don't hold your breath. Gateway implementations of secure IP have yet to prove themselves computationally and administratively feasible. Desktop implementations are even further off.
Coping Strategies
While you're waiting for secure IP to arrive, here are some interim solutions:
Piggyback on HTTP.
When you have only a hammer, everything looks like a nail. Likewise when the Internet industry decides that HTTP is the "safe" p
rotocol, every application starts to look like an HTTP application. "We're taking higher-level protocols like DCOM and putting them on top of HTTP in order to get through firewalls," says Bob Muglia, Microsoft's vice president for development tools. "It's crazy, but HTTP has become a legacy thing like MS-DOS."
Use Lotus Notes.
A Notes network riding on top of the Internet can be a highly secure virtual private network for geographically dispersed employees and business partners. To reach customers outside the Notes environment, use Internotes WebPublisher to export access to data and applications.
Encrypt your e-mail.
This is currently harder than it should be. Implementations of Pretty Good Privacy (PGP) have been available for years, but none yet integrate into popular mail programs such as Eudora and Netscape Navigator. A number of e-mail vendors now plan to support an alternative scheme, Secure Multipurpose Internet Mail Extensions (S/MIME), but no S/MIME mailers
are available yet, either.
What's the holdup? Nobody wants to get busted for violating U.S. restrictions on export of cryptographic technology, says Simson Garfinkel. Still, it's likely that secure mailers will soon be prevalent. Secure SMTP will be a useful transport for many applications.
Exploit other secure applications.
Netscape has added secure socket layer (SSL) support to its news server and client. Kerberos-enabled versions of mail, FTP, and other applications are available. These kinds of solutions lack the universality that makes standard Web applications so appealing. But they do exist.
The Firewall Dilemma: Too Few Locks, Too Many Doors
