Linking via SSL - One Server Has Problems

These are old archives. They are kept for historic purposes only.
Post Reply
mixx941
Posts: 16
Joined: Mon Jan 24, 2005 3:31 pm

Linking via SSL - One Server Has Problems

Post by mixx941 »

Hi everyone. I'm working on getting my network fully SSL enabled, however I'm having an issue with one of the servers. Right now, the hub I'm trying to link to has three other servers linked to it via SSL. They all worked fine with no problems.

Whenever I try to link this particular leaf up to the same hub with SSL, I only get:

--- Exiting ssl client hub2.mynet.net[@x.x.x.x.0]: SSL_connect(): Underlying syscall error

I've checked the link block on the leaf several times, and everything looks just like the rest that can link fine:

Code: Select all

link            hub2.mynet.net
{
        username        *;
        hostname        x.x.x.x;
        bind-ip         *;
        port            7979;
        hub             *;
        password-connect "xxx";
        password-receive "xxx";
        class           servers;
                options {
                        autoconnect;
                        zip;
                        ssl;
                };
};
The hub is listening on 7979 with SSL just fine, as the other three can link there great.

I've tried opening up another listen port on the hub, no go. I've checked the ircd.log file, and there is nothing in there. SSL works fine for client connections on port 6697, so I don't think it's an install error with SSL. I've even tried a different SSL listen port on the hub just for the fun of it, unfortunately nothing. Also tried specifying ciphers for it just in case, same thing.

It links fine to the hub on the regular, non-SSL port.

OS is Gentoo Linux, OpenSSL version 0.9.7e 25 Oct 2004

Thanks in advance.

-Mark
nate
Posts: 148
Joined: Fri Jul 29, 2005 10:12 am
Location: Johnstown, Pa
Contact:

Post by nate »

You're getting the 'Exiting ssl client hub2.mynet.net[@x.x.x.x.0]: SSL_connect(): Underlying syscall error' notice from your status screen on the main hub right?

I believe something like that was noted as a Junk notice in the FAQ, or atleast perhaps something similar.

Only other thing I've noticed mentioned awhile back which has something in relation to that error is something wrong with Certificates on the server you are trying to connect to, or as someone else put it:
Shell wrote:Look at your timestamp, then look at the date + time the cert is valid for.

Are you and the server in different time zones or something?
Syzop
UnrealIRCd head coder
Posts: 2112
Joined: Sat Mar 06, 2004 8:57 pm
Location: .nl
Contact:

Post by Syzop »

I think this is from the junk snomask already :p

Technical explanation:
Basically openssl says it gots an error from a system function such as read/write/accept/.., which would seem to indicate the problem is not on that end. Most likely, the remote end closed the connection - for whatever reason -.
You probably already know this, since - as you said - the hub already has 3 good ssl connections going.

So.. I guess that message is not going to help you much further.

Did you try the snomask on the other side? I don't know if it would output anything though ;).

What's the OpenSSL version on both sides? People have reported problems before with different openssl versions, though that SHOULD never happen AFAIK :p.
Try doing '/version' as an ircop on both sides, just to be sure.
Also be sure you don't ignore any "openssl version mismatch warnings" on boot.
mixx941
Posts: 16
Joined: Mon Jan 24, 2005 3:31 pm

Post by mixx941 »

Thanks for the responses.

Sorry, I should have been more clear. The syscall errors are all from the leaf. The hub is a hidden hub and does not accept any client connections at all. I read the FAQ and saw that bit about it too, but it's not like it's linking and giving those messages -- it won't link at all with SSL.
Syzop wrote: What's the OpenSSL version on both sides? People have reported problems before with different openssl versions, though that SHOULD never happen AFAIK :p.
The leaf runs OpenSSL 0.9.7e and the hub runs OpenSSL 0.9.7c, but the other leaves that link fine use 0.9.7e or higher I believe.
NBishop wrote: Look at your timestamp, then look at the date + time the cert is valid for.

Are you and the server in different time zones or something?
The certs were signed for two years. The leaf and the hub are in different time zones, but that shouldn't matter on this. I think that part was for the client side of things, which again works perfect with this particular server.

Thanks

-Mark
mixx941
Posts: 16
Joined: Mon Jan 24, 2005 3:31 pm

Post by mixx941 »

I've also tried recompiling just for the fun of it, same thing.

Don't mean to bug but any ideas? :?

Thanks

-Mark
mixx941
Posts: 16
Joined: Mon Jan 24, 2005 3:31 pm

Post by mixx941 »

