Persistant SSL connections

Submitted by raevnos on Sun, 2011-05-15 18:11

It still needs some more work before getting checked in for p5, but I have SSL connections that persist across @shutdown/reboots instead of getting dropped up and running. Only a few years after working out the basic design. Can't work faster than that!

The big problem has been that OpenSSL doesn't have a way of saving internal state across a reboot so that the same connections can be reused. In general, from a security standpoint, this is a good thing. It's just frustrating for players who use SSL connections. The solution is to use a proxy process to handle the SSL connections.

Shortly after reading the configuration files, the mush now forks a child process if it's starting up for the first time and not rebooting. That child (The slave) listens for SSL connections, accepts them, and for each one opens a new, unencrypted connection to the main mush process and pipes data between the two. Currently, instead of a completely separate executable (Like info_slave for hostname lookups), it shares the same binary as the main mush, just doing its own thing instead of going on to read the databases and such. I might change this to be like info_slave, but for now it was convenient to be able to access the ssl-related configuration options directly instead of having to pass them to the slave via command line arguments or something.

The mush and ssl slave communicate over a unix socket (An entity that lives in the filesystem but is opened and manipulated with the socket API). It's unencrypted, but if somebody can listen in on it, they have enough control over the host's kernel to do far far worse — plus the data isn't encrypted in the mush anyways as it is now. This type of socket is far more efficient than IP ones for local connections, and allows for some nifty things I'm not currently doing but might.

One part I still need to do is passing the remote host address to the mush for sitelock checks and the like. Right now, all SSL connections look like they're coming from localhost. I'm still debating doing the hostname lookup in ssl slave, or passing the IP address to the mush and then to info slave. It's simpler to do it in the ssl slave.

Instead of rolling my own event loop setup in ssl slave to do things when various sockets have data waiting or can be written to, I'm using the third-party libevent library. This makes it dead easy — libevent has a system where you can write data to a buffer and have it sent to the underlying socket once that socket can be written to without blocking, doing all the fiddling with partial writes and keeping track of what's still pending for you. Also, it supports OpenSSL sockets. I wouldn't mind using it in the main mush process, actually, instead of our current event loop and network i/o code.

The eventual end result to people who use SSL connections is that they'll be able to connect to games, not get kicked on reboots, and have no way to tell they're not connected directly to the mush.