Virgo Pärna 0 Posted November 24, 2017 Share Posted November 24, 2017 (edited) 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 November 24, 2017 by Virgo Pärna Link to comment Share on other sites More sharing options...
Virgo Pärna 0 Posted November 24, 2017 Author Share Posted November 24, 2017 And since I forgot to mention server version: ProductVersion: 6.5.417.0 in the same log file. Link to comment Share on other sites More sharing options...
ESET Staff MartinK 378 Posted November 25, 2017 ESET Staff Share Posted November 25, 2017 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 More sharing options...
Virgo Pärna 0 Posted November 25, 2017 Author Share Posted November 25, 2017 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 More sharing options...
Virgo Pärna 0 Posted November 25, 2017 Author Share Posted November 25, 2017 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 More sharing options...
Virgo Pärna 0 Posted November 25, 2017 Author Share Posted November 25, 2017 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 More sharing options...
ESET Staff MartinK 378 Posted November 25, 2017 ESET Staff Share Posted November 25, 2017 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 More sharing options...
Virgo Pärna 0 Posted November 25, 2017 Author Share Posted November 25, 2017 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 More sharing options...
ESET Staff MartinK 378 Posted November 25, 2017 ESET Staff Share Posted November 25, 2017 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 More sharing options...
Virgo Pärna 0 Posted November 25, 2017 Author Share Posted November 25, 2017 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 More sharing options...
Recommended Posts