Jump to content

Eraserver fails to start after upgrade to Debian Stretch


Virgo Pärna
 Share

Recommended Posts

After upgrading server operating system to Debian Stretch (was Jessie) eraserver fails to start up with "SSL initialization failed". (in trace.log).

2017-11-24 12:54:59 Information: Kernel [Thread b7507980]: Loading module library Network
2017-11-24 12:55:00 Error: Service [Thread b7507980]: SSL initialization failed

I have following ssl libraris installed:

libssl1.0.0

libssl1.0.2

libssl1.1

Edited by Virgo Pärna
Link to comment
Share on other sites

  • ESET Staff

Problem will be most probably with OpenSSL 1.1.* which is not supported by this ERA release. In case this library is found prior to older 1.0.x, it will result in failure. Only possibility is to configure system or ERA daemon startup script so that 1.0.2 ssl libraries are prioritized.  Forcing older library should be possible using environment variables defined for ERA process, or possibly also by creating symbolic link in it's program files directory (/opt/eset/RemoteAdministrator/Server/).

Link to comment
Share on other sites

39 minutes ago, MartinK said:

Problem will be most probably with OpenSSL 1.1.* which is not supported by this ERA release. In case this library is found prior to older 1.0.x, it will result in failure. Only possibility is to configure system or ERA daemon startup script so that 1.0.2 ssl libraries are prioritized.  Forcing older library should be possible using environment variables defined for ERA process, or possibly also by creating symbolic link in it's program files directory (/opt/eset/RemoteAdministrator/Server/).

Thanks. Creating links in /opt/eset/RemoteAdministrator/Server for

libcrypto.so -> /usr/lib/i386-linux-gnu/libcrypto.so.1.0.2

libssl.so -> /usr/lib/i386-linux-gnu/libssl.so.1.0.2

seems to have fixed the issue for now.

Link to comment
Share on other sites

Interestingly one XP computer, that we still have around fails handshake when connecting to server:

Error: CReplicationModule [Thread e94]: CReplicationManager: Replication (network) connection to 'host: "servername" port: 2222' failed with: Receive: NodSslWriteEncryptedData: Handshake failed to complete.

TLS 1.0 is still supported, so that should not be an issue.

 

Link to comment
Share on other sites

An on the server side the errors are:

Error: NetworkModule [Thread aa6f6b40]: Receive: NodSslWriteEncryptedData: Internal error in the underlying implementations., ResolvedIpAddress:10.10.10.36, ResolvedHostname:clientname, ResolvedPort:1758

Error: NetworkModule [Thread aa6f6b40]: Protocol failure for session id 1557, error:Receive: NodSslWriteEncryptedData: Internal error in the underlying implementations.

Link to comment
Share on other sites

  • ESET Staff
1 hour ago, Virgo Pärna said:

TLS 1.0 is still supported, so that should not be an issue.

Actually it may be related issue. Even if TLS1.0 is supported, it does not mean that obsolete (and no longer safe) crypto-suites are available. Empty intersection between list of ciphers supported by Windows XP and your openssl may result in handshake failure. If I recall correctly, there is no support for AES in Windows XP and thus support for 3DES is required by your openssl, which is considered as weak.

I would recommend to check handshake failure using tool like Wireshark - you will have to manually mark communication on port 2222 as TLS so that it is automatically decoded.

Link to comment
Share on other sites

Ok, I can try Wireshark at Monday. But that is probably the reason. 3DES is disabled at stretch version of openssl. And while jessie version of libssl1.0.0 is still installed the eraserver would not work with it (with libssl and libcrypto linked to 1.0.0 version). I guess that monitoring would not work with that computer anymore. Since it is not actively used, it really is not much of a issue. At least it is good to know the reason.

Link to comment
Share on other sites

  • ESET Staff

Using 1.0.1x from Jessie would work. It maybe even possible to just copy libcrypto.so (from jessie package) to /opt/eset/RemoteAdministrator/Server/ so that only this application is aware it. You will just have to handle updates manually in case of security issues are reported.

Just a note, we have decided to no longer rely on operating system SSL layers, so in next major release of ERA, all supported systems (including Windows XP) will be able to communicate with ERA using most secure TLS algorithms.

Link to comment
Share on other sites

 libssl1.0.0 package from jessie is actually version 1.0.1t. And when I tried now again, it worked. And from checking the bash history  it appears that previously I made an error linking libcrypto.so.1.0.0

Sot that it works now and is updated as long as Jessie is updated.

Thanks for help.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...