A trick to testing https setups on test machines

September 17, 2009

Suppose that you are building a new version of an existing machine that runs a https web server (perhaps you are rebuilding it under a different base OS version). Of course you want to test it before you switch it into production, which means that it needs a new temporary name of some sort. And a different name means problems with the SSL certificates for your https web server instances.

(There are people who will tell you, in all seriousness, that you should have a completely independent, isolated test network so that you can give your new machine the exact same name and IP address as it will have in production. These people either have very simple systems or have much, much larger budgets than I have ever been near.)

It turns out that there is a way to get around these problems: the SSL certificate validation process only cares about what the client sees as the IP address for the certificate's hostname, not what the server thinks it is. As long as your test client machines will resolve 'prod.yourco.com' or the like to a suitable IP address on your new machine, your new machine can carry the real SSL certificates that will be used in production, clients can be tested using the official name, and no one will get any certificate errors.

There are various ways to do this depending on what the client machines are running; on Unix, you can just edit /etc/hosts and then make sure it's consulted before DNS. I believe that other operating systems have similar features.

(Although it's a tempting hack, I personally think that building your own DNS server to return carefully crafted answers to your test machines is perhaps going a bit too far.)

The same trick generalizes to other SSL-protected protocols such as the various forms of SSL'ized IMAP, and may be even more handy there (where common clients may not actually give you any way to override certificate problems). It even works for ssh, in case you have an automated ssh-using system that you need to test.

(The in a nutshell version of why it works this way for SSL is simple: no one wants to pay certificate vendors yet more money every time they change the IP address (or, for large places, addresses) of their web servers.)

One can also take advantage of this to commit some interesting hacks with various forms of split-horizon DNS resolution, where the same nominal name can go to different machines that all carry the same SSL certificate but behave quite differently.


Comments on this page:

From 128.210.169.74 at 2009-09-17 08:40:35:

So what you're saying is that if you want to spoof a bank website, the first step is to modify the victims hosts file?

By cks at 2009-09-17 09:37:22:

If you have the bank's SSL certificate and want to spoof the bank's site, yes. Or you can use one of the various DNS hijack attacks to change the DNS answers that the victim sees, which may be easier.

(In practice attackers with that level of access to the victim's machine don't bother spoofing the bank site; instead they just use a keylogger or the like and let the victim talk to the real site.)

Written on 17 September 2009.
« Some kernel lockd NFS error messages explained
Are you sure it's a C string? »

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

Last modified: Thu Sep 17 00:50:36 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.