Well now the issue seems to include all of SSL. Client side SSL on this server was working fine up until last night when I needed to use it. I couldn't connect via SSL on port 6697 via irssi or X-Chat from several machines. Nothing has changed in any of the configs or on any firewalls (even connecting from localhost does not work).

I'm trying it more now, and the error I get from X-Chat is:
--- Connection failed. Error: SSL handshake timed out
I'm opered up on the same machine on the non-SSL port and I see this:
--- Exiting ssl client [@x.x.x.x.7379]: SSL_accept(): Internal OpenSSL error or protocol error
Linking via SSL still is not working.

Anyone? I've got a dedicated server sitting here waiting to be used, but we need all new servers to be SSL enabled. :(

Thanks very much in advance.

-Mark
Mike
Posts: 20
Joined: Fri Feb 04, 2005 11:25 pm
Location: Munich, Germany
Contact:

Post by Mike »

That new problem with SSL handshake, etc - I got no idea about it :-/ But as for the rest: did you say the link block at the beginning ist from the leaf? Then it should say 'leaf *;' and not 'hub *;'. Don't know if this has something to do with the SSL error messages, but it's no harm to correct it anyway.

Also, make sure you don't have 'autoconnect' for that link enabled on the hub (you seem to have on the leaf, and thats OK). If you do, it's possible that the hub is trying to connect to the leaf, thus causing those SSL read messages on the leaf.

Just 2 things I thought of while reading the thread, don't know if that helps :)


Mike
mixx941
Posts: 16
Joined: Mon Jan 24, 2005 3:31 pm

Post by mixx941 »

Hi Mike, thanks for the reply. The link block in the first post is from the leaf. The leaf connects to the hub, so I do believe it should say hub. I tried with leaf like you said, and got the following on a non-SSL link port:
--- *** LocOps -- Link hub2.us.mynet.net cancelled, is Non-Hub but introduced Leaf services.mynet.net
SSL linking still gives the same syscall error.

I only have leaves autoconnect to the hub, not the other way. ;)

Thanks

-Mark
Moogey
Posts: 56
Joined: Thu Sep 08, 2005 9:08 pm

Post by Moogey »

...Then it should say 'leaf *;' and not 'hub *;'...
No, he had it right. It should be hub *; In the link block, you're describing the link you're connecting to, not that server, and the link he's trying to connect to is a hub. Heh, I got confused with that as well at first.

mixx941 I've never tried doing SSL links before nor do I have the knowledge to say what the problem is, but I'd suggest that you get the SSL versions everywhere the same :)
Mike
Posts: 20
Joined: Fri Feb 04, 2005 11:25 pm
Location: Munich, Germany
Contact:

Post by Mike »

Moogey wrote:
...Then it should say 'leaf *;' and not 'hub *;'...
No, he had it right. It should be hub *; In the link block, you're describing the link you're connecting to, not that server
[...]
Quote from the Unreal docs:
hub (optional)
The value is a mask of what servers this hub may connect (ex: *.my.net).

leaf (optional)
The value is a mask that this server will act like a leaf towards.
I understand that so that if you have "hub *.org;" then a) this server is defined to be a hub, and b) it will accept links only from servers with names matching *.org

If you have "leaf *;" then a) this server is defined to be a leaf, and b) it will act as a leaf towards every server.

Or is my English too bad to understand what they mean in the docs? :)


Mike
Moogey
Posts: 56
Joined: Thu Sep 08, 2005 9:08 pm

Post by Moogey »

Well actually that may be what it says but it's wrong :)

It didn't work the other way because that way is wrong.
mixx941
Posts: 16
Joined: Mon Jan 24, 2005 3:31 pm

Post by mixx941 »

Thanks for the responses
Moogey wrote: mixx941 I've never tried doing SSL links before nor do I have the knowledge to say what the problem is, but I'd suggest that you get the SSL versions everywhere the same :)
Unfortunately this is not possible, since several of my servers are FreeBSD, and with FreeBSD it comes with OpenSSL in the base system. The way to upgrade that is to run the exact same version of FreeBSD on every server, or to install the updated FreeBSD port. When you install the port, it creates an OpenSSL install under /usr/local in addition to the one already in /usr. Unfortunately, when having two versions of OpenSSL on the same machine, then Unreal gets a mismatch about SSL versions (even if you tell it to use the proper one).

Just for the record, I have 3 or 4 of my servers already linked via SSL to the hubs, which are running different versions. They all work fine. The odd thing here is that:

- Client SSL on port 6697 was working up until yesterday. Now, after no changes it doesn't work anymore.

- When I initially made my first post about this, client side SSL was fine, but linking via SSL always gave that error and has never been successful on this server.

-Mark
Post Reply