TIdHTTPServer with SChannel?

[cpstevenc]

Using TIdHTTPServer with Delphi 11.3

I need to switch away from OpenSSL ( long story )

For client programs I use @ Delphi/Indy.SChannel/lib/Execute.IdSSLSChannel.pas at master · tothpaul/Delphi (github.com)

Which works well.

But there isn't A TidServerIoHandler version.

So pondering anything out there to deal with this?

[rlebeau]

there isn't A TidServerIoHandler version.

So pondering anything out there to deal with this?

Not that I'm aware of.

[cpstevenc]

there isn't A TidServerIoHandler version.

So pondering anything out there to deal with this?

Not that I'm aware of.

Well here is the story of what I am up against... and maybe you have an idea so can use OpenSSL ...

I have to use an ODBC driver where the company the writes it... still uses OpenSSL from 2005.

When any program I have that uses Indy does any SSL work, OpenSSL DLL files are loaded up into memory. So new OpenSSL files.

Well when that ODBC Driver loads, it appears to hook into the already loaded OpenSSL DLL files in memory.

Then the ODBC starts to fail left and right because "wrong" OpenSSL is running. Stack traces of memory dumps always lead back to this.

I am not sure if there is a way to prevent that or not.

1) The company that makes the Database/ODBC has zero interest on updating or changing anything.
2) There is no alternative ODBC software to this database engine.

[rlebeau]

I have to use an ODBC driver where the company the writes it... still uses OpenSSL from 2005.

In other words, likely OpenSSL 0.9.8.

Can't you get a newer ODBC driver?  If not from this company, then from another company?

When any program I have that uses Indy does any SSL work, OpenSSL DLL files are loaded up into memory. So new OpenSSL files.

In theory, Indy can use OpenSSL 0.9.8, although that hasn't been tested in many many years, so I don't know if it will still work.

Well when that ODBC Driver loads, it appears to hook into the already loaded OpenSSL DLL files in memory.

Then the ODBC starts to fail left and right because "wrong" OpenSSL is running. Stack traces of memory dumps always lead back to this.

I am not sure if there is a way to prevent that or not.

2 things that immediately come to mind: side-by-side assemblies, and activation contexts.  These were designed for this kind of situation, where some components in an app may need one version of a DLL, while other components may need a different version of the DLL.

So, for instance, you could put the 2 OpenSSL versions into separate assemblies, and then use a manifest to tell Windows which assembly to use when loading the DLL.  This might require you to separate the ODBC and Indy codes into separate apps, I'm not sure.

Or, before loading up either library in the same app, you could first create an activation context that uses the old OpenSSL DLLs and then load up the ODBC driver under that context, and then create a new activation context that uses the newer OpenSSL DLLs and then load up Indy under that context.

Just food for thought.  I don't have any practical hands-on experience using either approach.  I just know they exist.

[cpstevenc]

Can't you get a newer ODBC driver?  If not from this company, then from another company?

No. Its a very niche Database... Main target is banks and medical industries.
Just so happen our company used it too ( which is neither bank or medical related )
And our software started in 1979 ( year before i was born )
So really nothing on that front is gonna change.

For newer ODBC no. They won't budge. 

We are "stuck" on their 2018 server flavor for now.   Anything past that right now is gonna cost literally millions if dollars for new licenses and such to migrate to their newer database system.  Which is literally same stuff, just a new name and some new features.  Lawyers are involved, and way beyond me. I am just a cog in the machine here.

And the 2018 ODBC Drivers... for their 2018 Server Software... Use 1.0.2gz Openssl which appears to be from 2015.

Which i've found to cause lots of issues i've come to find with random products of ours that needed OpenSSL... Such as a Datasnap REST server that gets random SSL disconnect exception errors flagged.
Just oddball stuff.

No one else makes drivers. Its priority. They do have JDBC drivers. But that isn't gonna do me any good.

I did seem to maybe come up with a half-ass solution....

I copied IdSSLOpenSSLHeaders.pas to my source folder and edited it.  I put "cmrs" in the file name CONSTS.  And rename the files accordingly.

Now when running it, I used madExcept to raise an error... so it would dump me all the loaded modules.

I can now see CMRS ( my program ) ... has lbeay32.cmrs.dll and ssleay32.cmrs.dll loaded up.

And the ODBC Driver has ssleay32.dll and libeay32.dll from its own install folder loaded.

Before doing this...  there would only be one instance of the two DLL's in memory... and it would the OpenSSL files loaded by indy as that would get ran first.

I don't know if this is good or bad... but i had three of our QA testers doing testing for an hour with no errors.  Where before , it would crop up in under 1 minute every time.

I don't think there is code in IdSSLOpenSSLHeaders to allow me to change the dll file names to look for? if not, ill just have to for now on, include this file source over time and edit it to fit my needs.

But if works, it would be another of 1000 sloppy ugly work arounds i've had to do in my life to get by

   

   

[rlebeau]

And the 2018 ODBC Drivers... for their 2018 Server Software... Use 1.0.2gz Openssl which appears to be from 2015.

Indy definitely works with OpenSSL 1.0.2 (the last release was 1.0.2u).

I copied IdSSLOpenSSLHeaders.pas to my source folder and edited it.  I put "cmrs" in the file name CONSTS.  And rename the files accordingly.

