StunTour: SSL Enabler for mIRC

Background

Being able to connect securely to SSL-enabled IRC chat servers is something that remains difficult for most Win32 IRC applications. Very few IRC clients natively support connecting to servers with SSL, and the few that do are generally of very poor quality.

If you want to securely use a client such as the popular Win32 mIRC client, then you must generally resort to running a separate tunneling application (such as stunnel) and then make mIRC to connect to a port bound to a localhost listening socket. This has the added overhead of requiring another application to be running at all times, and makes it difficult to change what server you connect to since you must manipulate the destination of the tunnel application. Also, running an external program is inconvenient and prone to problems.

What is it? And what does it require?

After growing tired of fighting with stunnel, I decided to write a mIRC plugin DLL that would natively allow it to connect to SSL-enabled IRC servers. StunTour is a utility that automatically intercepts connections with destination port of 994. This allows you to connect to IRC servers using a secure SSL connection (provided that the server supports connecting over SSL on port 994).

There are currently very few IRC networks that support SSL connections. However, one IRC network that this program has been tested with is CuckooNet IRC (irc.cuckoo.com or irc.distributed.net), which is the IRC network run primarily for the users of distributed.net.

Due to the hooking technique that is being used, this program is only compatible with Windows 2000 and Windows XP machines (and probably Windows Server 2003).  It will not work on Windows 95, Windows 98, Windows Me, or Windows NT 4.

How do I load it?

  1. You can run the STUNRUN.EXE helper utility instead of MIRC.EXE when you want to start mIRC. This is the easiest and the recommended method.  This causes mIRC to be automatically launched with the DLL pre-loaded. You should ensure that mIRC is not already running when you do this.
    	STUNRUN.EXE
  2. You can start MIRC.EXE as you normally would, but load the DLL manually in mIRC with the command (before you connect):
    	/dll stuntour.dll load_stunnel
    
  3. You can start MIRC.EXE as you normally would, but have the DLL loaded automatically with scripting. Simply add this line to your "Remote" script tab:
            on *:start: { /dll stuntour.dll load_stunnel }
    

    Note that you cannot put a the dll load lines in the "Perform" script box since those commands are run after mIRC successfully connects to the server.

If you use the manual loading techniques (methods 2 or 3) and want to unload the library hooks manually for some reason without having to exit mIRC, use the following command:

	/dll -u stuntour.dll

Okay it's loaded, how do I use it?

StunTour is a automatically intercepts connections with destination port of 994. Simply configure mIRC to directly connect to the IRC server on port 994 and that connection will be automatically wrapped in an SSL encrypted tunnel.  Actually, by default StunTour currently allows any of the following ports to be used:

You can also customize the list of ports the StunTour will intercept, in case you need to connect to a server using a different port (see below).  Contact me by e-mail if your IRC network uses a port that is not listed and I'll add it to a future version so that it will be intercepted for new StunTour users by default, as long as I don't think that the port number overlaps with a commonly used plaintext port number.  However I greatly recommend that you to try to contact the operators of your IRC network and encourage them to use the RFC allocated standard port of 994 first.

Some of the ports listed above (such as 7000) are unfortunately also used by other networks for plaintext IRC traffic.  If you attempt to connect to such a network while StunTour is active, mIRC will attempt (and fail) to establish a SSL connection.

If you attempt to make IRC connections to a server on any other port, then a normal unencrypted connection will be made.  Since mIRC 6.x allows multiple simultaneous connections to different servers to be made, this allows you to be connected to both SSL and non-SSL servers using the same instance of mIRC.  Similarly, you can be connected to multiple SSL servers as well.

How can I connect to an IRC server that uses SSL on another port?

Thre are two ways to tell StunTour to perform automaticic SSL interception on additional port numbers:

  1. Use the dynamic-library command to add interception for only this instance of mIRC (will not be remembered for future launches of mIRC/StunTour):
  2. Alter your registry to allow StunTour to always perform interceptions on certain port numbers.

How can I always accept SSL certificate confirmation prompts?

Each time you connect to an IRC server over SSL, StunTour displays a confirmation dialog that includes details about the server's certificate, the issuer of the certificate, the address of the server, and other pre-validation information. If you ensure that the "remember this decision" checkbox is checked before clicking the "Yes" button, StunTour will no longer prompt you for connections made to a server utilizing that certificate.

