EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Strange problem with SSL server

Also by EldoS: MsgConnect
Cross-platform protocol-independent communication framework for building peer-to-peer and client-server applications and middleware components.
#549
Posted: 06/28/2006 07:10:11
by Stephane Grobety (Priority Standard support level)
Joined: 04/18/2006
Posts: 170

Hello,

A customer just called to report a very strange issue he had with our software:

No client could connect any more, all connections where rejected when the server tried to destablish TLS. Restarting the service didn't fix the problem: only restarting the server did.

He sent me the debug file generated by the server. Since I'm using Eurkalog to store these errors, I have a complete call stack and error description of the poblem. Unfortunately, I'm not shure what i can make of it.

The error is EIdSSLProtocolReplyError with message "Error connecting with SSL.". It is raised at line 506 of unit SBIndyServerIOHandler10.pas:


Code
    if FSecureServer.Active then
    begin
      FSecured := true;
      DoSSLEstablished;
    end
    else
    begin
      ForceClose := true;
      raise EIdSSLProtocolReplyError.Create(RSSSLConnectError); <--- there!
    end;


I'm not sure what to do at this point... I don't have the same kind of detailed log from the client application and it's not possible to reproduce it any more. I'd be happy to add more debug to the program but, the way I see it, there is some error information that is lost somewhere in there: I don't know if I'm witnessing a connection error, an SSL error, a software error or something completely different.

Would you have a suggestion about what I could do to find out what's happening here ?

Edit: I forgot to specify that I'm working with Delphi 6, the application is running as a service on windows 2003 and uses a Thawthe certificate. The version of SBB pro I had at this time is the version that was current on Jun, 14th (I'm afraid I can't remember the version number any more).
#551
Posted: 06/28/2006 08:42:26
by Matthias Hanft (Basic support level)
Joined: 04/28/2006
Posts: 15

Just a quick guess: Are you sure that there is only _one_ server with that IP address and port number? I once had similar problems and found out that I had tried to run the server process more than once (and/or tried to open the same IP/port twice within the same server under certain circumstances).

Matthias
#557
Posted: 06/28/2006 10:26:47
by Stephane Grobety (Priority Standard support level)
Joined: 04/18/2006
Posts: 170

Thanks for the idea.

It's highly unlikely that there could be more than one host on that network running with the same IP for a number of reason (including the fact that this one is running on a safe net where no client exeists and with tight host control: even if you connected a new server to the same subnet, you would need to disconnect the old one and reuse the same port in order to reuse that address).

It's also impossible for two server process to run on the machine at the same time: there is a limitation in the software that aborts the startup is another instance is already running, the program already handles the possible error of having another program running on the same port and the socket isn't open with the reuse flag set. As a final touch, no new process should have been created on that server at this time: it's dedicated to this application.

Maybe I've missed an angle to the issue, but I don't see how I could have dupplicates here.
#579
Posted: 06/29/2006 07:42:58
by Ken Ivanov (EldoS Corp.)

First of all, please consider handling OnError event and log its output. This event is thrown if some error occurs during SSL negotiation and can be used to track the reason for the problem.

Quote
Restarting the service didn't fix the problem: only restarting the server did.

Hmm, I'm not sure that I understood you right. The server is stopped along with the service, isn't it?
#580
Posted: 06/29/2006 08:17:28
by Stephane Grobety (Priority Standard support level)
Joined: 04/18/2006
Posts: 170

Quote
First of all, please consider handling OnError event and log its output. This event is thrown if some error occurs during SSL negotiation and can be used to track the reason for the problem.


Sounds reasonable. I'll implement this ASAP.

Quote
Hmm, I'm not sure that I understood you right. The server is stopped along with the service, isn't it?


Ok: I didn't get this first hand since the customer only called me after the fact (so the problem was already "fixed").

- Application stopped acception SSL connection
- User restarted server service.
- Application was still unresponsive.
- User rebooted the physical machine that was running the service.
- Application resume normal operation after hardware reboot.

I hope I managed to explain it better.
#581
Posted: 06/29/2006 08:46:27
by Ken Ivanov (EldoS Corp.)

Quote
- User restarted server service.
- Application was still unresponsive.
- User rebooted the physical machine that was running the service.
- Application resume normal operation after hardware reboot.

Thank you for the explanation -- I was not sure if you've been talking about software or hardware 'server'.

The following sequence of actions seems to have taken place:
a) incoming SSL connection failed for some reason,
b) as a result of (a), the service crashed. Although the service crashed, the listening socket was not automatically unbound by OS (we've noticed such a behaviour several times before),
c) the following attempts to alive the server failed because the listening port has been already bound by the previous session of the service and was not freed by OS when the service crashed.

We will try to find out what may have caused the issue.
#582
Posted: 06/29/2006 09:01:53
by Stephane Grobety (Priority Standard support level)
Joined: 04/18/2006
Posts: 170

Quote
the server failed because the listening port has been already bound by the previous session of the service and was not freed by OS


I don't think that's what happened here: if the service fails to bind the local socket at startup, it is designed to stop, writen an event in the application log and the terminate with an exception.

This didn't happen so either my code that handle this error was bugged in that version (always possible but unlikely snce it works now and I didn't touch it) or the binding was sucessful but somehow wouldn't work. I've noticed that this was indeed possible if the initial socket was created with the SO_REUSEADDR option but that's not how I create it (Indy will only use this option if you set the IdTCPServer.ReuseSocket ro rsTrue or rsOSDependant if you're running under Linux).

That being said, I've implemented an OnError even handler and it should now log all SSL errors to the database. I'll update the customer next week and we'll see if we can catch it again.

Thanks for your help,
Stephane
Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.

Reply

Statistics

Topic viewed 6153 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!