The recent versions of the FuzzBall MUCK server support SSL connections, as well as GUI interfaces via the MCP protocol. I'm not sure if MCP is anything like MXP, but I don't believe MUSHclient supports Secure Sockets Layer. Since MUCKs are based around socialising, and can be considered private, SSL connection support would be good for those of us who use MUSHclient for MUCKs.
FuzzBall's website is at http://www.belfry.com/, and the latest server can be found at http://sourceforge.net/projects/fbmuck/
Hmmm - I suppose by "private" you mean that in a one-on-one conversation you don't want other parties to eavesdrop?
The problem here is that SSL doesn't really solve that problem. It will, to a certain extent. If you are on a network then encrypted sessions will make it harder for people who are "tapping" the local subnet to listen to what you are saying, however that may not be your main problem.
This is what would happen (I guess) with a SSL-enabled session:
Player A -- (encrypted) --> MUCK -- (encrypted) --> Player B
The problem is that the MUCK will have the conversation in clear text, and I know of a couple of servers that have provision for admins to "snoop", "monitor" or "log" - that is, to view your conversations without your knowledge. The SSL provision will not stop that.
These provisions were added to help admins deal with troublesome players (eg. those that harrass others) by recording what they are doing, to be used in evidence against them.
The only really secure way to have a private conversation would be to have encryption/decryption at the client end and have the server pass through the encrypted message unchanged.
eg. You might say "SGVsbG8gdGhlcmUgSm9obg==" and someone with the correct password could interpret it.
I don't have a big problem with adding some sort of "encrypted say" to MUSHclient, excepting all the restrictions on exporting encryption from various countries.
You could conceivably do it yourself with a bit of scripting (eg find a DES routine, encrypt a message, use Base64 encoding on it, and send that).
Maybe one of the plugin authors here would like to try that? :)
Actually, I think the MUCK admins would take a rather dim view of people sending encrypted messages through the server. I'm not really concerned about the logging that /does/ go on on MUCKs. It is nessisary, as you said, to deal with problems. I trust the admins on the MUCKs I frequent, in any case. However, I would like to take advantage of FuzzBall's SSL feature to prevent eaves dropping between my computer and the server. Could it be implemented via a plug in?
Also, what of MCP?
Actually, in a world where the authorities have gone rampant invading everyone's privacy, I believe ALL communications should be encrypted, no matter how trivial the subject. :)
That don't sound like such a bad idea... The ability to send encrypted text to a Mu* and then others who have the proper password to decrypt it.
Some admins may not like this... But it would be a step to increase privecy if you do wish to send some information over a mu* that even the admins should not see.
I can't see what the major objection of admins would be. The two things a player is likely to do to annoy another player (via chatting) are:
Spamming them - you could tell if this was happening whether or not the message was encrypted, in this case the test is just "is there a lot of it?".
Offensive comments - if the comments were encrypted then you would simply refuse to decrypt them (eg. discard the password) thus you wouldn't know or care what they were.
Okay, I stand corrected. Please disregard the first sentance of my last post. :)
However, the rest of the post still stands, and doesn't seem to have been touched by anyone. If SSL connections can be handled by a plugin, I'd be more than happy to give it a shot. I program in Delphi 6.
I haven't tried this, but it might be possible to "pipe" MUSHclient through a SSL program (eg. PuTTY) thus getting the encryption in an external program. Basically, use it as a proxy server.
I really think this can be made to work. OpenSSH is an open source version of SSH, so you should be able to get it for Windows, and I am pretty sure it supports redirection to another port/server. I think they use that to do ftp via ssh. It would be something like this:
Piping is certainly possible. However, it's a pain to organise. There are sure to be many who want SSL connections -- it protects their passwords too, you know -- but not the bother of piping. Acording to the author of FB6 and Trebuchet (sp?), many people have started using the latter client, becuase of it's support for SSL and MCP (GUI for MUCKs). I'd rather stay with MUSHclient, however.
Much as I'd like to agree with Nick here, since the security still stops at the MUCK itself since you cannot guarantee that person B has the SSL, I can still say that the SSL support is a fine idea.
And yes, tunneling is a good try, after all I've seen stunnel and other things work out great, however I have a slight problem there:
I have about 5 MUCKs, MUDs MUSHs whatever that I connect to AT A TIME. Now, with OpenSSH this may be all well and good but what if I want to do all of them? I'd have to basically open up 5 ports on my computer. Now, if you're not running ZoneAlarm at home this doesn't seem like much of a problem, but the security risks of opening up a port on your PC that redirects to a FBMUCK or anything else under a secure shell with YOUR IP are just horrifying. Most people are unaware of that.
I'm not sure if OpenSSH allows for only opening the port on the local computer, or if in ZoneAlarm if I set it up so it's only able to serve to the trusted 'zone' (aka my PC) will that give it a heart attack... If someone knows SSH protocol and can write this in a plugin or even put it right into MUSHClient I'd think it'd be a lot safer. A lot of the popular telnet clients for UNIX, Windows, Mac, and other platforms (I think even Amiga) have SSH support built right in and clickable.
If I'm wrong and OpenSSH is smart about things like this please lemme know. But I'd love to continue using MUSHclient and also hide my password from being sent cleartext.
I too want the SSL support. The reason? I'm not concerned about being logged at the server level (I know exactly what logging can be done as I once installed FB6 on my OS X-based Powerbook and played with it). My concern is, rather, being sniffed on the local network level. I do not necessarily want anyone to be able to view my login password or any of my correspondence.
This is especially of importance to users of unencrypted (insecure) wireless networks. (My personal access point is as well locked down as it can be given what I have access to, but I know from wardriving experience that the vast majority of people don't encrypt their networks at all.)
MUSHclient is perfect for me ... except for SSL support.
Out of curiosity, please let me know of a server that supports SSL. Then at least I can try seeing how I can connect to it using MUSHclient, one way or another.
However I would like to comment that I am somewhat opposed to adding all sorts of extra features into MUSHclient that are effectively available elsewhere, because this is what makes reasonably small, tight, bugfree programs large, bloated and difficult to maintain. So far I have been asked to add:
SSH support
Support for <forms> tags (eg. in Pueblo) so it can behave like a web browser and you could edit room descs by filling in a form
Support for graphics (like a web browser again)
Support for ftp (MUDftp)
Support for sound
Proxy server support
Some things I can see the point of, eg. MXP and MCCP, as they need to be tightly integrated into the MUD client, and are also not particularly large (well, MXP was a fairly big project).
However most things can be achieved today another way, eg. using ftp in a separate program. I am somewhat of a fan of the Unix approach where you have lots of small "black boxes", each one of which does one thing, and does it well. If you need to combine two things (eg. ftp a compressed file) you use two of these things in tandem.
A Server that Supports SSL:
FurryMUCK -- Oldest Existing MUCK on Earth.
http://www.furry.com/
addr at muck.furry.com:8888
I understand your objection to adding more features into the program that will bloat the application, and I see the point in not wanting to add SSH support when it can be available via 'black boxes' or daemons.
MCP itself is another commonly used protocol, along with MXP, and I'm seeing both very common so MCP may be a feature that would be very good to implement. It's protocol is not all that bad, and can even in itself I think support some form of encryption if done right, but I'll leave that to you. I will provide more info if desired.
I love the UNIX approach of 'black boxes' etc, however, hear me out. It's all well and good to run PuTTY or some other SSH router to the MU* of your choice, but here are my points:
1. If you don't run it constantly, you have to start up the program and set up it's options when you want to use the MU*.
2. If you do run it constantly, what you have is basically an OPEN PORT. I hate to say it, but it's a pain to get a hardware firewall to block based on PROGRAM (you can block on the PORT but that's sometimes hard) and with software firewalls (which is all some of us can afford) none of these programs will behave if they are not given acceptable access to server to the outside internet.
Now, I'm going to go into a quick dissertation of why I don't want an open port on my computer.
If I connect to this port with MUSHclient, it reroutes it through PuTTY or Stunnel or other SSH router, to the server's SSL, and then decrypts it there. All is well, and to me it's seamless and I get encrypted transmission.
If someone ELSE connects to this port with ANYTHING, what they now have is a secure channel to this server, masquerading as ME! Which means they have full and complete access to start doing whatever they want and they won't get yelled at for 100 hack attempts or for crashing the server. I will.
As we all know from events regarding all those DDOS attacks, most of them came from average computer systems, which did not know that they were holding such 'Trojan Horses' and 'Redirects'. Which scares me, because if it had not been found out that they were, these individuals might be prosecuted.
I understand completely that maybe adding SSL support to MUSHclient is a bad idea because of bloat. However, if we can get someone skilled at writing PLUGINS or perhaps just figuring out how the plugin language works, and can get that to work with SSL, perhaps this is a much better alternative.
I hope I have swayed some thoughts, or at least provoked others, or at the LEAST wasted air.
OK, I've spent about an hour compiling and installing Fuzzball Muck, so far so good. It accepts an unencrypted connection, and an encrypted one on another port using:
openssl s_client -connect localhost:4567
However what I want to at least try is tunnel MUSHclient through this, which I can't seem to achieve right now. I can't even get ssh to work, which I suspect is because of the handshaking protocols more than anything.
I understand and agree about the open port, however I would have the source port available internally only, not to other incoming users.
eg.
MUSHclient --> openssl port 4567 -> FuzzBall 8888
Thus the openssl (or whatever) is on the local PC however only listening on port 4567 for localhost connections not internet connections.
Okay I'm a little frightened that you compiled it all yourself but okay.
You can force openSSL to be a localhost only client? If that's the case then damn the odds I'm getting openSSL for windows, and if I can get it to work I'll post my results (YMMV of course) and EOT.:)
Just one comment one the 'black box' theory.. This is fine in a unix environment where 90% of the system is dependant on those black boxes and there are a half dozen alternative boxes to employ. Under windows the effect of black boxing is the exact opposite. Often the same box will break going from one system to the next exa: there is a bug for instance in CreateProcess on 9x systems that results in a console app inheriting the stdin/stdout/stderr pipes from the calling program, even when you tell it not to - result NT/XP will work right if you fail to take this into account, but 9x gives no output. The other problem is availability.
There are one or two programs I would like to get for use with a program called POVRay that are impossible to find anymore. They also took the 'our program does just X and to extend it use Y approach'. The result has been an extremely good 3D photorealistic renderer, that takes as much time to learn to use properly as coding C++, because there are very few graphical front ends and even Moray, which was specifically designed to be used with it, doesn't correctly support all the features of the prior version, let alone the current one.
If you want to black box things you have to do one of three things. A) be absolutely sure that there are real alternatives around you can use that you are reasonably sure will still be available in a year from now, B) encourage people to design them and provide a plae to keep them 'along side the program' or C) code them yourself.
The problem is that A) is nearly certain to not be true, B) isn't entirely possible with your server set up, so stuff end up on other site, where it may not be available later and C) means time spent working on the black boxes instead of the client. It is imho better to find eligant solutions to some of these things internally than rely on the assumption that a windows product can function based on a black box design, especially considering the prevalence of item A above.
That said.. There may be some things like the graphics support that can be done the easy way. For instance as I stated in another thread, I have a fairly decent browser that is a mere 455k, runs quite fast and does everything IE can (using the IE core). My only complaint with it is that since it was designed to be used in a game, it doen't correctly keep track of the last pages scroll position and pop-up windows are opened in the full IE, which I hate. It wouldn't be that hard to make a black box that implimented a simple browser window to support nearly anything a person wanted to throw at the client, with the exception of full pages (and if you wanted to give it back, forward, stop, etc. buttons...). I wouldn't mind in the least having such a thing 'packaged' with the client as a black box, but I can't see myself relying on the full IE or something 3rd. party that I can't find a week from now.
I am inclined to agree with most of what Magnum says, however there are cases where something that is complex to implement, and is only wanted by a handful of players, might be better done as an external program. Once you have a program that works, you can always keep that copy along with MUSHclient.
MUSHclient itself is a blend of hand-written stuff (eg. XML parser), compiled-in routines (eg. regular expression handling), and external routines (eg. spell checker, scripting support).
Okay, here goes my only response: I can't seem to figure out how to make these programs work right. So, I'd like to ask the question:
Nick, do you feel it is possible to do this with Plugins, or is that not possible? If so, lemme know how to write one (I checked the documentation but could not do that, it didn't seem to exist, the plugin wizard) so, I think I could port the C++ code over if there's a standard plugin system to code in.
I don't really see this working in a plugin. You need to intercept the incoming encrypted text and decrypt it, and decrypt outgoing text. MUSHclient doesn't allow you to change the incoming text in this way.
The way I see it working is for a SSL program to act as a proxy, not that I got it to work yet, but it would go like this:
Client -> Request link to proxy port using local 127.0.0.1.
Proxy -> Checks is from local and tells client link
established if not remote.
Client -> Sends the server and port for the remote location
to proxy.
Proxy -> Attempts to connect to remote addr:port.
If successful -> send client a 'success' message.
Client -> Begins 'normal' telnet operation.
In theory at least this is how it 'should' work, unless some clown out there came up with some stupidly more complex method. I would try writing a proxy to do this stuff myself, assuming I could find the encryption info, but mushclient doesn't support the above transaction needed to establish the communications. I do however have to wonder what it is I am missing that makes it so hard to impliment.. :p But then I am by no means an expert on this. ;)
How's this for luck?
Got it to work, and here's the main explanation with security.
Please note that other options are available at the website
http://www.stunnel.org/
where you can find out other ways to configure Stunnel.
Instructions:
Obtain Stunnel from the above address.
Go to the Download Tab, and from there go to the download directory.
Currently available highest version is "stunnel-4.03.exe"
Put this anywhere you like. I put mine in a folder in Program Files, and set up a StartUp folder link to it, so that it would start every time.
If you're running NT, 2k or XP you may wish to set up Stunnel as a service. Look on the website.
You'll need the OpenSSL library for the encryption. In the download directory, go to the OpenSSL directory of your choice, preferrably the highest version. As of this writing, the highest version in that directory is openssl-0.9.6g. Download the zip file within, it will contain all the files you need. Extract that file to the same folder as you put Stunnel in.
Now, in notepad, create a new text file. Save it in the same directory. Remember the filename.
This text file will be our configuration file. The following options should be first in the file.
client = yes
output = out.log
I put client = yes so the program would know it's designed to tunnel to a server with SSL, and I put output = out.log because I wanted a definite file that the Stunnel program would record its output to. This can be changed or left out. client = yes is required.
Now for the fun part. You'll need to set up each service you wish to connect to with MUSHClient. I'll walk you through it.
Simplest way:
(Any Line with a # at the beginning is a comment and not necesary)
[servicename]
#This is the name of the service in stunnel's logs.
#whatever you wanna call it. I call them muck1 muck2 etc.
connect = muck.muck.com:9999
#This is obvious. 9999 should be the SSL port.
accept = localhost:5555
#5555 to be replaced with whatever port you wish.
Remember the accept lines, those are what you configure MUSHclient to connect to. 'localhost' at port 5555 and 5556.
Please note that further options can be gotten from the stunnel website (see the 'man page listing') or from running the command line 'stunnel -help'
By the way, this way works such that in ZoneAlarm, set stunnel to be allowed to access the internet and local, be a server to local, and block it from being a server to internet. In the newest version of ZoneAlarm, the first three boxes are check-marks, and the fourth is an X.