Alternatively, you can disable confirmation dialogs for all certificates by using REGEDIT (Registry Editor) to navigate to this location:  HKEY_CURRENT_USER\Software\Bovine Networking Technologies, Inc.\StunTour; then change the DWORD value "AlwaysAllowAnyCert" to be non-zero. Understand that doing this is insecure since it can allow "man-in-the-middle" attacks to intercept the connection establishment and use an alternate certificate without you noticing.

 

Advanced-users only:

How do I use client-side certificates?

Most SSL IRC servers are not configured to pay attention to client-side certificates, so this item is of little interest to most people.  However some servers require you to use a pre-generated certificate in order to prove your identity before you are allowed to connect.  Some IRC networks have a process where they will generate a certificate and key for you and ask that you use them when connecting.  Other IRC networks allow you to use your own certificate and you simply need to upload the public certificate to the server (such as via a web page) before you attempt to use it.

When StunTour loads, it checks for the existence of two files (the private key--stunkey.pem; and the public certificate--stuncert.pem) within the same directory where mIRC's EXE is located.  If these two files are found, then they will be loaded and used to identify your client when connecting to any SSL IRC server. (Note that the client-side certificate will also be used for any SSL-encrypted DCC operations initiated to other clients--see section below.)

The private key file and certificate file must be in "PEM" encoded format. There must not be a passphrase on it, since StunTour does not currently offer a way to interactively prompt for the passphrase.

If you want to generate your own "self-signed" certificate, you can use then OpenSSL command-line tool to generate it using two command-lines similar to the following.

 

How do I use DCC (direct client-to-client communications)?

StunTour allows SSL-encrypted DCC chat between two clients by adding support for the special "DCC SCHAT" (instead of "DCC CHAT") CTCP command.  The SCHAT command is known to be natively supported by kvirc, as described in http://www.kvirc.de/docu/doc_dcc_connection.html

SSL-encrypted DCC file transfers are not currently supported by StunTour, but will be added in a future version.

In order to initiate an SSL-encrypted DCC chat to another user, do the following:

  1. You must have a client-side certificate installed for yourself (see the above section for details). That client-side certificate will be displayed to the user that you connect to and the information in the certificate will be used by that user to decide whether to accept the communication.
  2. Issue the following command at a mIRC prompt to inform StunTour that the next outgoing DCC chat should be converted into a secure SSL request:  /dll stuntour.dll secure_dcc_chat
  3. Initiate the DCC chat request to the other user using standard mIRC methods (either using pull-down menus in mIRC, or via the "/dcc chat username" command).  Note that the user you connect to must be using StunTour, or another IRC client that natively support the "DCC SCHAT" standard.

In order to receive an SSL-encrypted DCC chat from another user, do the following:

  1. You must have loaded StunTour for your mIRC session (or be using another IRC client that natively supports SSL and the "DCC SCHAT" standard).
  2. You do not necessarily need to have installed a client-side certificate for receiving connections.
  3. When you receive the incoming DCC SCHAT request, mIRC will prompt you to accept or ignore the request.
  4. When you click accept, you will see another dialog box from StunTour asking you to accept a connection from someone with the certificate details that are displayed. (If you have already told StunTour to always accept that certificate, you will not see the certificate confirmation prompt.)

 

How does it work?

I'm using a the OpenSSL library for the implementation of the encryption layer, and the Microsoft Detours library to perform API interception/hooking on several of the standard Winsock functions. From mIRC's perspective, it is still opening an unencrypted connection to the server, but my code is doing the necessary work to ensure that the actual connection is actually SSL encrypted. I do this by using the Microsoft Detours library to intercept the Winsock connect(), send(), recv(), etc functions and making them utilize the OpenSSL equivalents when a connection is made to a remote server on port 994.

This product includes cryptographic software written by Eric Young (eay@cryptsoft.com)

 

Why is it named "StunTour"?

The name is simply a shortened contraction of "SSL tunnel detour". The word "detour" is simply the name of the API hooking library that I'm using to perform some of the critical network interception calls.


Jeff Lawson <jlawson@bovine.net>