I don't think that will work by itself, because one of the OpenSSL DLLs is linked to the other DLL, so you would have to also modify/recompile the affected DLL to update the filename in its linkage.

I don't know if this is good or bad... but i had three of our QA testers doing testing for an hour with no errors.  Where before , it would crop up in under 1 minute every time.

This is not a good solution. Are you not considering the other solutions I mentioned?

I don't think there is code in IdSSLOpenSSLHeaders to allow me to change the dll file names to look for?

No, they are hard-coded. You can only specify the folder where the DLLs are loaded from.

[cpstevenc]

And the 2018 ODBC Drivers... for their 2018 Server Software... Use 1.0.2gz Openssl which appears to be from 2015.

Indy definitely works with OpenSSL 1.0.2 (the last release was 1.0.2u).

I copied IdSSLOpenSSLHeaders.pas to my source folder and edited it.  I put "cmrs" in the file name CONSTS.  And rename the files accordingly.

I don't think that will work by itself, because one of the OpenSSL DLLs is linked to the other DLL, so you would have to also modify/recompile the affected DLL to update the filename in its linkage.

I don't know if this is good or bad... but i had three of our QA testers doing testing for an hour with no errors.  Where before , it would crop up in under 1 minute every time.

This is not a good solution.  Are you not considering the other solutions I mentioned?

I don't think there is code in IdSSLOpenSSLHeaders to allow me to change the dll file names to look for?

No, they are hard-coded.  You can only specify the folder where the DLLs are loaded from.

1.0.2gz causes Delphi 11.3 DataSnap to throw exceptions everywhere on SSL Disconnections ( forget exact message but it is not happy )

As for the side-by-side assemblies, and activation contexts. 

I am still trying to wrap my head around those. And how that works and if does what I need. As at time I read your post, I had done my DLL renaming process, which in my screen shot in my previous post, shows both sets DLL's loaded.. my set of DLL's I renamed and my program started... and the DLL's by the ODBC Driver once ODBC work is done and show up... And after nearly 24hrs of testing and "so-far-so-good" I am being told from thousands of tests via Ranorex testing have all passed.

For the ODBC I do nothing special currently... Run A TADOConnection / TADOQuery / TADOStoredproc ... like with any ODBC driver and let it do its thing.
I don't do any code to fire it up / load it up /ect ect ...

Splitting up the code in all our products is a no go. Talking millions and millions of lines of code among multiple programs. To sperate Program from ODBC calls...
Ain't gonna happen. Some of our products are 20+ years old of continuous development and on tens of thousands of workstation systems. And changing how that all works... nope.

I'll keep playing around ... Not trying to be difficult ... just under a time crunch to get this all working in roughly 3 weeks, no matter how hacky in the end, so in a slight "panic mode".... And this doofy ODBC driver is mostly the root of this and the company that makes it don't care to help or budge a finger on it.

[cpstevenc]

BTW I do see what you mean about the ssleay32 dll ... it loads any Libeay32.dll it can find it seems as i found in the loaded modules.

I found this by testing connecting to an older DB software setup that doesn't require SSL/TLS for the ODBC to work. So the ODBC didn't load anything OpenSSL related.

And because of this, ssleay32.cmrs.dll actually loaded a libeay32.dll from a 3rd party program installed on my system. 

I am still looking into the whole manifest XML deal but so far coming up short on that.

So probably, only way for now would be compile the DLLs myself and make sure it looks for a different file names and the code in the files are looking for the different file names also.
And modify the INDY code....

As running out of time

[rlebeau]

BTW I do see what you mean about the ssleay32 dll ... it loads any Libeay32.dll it can find it seems as i found in the loaded modules.
...
And because of this, ssleay32.cmrs.dll actually loaded a libeay32.dll from a 3rd party program installed on my system. 

Exactly. And you can't be sure that the DLLs from two separate app installations are compatible with each other.

[cpstevenc]

BTW I do see what you mean about the ssleay32 dll ... it loads any Libeay32.dll it can find it seems as i found in the loaded modules.
...
And because of this, ssleay32.cmrs.dll actually loaded a libeay32.dll from a 3rd party program installed on my system. 

Exactly.  And you can't be sure that the DLLs from two separate app installations are compatible with each other.

I couldn't figure out the side-by-side assemblies / activation contexts. Just couldn't find exactly what to do or how it would fix my problem. Google / ChatGPT / Ect... couldn't put it together enough for my chimp brain.

I was able to just check out the OpenSSL source and compile it myself in Visual Studio 2022. Using Strawberry Perl / NASM. Just followed the instructions and it worked.

Then made a batch file to zip through files to fix the naming convention from libeay32 to libeayCM32 and ssleay32 to ssleayCM32 for the file names and the internal refernce to libeay from ssleay.

And this worked like a charm. So now just a batch script to take a clean OpenSSL 1.0.2 source and "fix it up" and compile it all down.

Only other change for this to work is the edit the Indy source code on what DLL name to look for.

I tried this on our two problem child programs having this OpenSSL fight with what it wants vs the InterSystems Cache Drivers loading their flavor and wanting that old version to work.
And things are working. HTTPS Client and server /FTPS/SMTP/DataSnap REST/ect/ect which all use INDY is working like a charm now.  And the ODBC drivers are doing its thing.  

I don't 100% like this, but its my only hope and only solution i've gotten to actually work.