How do mud servers typically implement SSL/TLS? Specifically:
Must it use a separate port and assume SSL/TLS support by anything connecting to that port?
Is there a STARTTLS-style telnet negotiation followed by SSL/TLS negotiation?
Is there a commonly-accepted unofficial STARTTLS-like telnet negotiation that most SSL-enabled mud clients can handle?
Is there a literal (plaintext) STARTTLS command preceding SSL/TLS negotiation such as is commonly available on SMTP servers?
I've spent some time searching Google for telnet SSL/TLS support details, but mostly turned up threads by people new to encryption asking how to do STARTTLS negotiation to an SMTP server via telnet. I've also searched this site and found one vague reference to STARTTLS here.
Are there any available MUD codebases where I could examine such implementation? I don't care whether the codebase uses OpenSSL, gnutls, LibreSSL, or NSS at this early stage.
IMHO it's a waste of time to try to inline some kind of negotiation on top of an existing unencrypted telnet port. Just open another port and have it be dedicated SSL, and tell ssl clients to connect there. If you export http directly out of the server you'll need to do that anyway to handle https requests. Examples:
I can agree that the dedicated port is simpler and even preferable. But if there's an effective way to negotiate or detect SSL on the same port, I'd still like to know what my options are.
In a more security-conscious context, the dedicated port has a slight advantage – with STARTTLS, a client may fail to inform its user that negotiation failed (or was not offered), and fall back to an unencrypted connection. With the dedicated port, a failure to establish an SSL session is effectively a failure to connect.
It's mostly a waste of time because nobody bothers with any kind of TLS over TELNET. TELNET is a dinosaur protocol, and the client isn't even installed (by default) in the last 3 versions of Windows. Anyone who cares at all about a secure connection just uses SSH.
So, you have three options. You can waste a lot of time and effort trying to auto-detect an SSH connection over the same port you use for TELNET. You can run an SSH connection on a seperate port and require the user enter that port, just like they currently have to enter your psuedo-TELNET port. Or, you can run on the actual TELNET and/or SSH ports (23 and 22, respectively) and move the actual telnetd or sshd services elsewhere.
For anyone interested, at the telnet level it looks like you negotiate for authentication type 0x07, and if that succeeds you initialize an SSL session. (0x07 is technically non-standard, not officially accepted by the IETF but actively in use in the wild.)
That's all I need to know for the server end. The remaining question I have is whether any mud clients bother with this.
MUSH appears to use OpenSSL, somewhat complicated looking implementation. Haven't seen any server side GNUTLS implementations, looked into it myself but couldn't get it to work.
There's no commonly accepted TELNET negotiation. Would be helpful to have one as MCCP should be mostly useless over SSL as it would be better to compress data before encrypting it. Not sure if any SSL enabled MUDs know the compression ratio of MCCP using the traditional SSL implementation.
STARTTLS is a fairly complex negotiation, could be done fairly simple over telnet though and assume there won't be any man in the middle attacks. MCCP in itself adds some protection, so one option is to extend MCCP to compress client commands.
I think most servers use stunnel… biggest drawback is that the player IP will show as localhost, though there may be a workaround for that?
In foreground mode stunnel logs to stderr; you could capture and parse that output for fairly accurate mappings back to the true IP addresses. Depending on how much detail can be logged, it might get dicey when multiple clients connect within moments of each other.
I am incredibly confused. Why on earth would you do this instead of just linking against libssl and using SSL functions on your ssl enabled sockets? Using stunnel for this is like flying from LA to Vegas with stopovers in Tokyo and Jerusalem. Are the stock codebases seriously this retarded to work with? We've had SSL socket support in our stack since somewhere around 1999.
It's not the way *I* would go, but for some people the approach would have value. You have to balance the relatively minor runtime overhead of stunnel vs the developer time put into utilizing an SSL library (assuming your codebase is in C).
To begin with, you wouldn't need to write any SSL code, certificate handling is for your SSL tools to worry about instead of your code, your project would have fewer build dependencies, and your probably-single-threaded stock codebase can remain single-threaded without penalty.
(I think I'd use socat rather than stunnel, btw, it's a much more powerful tool)