Use SSL with PennMUSH Revised: 11 August 2003 As of version 1.7.7p17, PennMUSH supports SSL connections when linked with the OpenSSL library (http://www.openssl.org). The following features are supported: * Encrypted sessions using SSLv2, SSLv3, and TLSv1 protocols with ephemeral Diffie-Hellman keying. * Authentication of the server via certificates * Authentication of the clients via certificates This document explains how to use SSL with PennMUSH, and covers the following issues: I. An SSL overview II. Compiling with OpenSSL III. Mush configuration overview IV. Installing a server certificate (required) V. Using client certificates for authentication (optional) VI. Legal issues I. An SSL overview When an SSL client connects to an SSL server, it performs a "handshake" that looks something like this: Client says hello, offers a menu of cipher options Server says hello, selects a cipher. Server presents its certificate, requests a client certificate Client presents a certificate (or not) Client and server exchange cryptographic session keys The server is identified to the client by a certificate, an encoded text that gives the server's name and other attributes and is signed by a certifying authority (CA), like Verisign. The client checks that the signature is by a CA that it trusts, and may perform other validation on the certificate (e.g., checking that the hostname in the certificate matches the hostname it's trying to connect to). If the client chooses to present a certificate (or is required to by the server), the server will likewise attempt to validate it against its list of trusted CAs, and may perform other verification. Once session keys have been exchanged, the client and server can communicate secure from eavesdropping. II. Compiling with OpenSSL The Configure script distributed with PennMUSH automatically detects the OpenSSL libraries (libssl and libcrypto) and attempts to link them into the executable, defining HAS_OPENSSL in config.h. If you have SSL libraries but wish to avoid linking with them, give the -D no_openssl argument to Configure when you run it. You can compile the OpenSSL libraries yourself from source code at http://www.openssl.org. OpenSSL can also be compiled on Windows, and you could add its libraries to the PennMUSH project file and link it in that way. Noltar has done this succesfully; it requires compiling both OpenSSL and PennMUSH in /MD (multithread dll) mode. III. Mush configuration overview mush.cnf includes three directives that configure the SSL support: ssl_port selects the port number for the MUSH to listen for SSL connections. Any port number other than the MUSH's ordinary listening port can be chosen (subject, of course, to other system restrictions on choosing port numbers). ssl_private_key_file specifies the name of the file (relative to the game/ directory if it's not an absolute path) that contains the MUSH server's certificate and private key. See section IV below. ssl_ca_file specifies the name of the file that contains certificates of trusted certificate authorities. OpenSSL distributes a file containing the best known CAs that is suitable for use here. If you comment this out, client certificate checking will not be performed. ssl_require_client_cert is a boolean option that controls whether the MUSH server will require clients to present valid (that is, signed by a CA for which ssl_ca_file holds a certificate) certificates in order to connect. As no mud clients currently do this, you probably want it off. See section V below. IV. Installing a server certificate SSL support requires that the MUSH present a server certificate (except as discussed below). You must create a file containing the certificate and the associated private key (stripped of any passphrase protection) and point the ssl_private_key_file directive at this file. This file should only be readable by the MUSH account! How do you get such a certificate and private key? Here are the steps you can use with openssl's command-line tool: 1. Generate a certificate signing request (mymush.csr) and a private key (temp.key). You will be asked to answer several questions. Be sure the Common Name you request is your MUSH's hostname: $ openssl req -new -out mymush.csr -keyout temp.key -passin pass:foobar 2. Strip the passphrase off of your private key, leaving you with an unpassworded mymush.key file: $ openssl rsa -in temp.key -out mymush.key -passin pass:foobar $ rm temp.key 3. Send the certificate signing request to a certifying authority to have it signed. If the CA needs the private key, send the passphrased one. The CA will send you back a certificate which you save to a file (mymush.crt) 4. Concatenate the certificate with the unpassworded private key and use this as the ssl_private_key_file: $ cat mymush.key >> mymush.crt Commercial CAs like Verisign sign certificates for a yearly or two-yearly fee that is probably too steep for most MUSH Gods. Instead of using a commercial CA, you can generate a self-signed certificate by changing step 1 above to: $ openssl req -new -x509 -days 3650 -out mymush.crt -keyout temp.key -passin pass:foobar A self-signed certificate is free, but clients that attempt to validate certificates will fail to validate a self-signed certificate unless the user manually installs the certificate in their client and configures it to be trusted. How to do that is beyond the scope of this document, and highly client-dependent. Another option is to skip the use of a certificate altogether. If you don't provide an ssl_private_key_file, the server will only accept connections from clients that are willing to use the anonymous Diffie-Hellman cipher; it is unknown which clients are configured to offer this. This provides clients with no security that they are actually connecting to your server, and exposes them to a man-in-the-middle attack, but requires no work on your part at all. Hosting providers or other parties may one day provide CA service to PennMUSHes for free. When they do, you'll have to install those CAs' certificates in your client as trusted in order to have the server's certificate validate, but if a few CAs certify many MUSHes, this is efficient. V. Using client certificates for authentication If you provide PennMUSH with a file containing the certificates of trusted CAs (using the ssl_ca_file directive in mush.cnf), it will, by default, request that clients present certificates when they connect. Clients that do not present certificates will still be allowed to connect (unless ssl_require_client_cert is enabled). Clients that do present certificates must present certificates signed by a trusted CA, or they will be disconnected. Both valid and invalid certificates are logged (to connect.log and netmush.log, respectively). If you were really serious about this, you probably would issue your own certs and not allow Verisign, etc. certs. You'd probably want to have the server validate extra attributes on each client cert, which should probably include the player's dbref and creation time. This is left as an exercise for the reader for now. VI. Legal issues OpenSSL is used in PennMUSH and may be redistributed with PennMUSH under the following license(s): OpenSSL License --------------- /* ==================================================================== * Copyright (c) 1998-2001 The OpenSSL Project. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in * the documentation and/or other materials provided with the * distribution. * * 3. All advertising materials mentioning features or use of this * software must display the following acknowledgment: * "This product includes software developed by the OpenSSL Project * for use in the OpenSSL Toolkit. (http://www.openssl.org/)" * * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to * endorse or promote products derived from this software without * prior written permission. For written permission, please contact * openssl-core@openssl.org. * * 5. Products derived from this software may not be called "OpenSSL" * nor may "OpenSSL" appear in their names without prior written * permission of the OpenSSL Project. * * 6. Redistributions of any form whatsoever must retain the following * acknowledgment: * "This product includes software developed by the OpenSSL Project * for use in the OpenSSL Toolkit (http://www.openssl.org/)" * * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED * OF THE POSSIBILITY OF SUCH DAMAGE. * ==================================================================== * * This product includes cryptographic software written by Eric Young * (eay@cryptsoft.com). This product includes software written by Tim * Hudson (tjh@cryptsoft.com). * */ Original SSLeay License ----------------------- /* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com) * All rights reserved. * * This package is an SSL implementation written * by Eric Young (eay@cryptsoft.com). * The implementation was written so as to conform with Netscapes SSL. * * This library is free for commercial and non-commercial use as long as * the following conditions are aheared to. The following conditions * apply to all code found in this distribution, be it the RC4, RSA, * lhash, DES, etc., code; not just the SSL code. The SSL documentation * included with this distribution is covered by the same copyright terms * except that the holder is Tim Hudson (tjh@cryptsoft.com). * * Copyright remains Eric Young's, and as such any Copyright notices in * the code are not to be removed. * If this package is used in a product, Eric Young should be given attribution * as the author of the parts of the library used. * This can be in the form of a textual message at program startup or * in documentation (online or textual) provided with the package. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * "This product includes cryptographic software written by * Eric Young (eay@cryptsoft.com)" * The word 'cryptographic' can be left out if the rouines from the library * being used are not cryptographic related :-). * 4. If you include any Windows specific code (or a derivative thereof) from * the apps directory (application code) you must include an acknowledgement: * "This product includes software written by Tim Hudson (tjh@cryptsoft.com)" * * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * The licence and distribution terms for any publically available version or * derivative of this code cannot be changed. i.e. this code cannot simply be * copied and put under another distribution licence * [including the GNU Public Licence.] */