Wandering Thoughts archives

How our DHCP registration portal redirections work

Like other places, we have an automatic DHCP registration portal (to use the term I've heard). In the abstract, you plug your new laptop into our laptop network, try to visit some website, and instead wind up on a registration web page. You supply your local login and password, the machine you're using is registered as yours, and then you can go on to get Internet access.

(Some registration portals will automatically send you on to whatever website you were trying to visit. Ours was a quick hack, so we don't try to support that.)

There's a slightly complicated dance of redirections involved in the web server portion of this process, so here's how it works. First, there's three IP addresses involved; let's call them Inside-1, Inside-2, and Outside. The two Inside addresses are on our laptop network and the Outside IP is a public IP on our normal network. Conceptually, separate web servers run on each IP (practically, it is one Apache instance with three IP-based virtual hosts).

Then:

• on Inside-1, there is a http server that gives temporary redirects to the public name of our registration portal. Some magic arranges for unregistered DHCP clients to be told that this name's IP address is Inside-2.

• on Inside-2 there is a http and a https server. The https server has the registration portal; the http server redirects to the https server.

• on Outside, there is both a http and an https web server that redirect visitors to our non-portal DHCP registration system. The public name of our registration portal points here.

We need two inside IPs because we need people's attempts to talk to random https URLs to fail outright. If someone asks for https://somesite/ and we actually give them something to talk to, there is no way to avoid them getting a scary certificate mismatch warning; this is either unnecessarily alarming or bad training for our users or both. Thus, it's better that their browsing fail with a 'website not responding' browser error, and the only fully reliable way to get that is to have an IP address that has no https server on it at all.

In theory one could shim in the initial portal web page by just having Outside-1 reply to all requests with it. There's two reasons not to do this; first, we need to redirect to an https page at some point anyways, and second, I expect that there's client software that doesn't like it when it requests some URL that it expects to be in some specific format and instead gets an HTML page. A feed reader that polls feeds on startup (or when a network connection appears) might get quite upset, for example. Such software may still malfunction when given a temporary HTTP redirection, but at least we've tried to do the proper thing.

(I suppose there's a third reason: if you do it by shimming in a page, you're training your users to expect internal administrative web pages to appear on random external URLs. This sounds like a gift to phishers to me.)

Theoretically we don't need a webserver on Outside, but I was concerned that people would turn 'go to this website name to get registered' into local folklore and then try to apply it even when they were outside the laptop network. Since the machine needed an outside IP address anyways, it seemed friendlier to run a webserver there.

SSL certificates require proper domain names

Here's one of those little petty irritations with SSL: if you want to get a SSL certificate out of a CA without at least a lot of slow discussion, the hostname needs to be in one of your official domains. (It wouldn't surprise me if there were CAs that required the name to exist in your public DNS.)

This may be a local peculiarity, but we prefer to put machines that are on private networks into a set of local private domain names under a top level domain that doesn't exist in the outside world. Among other things, using such names makes it immediately clear if a machine is an internal one or not, and avoids various leaks that tend to cause problems.

(Put simply, our rule is 'private IP, private hostname; public IP, public hostname'.)

But, of course, we can't get SSL certificates for machines with such private names. This is totally fair, but at the same time kind of inconvenient every so often.

(It's fair because if we could get such certificates for our machines, necessarily someone else could also get such certificates for our machines.)

I now wonder if large organizations set up their own CA (and have the CA key installed on all of their machines) so that they can avoid this. Probably this is not a specific concern, although there are other reasons they might want their own CA.

(For the sufficiently cautious, you can worry about the information leak inherent in telling the CA about various of your internal hostnames by asking for SSL certificates. After all, if they're useful hostnames for you they're probably at least somewhat revealing for outsiders.)

A trick to testing https setups on test machines

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.