Note: This file has moved to notablog.

Somebody wrote: I have a client who wants to do a project that involves having users upload some extremely sensitive data via the web. They are very concerned about the security of this information, not only keeping the information confidential but also reassuring their clients (for whom they are doing the project) that there is no possibility the information will be compromised. [...]?> The problem is what happens to the data after it reaches the server. Their current ISP is fairly disorganized and conversations with them has only convinced my client that they will never be comfortable setting this project up where they have their normal web pages. Hm... sounds like you have some fairly stringent (although not entirely unreasonable given the circumstances) security requirements. My first comment is that there are a lot of ISPs and IPPs out there. I have no idea whether any offer "secure" hosting (i.e. more secure than normal). I doubt you'll find them advertising it if they do - it'd just make them a target. You may have to narrow your list down and contact them to find out. I have no doubt you'll pay a pretty penny for a high-security server and for *real* security you'll no doubt have to deal with some constraints imposed by the security. The guys at www.bravenewworlds.com are not cheap, but are probably a better bet than your average McISP when it comes to keeping their systems and and network secure. They also might be able to help you implement my next suggestion (though I haven't asked them about it), which is to use public key encryption on the server to keep the data safe and secure until it's downloaded. Public key encryption, of which the most well-known examples are SSL and PGP, is where you have two keys, public and private. Using special "one-way" mathematical functions that I can't explain, let alone understand :-), the public key can be used encrypt but not to decrypt. The private key is necessary to decrypt. You can hand out your public key to all and sundry so they can send you private messages, or use it in a less secure context (like the web server) to encrypt data. Keep your private key private and use it to decrypt the data once you have it on a more secure system. A variant on this technology is used in SSL, mostly to set up a normal private-key encryption tunnel between your browser and a web server. There's still a window of vulnerability, since the web server itself could be subverted and the program that ordinarily takes the information could be replaced by one that mailed it off to somewhere. But the window is much smaller, and the data submitted up to that point is safe from prying eyes. There are other precautions you can take against such subversion, for example a program like Tripwire. Tripwire is a security program from the COAST project (I don't know if there are any commercial versions available, but the source is available from the COAST ftp archive). You run Tripwire against the files in your system to produce something like a checksum. A Checksum is a unique number derived from the data in a file; checksums are normally used to be sure that a chunk of data survived transmission intact. Checksums, however, can be faked - a checksum doesn't guarantee that the data in two files is identical, but it's extremely unlikely that two different sets of data would produce the same checksum number. Tripwire, on the other hand, uses an algorithm that is not just "unlikely" but difficult (if not impossible - but math types don't like the word impossible :-) to fake the checksum. Used properly, neither Tripwire nor the checksum values should be stored on the computer. Ideally they'd be stored in an un-mounted, physically disconnected drive. Then you periodically (daily or maybe even hourly if you're *really* paranoid) connect, mount, run, compare the numbers, unmount and disconnect. Or, rather, to really, really be paranoid, you unmount the data drive and plug it into the system (not connected to the network) that has Tripwire. This avoids any possibility of your system being compromised and a wily intruder actually subverting the process of your running Tripwire. This is, needless to say, unlikely, but then again, security is a matter of degrees. Needless to say, this is all a big pain in the ass. Tripwire should be run regularly to determine if your program files (particularly if your program files are binaries, not scripts) have been subverted. If you have a Linux system of your own and you're competent with it, you should be able to figure out things and keep the Tripwire software and logs on your box, connecting to the web server and uploading them (or downloading the files you're keeping track of, whichever is smaller and easier) and checking. (Come to think of it, you could get a rudimentary level of Tripwire-like security by simply re-uploading fresh copies of your software. Of course, you quickly run into trade-off issues. If it were just the perl scripts in your CGI-bin directory, for example, that'll go pretty fast, but you have no idea whether the Perl interpreter was subverted, not to mention the webserver, which might be subverted and set up to run a different interpreter or a different script altogether). Which brings us to the next issue, which is how do *you* get secure access to the web server. Security isn't about not allowing access to things, it's about allowing controlled acess. Otherwise, the best firewall in the world would be a brick. If you manage to find an ISP and convince them to take these elaborate precautions for you, they're not about to turn around and let you log in over the internet in the clear. You need to get to your server in such a way that your packets can't be sniffed by somebody else somewhere along the way, either in *your* local network (or your dialup ISP's network) or in the local network where the web server is hosted. Enter Secure Shell (ssh). Secure Shell is a program for securely logging into a Unix system. It uses some of the techniques I discussed above to create an encrypted "tunnel" through which the two programs (one on your box and one on the web server) can send and receive information. This is somewhat like SSL, but I won't even begin to try to explain how it works. The important point to realize is that besides allowing encrypted telnet sessions, Secure Shell can be set up to allow encrypted connections of all sorts. It's fairly common for people to use Secure Shell to allow secure FTP via "port forwarding", for example. I know a guy who set up a secure shell tunnel from his home linux box to his work linux box and routed his work pop server through it. That way he could run his favorite mail client at home and just point it at the standard email port and get a secure connection to his work mailbox. SecureCRT is a commercial product (with a 30 day demo avaialble for downloading) that will provide Secure Shell capabilities on an MS-Windows OS. It also provides excellent vt100 emulation. Well worth the $30 for a license. Putty is a free terminal emulation program with SSH support, and TeraTerm is yet another free terminal emulation program with SSH support. TeraTerm SSH and SecureCRT also provides port-forwarding capabilities similar to what normal SSH provides (Putty doesn't). Yet another option for those more comfortable in Unix-like environments, is cygwin's SSH implementation for Windows. I guess you can see there's a lot involved in maintaining a high-security site. I haven't even touched on the extensive network and system security measures that are necessary, and things get even more work-intensive when you have a large user population in your local network or even worse, on the same box (you'd be better off colocating your own box so you can avoid worrying about other users as much). Still, if you find a reasonably careful ISP/IPP and take some extra measures as I've described, you can attain a much better than average level of security with some diligence and planning.