<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
I have a problem using stunnel with mIRC:<br>
<br>
I was using a pretty old version of stunnel.exe that was packed with a
mIRC script and could be ran as a command-line-only application without
a configuration file (supplying all necessary informations parameters).<br>
I know that current mIRC version have their own ssl support, but I
prefer an old version without because it has much better performance.<br>
The old one was used by "stunnel.exe -c -d localhost:<localport>
-r <irc-server-ip>:<irc-server-port>" in command line and
"/server localhost:<localport>" in irc.<br>
<br>
A few of my servers stopped supporting an old ssl version, this old
stunnel.exe is no longer compatible to the new (open)ssl dll files and
so I had to upgrade to the most recent version of stunnel - and I have
some problems make it run properly.<br>
<br>
Here you can see my configuration file (stunnel.conf):<br>
<blockquote><font color="#33cc00"><small>; Sample stunnel configuration
file for Win32 by Michal Trojnara 2002-2012</small><br>
<small>; Some options used here may be inadequate for your particular
configuration</small><br>
<small>; This sample file does *not* represent stunnel.conf defaults</small><br>
<small>; Please consult the manual for detailed description of
available options</small><br>
<br>
<small>;
**************************************************************************</small><br>
<small>; * Global
options�������������������������������������������������������� *</small><br>
<small>;
**************************************************************************</small><br>
<br>
<small>; Debugging stuff (may useful for troubleshooting)</small><br>
<small>;debug = 7</small><br>
<small>;output = stunnel.log</small><br>
<br>
<small>; Disable FIPS mode to allow non-approved protocols and
algorithms</small><br>
<small>;fips = no</small><br>
<br>
<small>;
**************************************************************************</small><br>
<small>; * Service defaults may also be specified in individual
service sections� *</small><br>
<small>;
**************************************************************************</small><br>
<br>
<small>; Certificate/key is needed in server mode and optional in
client mode</small><br>
<small>;cert = stunnel.pem</small><br>
<small>;key = stunnel.pem</small><br>
<br>
<small>; Authentication stuff needs to be configured to prevent MITM
attacks</small><br>
<small>; It is not enabled by default!</small><br>
<small>;verify = 2</small><br>
<small>; Don't forget to c_rehash CApath</small><br>
<small>;CApath = certs</small><br>
<small>; It's often easier to use CAfile</small><br>
<small>;CAfile = certs.pem</small><br>
<small>; Don't forget to c_rehash CRLpath</small><br>
<small>;CRLpath = crls</small><br>
<small>; Alternatively CRLfile can be used</small><br>
<small>;CRLfile = crls.pem</small><br>
<br>
<small>; Disable support for insecure SSLv2 protocol</small><br>
<small>options = NO_SSLv2</small><br>
<small>; Workaround for Eudora bug</small><br>
<small>;options = DONT_INSERT_EMPTY_FRAGMENTS</small><br>
<br>
<small>; These options provide additional security at some
performance degradation</small><br>
<small>;options = SINGLE_ECDH_USE</small><br>
<small>;options = SINGLE_DH_USE</small><br>
<br>
<small>;
**************************************************************************</small><br>
<small>; * Service definitions (at least one service has to be
defined)���������� *</small><br>
<small>;
**************************************************************************</small><br>
<br>
<small>; Example SSL server mode services</small><br>
<br>
<small>;[pop3s]</small><br>
<small>;accept� = 995</small><br>
<small>;connect = 110</small><br>
<br>
<small>;[imaps]</small><br>
<small>;accept� = 993</small><br>
<small>;connect = 143</small><br>
<br>
<small>;[ssmtp]</small><br>
<small>;accept� = 465</small><br>
<small>;connect = 25</small><br>
<br>
<small>; Example SSL client mode services</small><br>
<br>
<small>;[gmail-pop3]</small><br>
<small>;client = yes</small><br>
<small>;accept = 127.0.0.1:110</small><br>
<small>;connect = pop.gmail.com:995</small><br>
<br>
<small>;[gmail-imap]</small><br>
<small>;client = yes</small><br>
<small>;accept = 127.0.0.1:143</small><br>
<small>;connect = imap.gmail.com:993</small><br>
<br>
<small>;[gmail-smtp]</small><br>
<small>;client = yes</small><br>
<small>;accept = 127.0.0.1:25</small><br>
<small>;connect = smtp.gmail.com:465</small><br>
<br>
<small>; Example SSL front-end to a web server</small><br>
<br>
<small>;[https]</small><br>
<small>;accept� = 443</small><br>
<small>;connect = 80</small><br>
<small>; "TIMEOUTclose = 0" is a workaround for a design flaw in
Microsoft SSL</small><br>
<small>; Microsoft implementations do not use SSL close-notify alert
and thus</small><br>
<small>; they are vulnerable to truncation attacks</small><br>
<small>;TIMEOUTclose = 0</small><br>
<br>
<small>; vim:ft=dosini</small><br>
<br>
<small>[abjects]</small><br>
<small>client = yes</small><br>
<small>accept = 127.0.0.1:7001</small><br>
<small>connect = irc.abjects.net:9999</small><br>
<br>
<small>[Elite-IRC]</small><br>
<small>client = yes</small><br>
<small>accept = 127.0.0.1:7002</small><br>
<small>connect = SpeedSpace-IRC.eu:6697</small><br>
<br>
<small>[BodenTruppe]</small><br>
<small>client = yes</small><br>
<small>accept = 127.0.0.1:7003</small><br>
<small>connect = boden-truppe.zapto.org:7001</small><br>
<br>
<small>[LinkNet]</small><br>
<small>client = yes</small><br>
<small>accept = 127.0.0.1:7004</small><br>
<small>connect = irc.link-net.nl:7000</small></font><br>
</blockquote>
<br>
The first connect always works properly (as shown in the log below):<br>
<blockquote><font color="#33cc00"><small>2013.09.03 12:30:45
LOG5[10696:9140]: stunnel 4.56 on x86-pc-msvc-1500 platform<br>
2013.09.03 12:30:45 LOG5[10696:9140]: Compiled/running with OpenSSL
1.0.1e-fips11 Feb 2013<br>
2013.09.03 12:30:45 LOG5[10696:9140]: Threading:WIN32
Sockets:SELECT,IPv6 SSL:ENGINE,OCSP,FIPS<br>
2013.09.03 12:30:45 LOG5[10696:9140]: Reading configuration from file
stunnel.conf<br>
2013.09.03 12:30:45 LOG5[10696:9140]: FIPS mode is enabled<br>
2013.09.03 12:30:45 LOG5[10696:9140]: Configuration successful<br>
2013.09.03 12:30:53 LOG5[10696:10756]: Service [abjects] accepted
connection from 127.0.0.1:3397<br>
2013.09.03 12:30:53 LOG5[10696:10756]: connect_blocking: connected
188.126.73.62:9999<br>
2013.09.03 12:30:53 LOG5[10696:10756]: Service [abjects] connected
remote server from 192.168.1.10:3398<br>
2013.09.03 12:30:54 LOG5[10696:14396]: Service [LinkNet] accepted
connection from 127.0.0.1:3399<br>
2013.09.03 12:30:54 LOG5[10696:14396]: connect_blocking: connected
194.126.217.98:7000<br>
2013.09.03 12:30:54 LOG5[10696:14396]: Service [LinkNet] connected
remote server from 192.168.1.10:3400<br>
2013.09.03 12:30:54 LOG5[10696:2916]: Service [BodenTruppe] accepted
connectionfrom 127.0.0.1:3401<br>
2013.09.03 12:30:54 LOG5[10696:2916]: connect_blocking: connected
178.254.22.94:7001<br>
2013.09.03 12:30:54 LOG5[10696:2916]: Service [BodenTruppe] connected
remote server from 192.168.1.10:3402<br>
2013.09.03 12:30:54 LOG5[10696:12260]: Service [Elite-IRC] accepted
connection from 127.0.0.1:3403<br>
2013.09.03 12:30:54 LOG5[10696:12260]: connect_blocking: connected
62.75.235.122:6697<br>
2013.09.03 12:30:54 LOG5[10696:12260]: Service [Elite-IRC] connected
remote server from 192.168.1.10:3404</small></font><br>
</blockquote>
<br>
But when I try to reconnect, it doesn't work for 2 of my 4 servers<br>
This is an example for what happens to Elite-IRC:<br>
<blockquote><font color="#33cc00"><small>2013.09.03 12:32:22
LOG5[10696:12260]: Connection closed: 1972 byte(s) sent to S</small><small>SL,
26903 byte(s) sent to socket</small><br>
<small>2013.09.03 12:32:23 LOG5[10696:17168]: Service [Elite-IRC]
accepted connection f</small><small>rom 127.0.0.1:3429</small><br>
<small>2013.09.03 12:32:23 LOG5[10696:17168]: connect_blocking:
connected 62.75.235.122</small><small>:6697</small><br>
<small>2013.09.03 12:32:23 LOG5[10696:17168]: Service [Elite-IRC]
connected remote serv</small><small>er from 192.168.1.10:3430</small><br>
<small>2013.09.03 12:32:23 LOG3[10696:17168]: SSL_connect: Peer
suddenly disconnected</small><br>
<small>2013.09.03 12:32:23 LOG5[10696:17168]: Connection reset: 0
byte(s) sent to SSL,</small><small>0 byte(s) sent to socket</small></font><br>
</blockquote>
The frist line shows the manual disconnect occured by executing
"/server localhost:7002" in mIRC.<br>
The second line shows the new incoming connection from my mIRC.<br>
The third line? ... I got no clue why it has to block anything.<br>
The fourth line: Successfully connected to IRC-Server?<br>
And then the fifth line occurs. I'm not sure if I interpret it right,
but for some reason tstunnel.exe is kicking out my connected mIRC
client which makes mIRC to tell me "[10053] Software caused connection
abort".<br>
<br>
The whole lines in mIRC are:<br>
<blockquote><font color="#33cc00"><small>[12:34pm] * Connect retry #1
localhost (7003)</small><br>
<small>————————————————————</small><br>
<small>[12:34pm] * [10053] Software caused connection abort</small><br>
<small>————————————————————</small><br>
<small>[12:34pm] * Disconnected</small></font><br>
</blockquote>
By the way, I have packed libeay32.dll, ssleay32.dll, stunnel.conf and
tstunnel.exe in a subdir in mIRC directory <br>
and I'm starting it using "tstunnel.exe stunnel.conf"<br>
<br>
When this error occurs, I have to kill tstunnel.exe and start it again
- then everything works fine again.<br>
For 1 of 4 servers, I also had this error with the old command-line
stunnel.exe and I just wrote a script killing (only this) stunnel.exe
and restarting it when this mIRC error occurs. Unfortunately this is no
longer possible when tstunnel.exe is using a configuration file and one
process is managing all connections.<br>
<br>
<br>
Is there any way I can fix this? <br>
(Maybe by fixing the logout of my local mIRC from my local
tstunnel.exe?)<br>
<br>
Best regards<br>
</body>
</html>