2010-12-31
The only way to really be secure with SSL
There is a popular view that use of SSL creates authentication. If you really care seriously about security (and worry a lot about interception), this is not the case. Assuming that all else goes well, a SSL certificate only creates authentication if you (as the user of a website) can trust that the certificate actually belongs to the website; otherwise you could be talking to an imposter or someone conducting a man in the middle attack.
(Note that there is a lot that can go wrong before you get to this point if there are people involved, or even software that makes mistakes.)
Knowing this is a lot different than merely knowing that a website's SSL certificate is signed by a general CA that you accept. It follows that the only way to be really secure with SSL in practice is to control the full signature authentication chain, so that you simply don't accept SSL certificates signed by general CAs; this is the only way to keep either CA screwups or 'corrupt' CAs from destroying your security by issuing imposter certificates through accident or malice.
(As I've alluded to before, I put 'corrupt' in scare quotes because you can't really call CAs corrupt as such when they are actually arms of a hostile government, or simply vulnerable to legal coercion. By the way, don't think that you won't get spied on just because you've got no espionage value for governments. National governments have a long history of conducting economic spying on behalf of sufficiently important local companies.)
Unfortunately this is relatively difficult with today's software. It isn't enough to simply have a private CA and preload all of your employee's machines with the CA root certificate; that just lets them accept your CA in addition to all of the other CAs. If you really care about security, you do not want your employees accepting certificates for your machines that are signed by anyone other than your CA (and you do not want this to be something they can override under any circumstances, because at this point you are well into the rainbow series 'better to fail than to disclose information' territory).
(I say employee instead of user because generally employees are the only people you can make go through this much pain and annoyance.)
The two solutions to this are client certificates and custom software. Client certificates let your SSL servers verify that they are talking directly to the employee's machine (and thus that it has accepted your certificate and your strong crypto), with no CA-enabled 'transparent' interception going on. The easiest custom software is simply to use a VPN (with appropriate certificates and non-relayable authentication); you can then make your important secure services only accept connections from the VPN's IP address range. Using a VPN has the twin advantages that you do not have to figure out how to make all of your important SSL servers require client certificates (and manage them), and that you can secure services that do not use SSL or do not use SSL soon enough.
(On a general level you're still vulnerable, but now you only have to worry about keyloggers and other problems with compromised employee machines. And client issues are theoretically out of scope for SSL anyways.)
One group that can sensibly use non-GPL'd Linux kernel modules
A rather long time ago, a commentator on my entry on the practicalities of non-GPL'd kernel modules wrote, in part:
ZFS is most beneficial to companies running storage servers. These companies will only use supported modules [...]
I actually think that this is backwards. Ignoring the various legal issues for the moment, companies building commercial storage servers are exactly the people that I would not be surprised to see using a kernel module that was not and could never be in the mainline Linux kernel.
(I agree that organizations rolling their own hand-built storage servers on commodity Linux distributions would be crazy to adopt any out of kernel module that was not really crucial and very well maintained, or at least trying very hard to get into the mainline and likely to succeed.)
More generally, I think that any company selling a black box system based on Linux has a number of decent reasons to consider using out of kernel modules:
- delivering a black box instead of a Linux system (or distribution)
drastically reduces the pressure of updating to new Linux kernels and
thus the support burden of dealing with porting code and so on.
- they may well really need the features that the out of kernel module
gives them, or to put it another way such modules can give them
significant competitive advantages (as in the case of ZFS).
- if they're doing a good job, they already need to have fairly deep kernel expertise on hand in order to tune things for their specific environment and to fix any bugs that you run into.
The latter deserves a bit of elaboration. First, the attraction of black boxes to your customers is that they just work. Thus, as a company you do not have the time to wait for anyone else to solve the problems you run into, either before you ship or after you ship; no matter what, you need your own local expertise so you can fix problems in a timely manner.
In a sense, the extra work required to make out of kernel modules work is a competitive advantage. In the long term, a good part of your profits are determined by how much value you add; the more value you add, the more profits you get (conversely, the less value you add the less money you make). Doing the work costs you money, but if you chose correctly it gives you more than that back in extra value added.