Page 1 of 1
Stumped (SSL linking problem)
Posted: Wed Nov 16, 2011 10:38 pm
by cards
Here's the scenario. I have a mid sized network with several servers. They are all linked correctly. Here's the problem. We use SSL to connect all of our servers together, however they can only connect one way.
Example.
Hub->Server1 works fine.
However
Server1->Hub results in SSL_connect(): Internal OpenSSL error or protocol error
I have telneted from Server1 to Hub using the SSL Port, and it connects. Server2->Hub also works without a problem. What could be going on.
Re: Stumped...
Posted: Thu Nov 17, 2011 10:03 pm
by Syzop
You could check if you can use SSL from Server1->Hub via some other program, to check if it's really UnrealIRCd's fault.
The command is:
where, naturally, you need to replace the IP and PORT with the remote IRC servers' IP and (server) port, the exact same you use in your linking block.
Then, type something like 'version' (+enter), to see if it says something useful back.
If this doesn't work, then verify your listen block (on the Hub) includes the ssl option.
If it does work, then it get's interesting
Re: Stumped (SSL linking problem)
Posted: Sun Nov 20, 2011 6:45 am
by cards
Didn't mean to blame Unreal. It's just stumping me. Did as you asked and I guess it get's interesting.
Connect from the host that throws the error to our hub. Here is the result:
Code: Select all
Compression: 1 (zlib compression)
Start Time: 1321771283
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
version
:hub2.420-hightimes.com 005 CMDS=KNOCK,MAP,DCCALLOW,USERIP UHNAMES NAMESX SAFELIST HCN MAXCHANNELS=15 CHANLIMIT=#:15 MAXLIST=b:60,e:60,I:60 NICKLEN=30 CHANNELLEN=32 TOPICLEN=307 KICKLEN=307 AWAYLEN=307 :are supported by this server
:hub2.420-hightimes.com 005 MAXTARGETS=20 WALLCHOPS WATCH=128 WATCHOPTS=A SILENCE=15 MODES=12 CHANTYPES=# PREFIX=(qaohv)~&@%+ CHANMODES=beI,kfL,lj,psmntirRcOAQKVCuzNSMTGZ NETWORK=420-HIGHTIMES CASEMAPPING=ascii EXTBAN=~,qjncrR ELIST=MNUCT :are supported by this server
:hub2.420-hightimes.com 005 STATUSMSG=~&@%+ EXCEPTS INVEX :are supported by this server
ERROR :Closing Link: [67.220.66.2] (Ping timeout)
closed
Re: Stumped (SSL linking problem)
Posted: Sun Nov 20, 2011 12:11 pm
by Syzop
I see.
What OpenSSL version are you using on both sides? (Please use /VERSION as IRCOp to find out)
Re: Stumped (SSL linking problem)
Posted: Sun Nov 20, 2011 2:04 pm
by katsklaw
Syzop wrote:I see.
What OpenSSL version are you using on both sides? (Please use /VERSION as IRCOp to find out)
Due to the "friendliness" of some clients, you may need to do
/quote version otherwise the client will try
/ctcp VERSION instead of the
/version command which are not the same thing.
Re: Stumped (SSL linking problem)
Posted: Thu Nov 24, 2011 6:19 am
by cards
Sorry. My internet is flakey so I can't get on every day. Damn Wileblue. Here are the results:
Hub
OpenSSL 0.9.8g 19 Oct 2007
Server/Leaf
OpenSSL 1.0.0e 6 Sep 2011
I will try upgrading OpenSSL on the hub, as I can control it. However all of our leafs are shared hosting, so I have no control over them
Re: Stumped (SSL linking problem)
Posted: Thu Nov 24, 2011 7:06 am
by cards
Can't update base lenny as I have to install a new kernal. I will probably update the kernal soon, just don't feel like it right now. But I'm pretty sure this is part of the issue.
Re: Stumped (SSL linking problem)
Posted: Thu Nov 24, 2011 6:59 pm
by warg
If you were able to telnet to a server on SSL port, then that port isn't SSL. Telnet does not support SSL. To test an SSL port, try openssl s_client -connect <server>:<sslport>
eg:
openssl s_client -connect irc.unrealircd.org:6697
Re: Stumped (SSL linking problem)
Posted: Thu Nov 24, 2011 7:16 pm
by Syzop
/me forces warg to re-read the thread
cards: The kernel is unlikely to have anything to do with it (but yeah, I understand you have to update it before you can proceed with the rest).
As for those different OpenSSL versions, yes, that could be the problem. It shouldn't, but past experience shows that there are sometimes compatibility issues with it, even though they are rare. I recently discovered we might be missing some compatibility-workarounds in the UnrealIRCd OpenSSL code, which might cause this issue. After all, since the openssl s_client works, UnrealIRCd should also work, but it doesn't...
(On the other hand, because of the lack of those standard work arounds, the implementation is more secure...)