Arranging your SSL websites for very cautious people

October 3, 2008

Suppose that you have a very valuable SSL certificate (for example, you are a bank) and a rather complex application (for example, you are doing online banking). You want to limit the damage of a compromise as much as possible and especially you do not want to have the high value SSL certificate compromised, because that would be a gold mine for sophisticated attackers.

Here is one approach to this problem that has recently struck me:

  • your application runs on your pool of servers as usual, but each of them has its own DNS name and its own SSL certificate and you make these visible to the outside world.

  • your normal https website, the one that users all know about and use, does not run your application. Instead, all it does is serve up (https) redirections to one of the pooled servers, using that server's individual name.

What this does is give you what I will call revocable names, DNS names that you can easily delete. You need this because the only way to limit the damage of a certificate compromise is to insure that the attacker can't use the certificate any more, and the only sure way to do that is to remove the hostname that's in the certificate.

Here, you have a system where the complex application is running on machines with revocable names. The only thing running on the one name that you can't revoke is your very simple central redirection server, which is much less likely to be compromised. (You can use a variety of techniques to force users to always go through the central redirector instead of bookmarking their favorite application server and returning directly to it.)

If you are willing to run slightly more code on the central server, this whole situation is natural for something like Kerberos. The central server is the only place that handles logins; when you log in, it passes a Kerberos ticket for you to the application server that it has determined will handle your session. The complex application never sees your credentials in any form, just a time-limited ticket it can use to get and put certain data from the backend on your behalf.

Written on 03 October 2008.
« Another consequence of the Debian OpenSSL security bug
Consider having obvious interfaces too »

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

Last modified: Fri Oct 3 00:23:04 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.