The only way to really be secure with SSL

December 31, 2010

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.)

Written on 31 December 2010.
« One group that can sensibly use non-GPL'd Linux kernel modules
Why there is a gulf between shells and scripting languages »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Dec 31 22:38:47 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.