Jump to content
dummzeuch

Troubleshoot SSL/TLS connection with Indy

Recommended Posts

Yesterday, all of a sudden, one of my Delphi programs failed to connect to various WMS servers on the internet. I got the following error message:

Error connecting with SSL. error 1409442E:SSL routine:ssl3_read_bytes:tlsv1 alert protocol version

Since I was using a recent version of Indy, this should not happen, according to this thread on Delphi Praxis. It turned out that somehow a very old version of the openssl DLLs libeay32.dll and ssleay32.dll had gotten ... read on in the blog post

  • Thanks 1

Share this post


Link to post

SysInternals Process Explorer can show the path and version resource of each loaded DLL in a process.

  • Thanks 1

Share this post


Link to post
3 hours ago, timfrost said:

SysInternals Process Explorer can show the path and version resource of each loaded DLL in a process.

Yes, I kind of knew this (but didn't think of it). But using the internal functions will also help diagnose installations on computers which cannot be accessed directly. A program can present the user with this information or it can be included in an error message or log file.

Share this post


Link to post
20 hours ago, dummzeuch said:

Yes, I kind of knew this (but didn't think of it). But using the internal functions will also help diagnose installations on computers which cannot be accessed directly. A program can present the user with this information or it can be included in an error message or log file.

In  C#/,Net i (years ago) intercepted the DLL loads (long time ago), i could log them, and maybe (can't remember divert them).

Within that method i could test versions (for win32 dll as for ".net assembly dll") and decline them. 

 

(Was nice back then to find out .Net searched DLL's in another place on devices with VisualStudio installed on them)

 

 

Edited by mvanrijnen

Share this post


Link to post

So your program has relied on a 3rd party libs that *should* be kept up-to-date by someone else 🙂? I think in such case the program itself must control what it loads and check if a loaded module has proper version. Or just use local libs and don't bother about what's in search path.

Edited by Fr0sT.Brutal

Share this post


Link to post
2 hours ago, Fr0sT.Brutal said:

So your program has relied on a 3rd party libs that *should* be kept up-to-date by someone else 🙂?

No, the program should have had these DLLs in its installation directory. And it usually has.

2 hours ago, Fr0sT.Brutal said:

I think in such case the program itself must control what it loads and check if a loaded module has proper version. Or just use local libs and don't bother about what's in search path.

Yes, it should. It didn't though. Now it does.

The error occurred on my development computer with freshly checked out sources. Normally missing DLLs would have caused an error message which would have reminded me to copy them from a subfolder. Unfortunately there was no error message, just the SSL connection failed.

Hm, thinking about it: Maybe the loading code should specify the full path for the DLLs. But that would mean I had to change the Indy sources. I'd rather not do that. Alternatively my program could load the DLLs before calling any Indy code.

Share this post


Link to post
2 hours ago, dummzeuch said:

Alternatively my program could load the DLLs before calling any Indy code.

It should be enough to use IdOpenSSLSetLibPath.

  • Like 1
  • Thanks 1

Share this post


Link to post
14 hours ago, dummzeuch said:

Maybe the loading code should specify the full path for the DLLs.

I think any lib loading a non-system DLL should provide an option to specify the DLL path because though there are functions like SetDllDirectory you can't forbid the loading from system folders unless full path is specified when calling LoadLibrary. However SetDllDirectory allows to change search path priority to load DLL from a specific folder. Pre-loading the DLL also an option

Edited by Fr0sT.Brutal

Share this post


Link to post
10 hours ago, Fr0sT.Brutal said:

I think any lib loading a non-system DLL should provide an option to specify the DLL path

Which Indy does - the IdSSLOpenSSLHeaders.IdOpenSSLSetLibPath() function, as Lajos Juhász mentioned.  By default, Indy loads the DLLs using the system search path, but if you call IdOpenSSLSetLibPath() first then Indy loads the DLLs using the specified path instead.

Edited by Remy Lebeau

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×