Another case of tlsv1 alert protocol version

[giomach 1]

This problem is similar to "tlsv1 alert protocol version" raised on this forum in December 2020.  I have tried to understand the solution to that problem but I cannot follow it and I cannot know if it applies to my system.

 

I wrote a Delphi program using units IdHTTP, IdSSLOPenSSL, etc. to access the Babelfy server (http://babelfy.org/guide#HowdoIobtainaBabelfyAPIkey? option HTTP API).  The program worked until recently, but now gives "Error connecting with SSL. error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert ptorocol version".  I gather that this may mean that the server has disabled something called TLS v1, but no information can be obtained about any such change, or what version of TLS is now required.

 

In trying to follow the previous postings, my first step was to change a statement to the following

      LHandler.SSLOptions.SSLVersions := [sslvTLSv1, sslvTLSv1_1, sslvTLSv1_2];

where previously it has only sslvTLSv1.  However the extra parameters are 'undeclared identifiers' in Delphi.

 

I have Delphi XE Version 15.0.3953.35171 with update 1 installed, and (according to the Delphi Help) Indy.Sokets 10.1.1.

 

Is it possible to say from this whether my system can support access to servers which have dropped TLS v1?

 

 

 

 

[mjustin 23]

The error message 'undeclared identifiers' could mean that your Indy version is to old.

Try to update to a newer version from https://github.com/IndySockets/Indy

Note: you can extract Indy to a separate directory, keeping the original version unchanged.

Just configure the project search path to include the Core, Protocols and System directories.

[giomach 1]

Many thanks for replying.  As I'm way out of my depth here, I don't want to try anything too ambitious, like recompiling Indy from source (if that is what your suggestion involves — I downloaded Indy-master.zip from your link and it seems to be all source) .  The idea that Indy could be updated independently from the rest of Delphi is something I haven't yet come to terms with.

 

So can I try your patience and ask: can I use compiled dlls instead, like libeay32.dll and ssleay32.dll? I've downloaded those (v 1.0.2.21) from https://github.com/IndySockets/OpenSSL-Binaries but simply placing them in the application directory changes nothing.

 

There are no files called libeay32.dll or ssleay32.dll already on my computer, except in the system directories of installed applications.  One of these directories is Program Files (x86)\Embarcadero\Studio\20.0\bin\subversion  They are v 1.0.2.14.  Could that be where Delphi finds them?  My project search path consists of $(BDSLIB)\$(Platform)\release, $(BDSUSERDIR)\Imports, $(BDS)\Imports, $(BDSCOMMONDIR)\Dcp and $(BDS)\include, which doesn't seem to cover it.

 

Also, Delphi tells me that the identifier sslvTLSv1 is defined at IdSSLOpenSSL.pas (232).  The source of that file, apparently rev 1.40, in Program Files (x86)\Embarcadero\Studio\20.0\source\Indy10\Protocols,  contains no such definition at that line, but lines 236–7 are

type
  TIdSSLVersion = (sslvSSLv2, sslvSSLv23, sslvSSLv3, sslvTLSv1,sslvTLSv1_1,sslvTLSv1_2)
Nevertheless only the fourth of these is recognized by my Delphi as a defined identifier.  But at least the programmer was aware of the other versions by name.  I'm hoping there is some way to "activate" them with the least possible disturbance.

 

The IdSSLOpenSSL.pas in Indy-master.zip and the one in my machine source are both labelled rev 1.40. They differ in a few ways, but not — as far as I can see — in any way that relates to this problem.

 

 

 

[Remy Lebeau 1401]

On 11/7/2021 at 11:01 AM, giomach said:

As I'm way out of my depth here, I don't want to try anything too ambitious, like recompiling Indy from source (if that is what your suggestion involves

That is exactly what you would need to do.  10.1.1 is an EXTREMELY OLD version of Indy.  The current version is 10.6.2.

Quote

I downloaded Indy-master.zip from your link and it seems to be all source) .  The idea that Indy could be updated independently from the rest of Delphi is something I haven't yet come to terms with.

Be sure to read the install instructions first.

Quote

can I use compiled dlls instead, like libeay32.dll and ssleay32.dll? I've downloaded those (v 1.0.2.21) from https://github.com/IndySockets/OpenSSL-Binaries but simply placing them in the application directory changes nothing.

Yes, you need those DLLs no matter what.  But you would still need an up-to-date Indy to take advantage of those updated DLLs and configure them properly.

Quote

There are no files called libeay32.dll or ssleay32.dll already on my computer, except in the system directories of installed applications.

It is very common for apps to use their own copies of OpenSSL DLLs, to avoid versioning conflicts, as the OpenSSL API tends to change from one major version to another.

Quote

One of these directories is Program Files (x86)\Embarcadero\Studio\20.0\bin\subversion  They are v 1.0.2.14.  Could that be where Delphi finds them?

It should not, since that folder should not be on the system search path, but even if it were, the DLLs should normally be looked for in the app's folder first.  But, Indy does have an IdOpenSSLSetLibPath() function in the IdSSLOpenSSLHeaders unit if you need to specify exactly which folder Indy looks in for the DLLs.

Quote

Also, Delphi tells me that the identifier sslvTLSv1 is defined at IdSSLOpenSSL.pas (232). The source of that file, apparently rev 1.40

The revision notes at the top of each Indy .pas file are EXTREMELY OLD, so just ignore them.  They are a remnant from when Indy used TeamCoherence for its version control many years ago, before switching to SVN and now GitHub (neither of which store commit details directly in source files themselves).

Quote

in Program Files (x86)\Embarcadero\Studio\20.0\source\Indy10\Protocols,  contains no such definition at that line, but lines 236–7 are

type
  TIdSSLVersion = (sslvSSLv2, sslvSSLv23, sslvSSLv3, sslvTLSv1,sslvTLSv1_1,sslvTLSv1_2)
Nevertheless only the fourth of these is recognized by my Delphi as a defined identifier.

Then you have an EXTREMELY OLD version of Indy installed and need to upgrade.

Quote

I'm hoping there is some way to "activate" them with the least possible disturbance.

Not without upgrading, no.

Quote

The IdSSLOpenSSL.pas in Indy-master.zip and the one in my machine source are both labelled rev 1.40.

See my comment above.

Edited November 8, 2021 by Remy Lebeau

[giomach 1]

Thanks for clarifying the relationship between Delphi, Indy and OpenSSL.  I'll try to recompile Indy for XE.

 

Just for the record — it doesn't change anything significant, just makes things more consistent — the references in my last post on this thread to Studio/20.0 should instead have been to RAD Studio/8.0. The libeay32.dll and ssleay32.dll there are version 0.9.8.14.  And lines 231–2 of IdSSLOpenSSL.pas actually read

type
  TIdSSLVersion = (sslvSSLv2, sslvSSLv23, sslvSSLv3, sslvTLSv1)

 

 

 

[giomach 1]

Two questions already about compilation and installation of Indy.

 

1. Is the batch file for installation in Delphi XE called FULLD_XE.BAT?  I don't see such a file in Indy-master.zip.

 

2. The instructions for XE say "If you need to use DataSnap, then you will need to maintain the original Indy 10 packages for use in DataSnap projects.  You can use a separate installation of Indy 10 for non-DataSnap projects." I don't use DataSnap but I don't want to rule it out unnecessarily for the future.  How then can I make a "separate installation" of Indy 10, thus keeping the original packages installed where they are, given that "If Indy10 is installed, it must be uninstalled first"?

[Remy Lebeau 1401]

2 hours ago, giomach said:

1. Is the batch file for installation in Delphi XE called FULLD_XE.BAT?  I don't see such a file in Indy-master.zip.

There is no .BAT script for Delphi XE, only for C++Builder XE.  Indy stopped using .BAT scripts for Delphi installations after D2009.  Instead, you can simply open the 5 .DPK packages directly in the IDE (sadly, there is no Project Group file provided for XE) and then compile+install them from the Project Manager.

2 hours ago, giomach said:

2. The instructions for XE say "If you need to use DataSnap, then you will need to maintain the original Indy 10 packages for use in DataSnap projects.  You can use a separate installation of Indy 10 for non-DataSnap projects." I don't use DataSnap but I don't want to rule it out unnecessarily for the future.  How then can I make a "separate installation" of Indy 10, thus keeping the original packages installed where they are, given that "If Indy10 is installed, it must be uninstalled first"?

You would have to maintain separate copies of Indy in different folders, and then configure individual projects to use one folder or the other when referencing the Indy packages/sources.

[giomach 1]

Sorry to be so obtuse. I've not worked with packages before.

 

> open the 5 .DPK packages directly in the IDE and then compile+install them from the Project Manager

 

From the directory where I unpacked Indy-master.zip, I opened Indy-master\Lib\System\IndySystem150.dpk in the IDE.  I got a warning that IndySystem150.dproj (I think) would be updated and a backup created.  I gave that the go-ahead and I have a new IndySystem150.dproj in the \Lib\System directory, which did not exist in the zip file.  IndySystem150.dpk has not changed.  When I reopen IndySystem150.dpk in the IDE, I find myself in "IndySystem150 - Delphi XE - ProjectGroup1.groupproj."

 

Is my next move to choose "Compile IndySystem150" from the "Project" menu?  What will the compiled output be called and where will it be placed? The project option "Package Output Directory" has been set to $(BDSCOMMONDIR)Bpl (wherever that is! - there's a Bpl subdirectory under C:\Users\Public\Documents\RAD Studio\8.0, and it's empty).  Do I need to change the package output directory to avoid disturbing the original IndySystem150.bpl in RAD Studio\8.0\bin, or does that only arise at the next step of "installation"?

 

Where is my original installed version of the package anyway?  These are among the files that were created long ago when Delphi XE was installed:

  RAD Studio\8.0\source\Indy10\System\IndySystem.dpk

  RAD Studio\8.0\bin\IndySystem150.bpl   and other copies buried deep in ProgramData and in Users\AllUsers

  RAD Studio\8.0\lib\win32\debug\IndySystem.dcp

  RAD Studio\8.0\lib\win32\release\IndySystem.dcp

[Remy Lebeau 1401]

19 hours ago, giomach said:

From the directory where I unpacked Indy-master.zip, I opened Indy-master\Lib\System\IndySystem150.dpk in the IDE.  I got a warning that IndySystem150.dproj (I think) would be updated and a backup created.  I gave that the go-ahead and I have a new IndySystem150.dproj in the \Lib\System directory, which did not exist in the zip file.  IndySystem150.dpk has not changed.  When I reopen IndySystem150.dpk in the IDE, I find myself in "IndySystem150 - Delphi XE - ProjectGroup1.groupproj."

Sounds about right.  Modern Delphi prefers .dproj files for storing Project settings.  When you open a .dpk file and no .dproj file exists, a new .dproj file is created from the settings in the .dpk file.  And since you are not using a .groupproj file for a Project Group, a default Project Group is created for you, as well.

19 hours ago, giomach said:

Is my next move to choose "Compile IndySystem150" from the "Project" menu?

Yes.  And then repeat that for all 5 Indy packages (in this order): IndySystem, IndyCore, IndyProtocols, dclIndyCore, dclIndyProtocols.  And then you can install the 2 dcl Packages in the IDE if you want to (replacing the old one), or just update individual projects to reference the newer non-dcl packages as needed.

19 hours ago, giomach said:

What will the compiled output be called and where will it be placed?

That, I can't answer for sure.  It varies from one IDE version to another.  I don't know what the default are for XE.

19 hours ago, giomach said:

The project option "Package Output Directory" has been set to $(BDSCOMMONDIR)Bpl (wherever that is! - there's a Bpl subdirectory under C:\Users\Public\Documents\RAD Studio\8.0, and it's empty).

You can go into the IDE settings to see exactly where the BDSCOMMONDIR environment variable maps to.

19 hours ago, giomach said:

Do I need to change the package output directory to avoid disturbing the original IndySystem150.bpl in RAD Studio\8.0\bin

That would probably be a good idea.

19 hours ago, giomach said:

Where is my original installed version of the package anyway?

If you go into the IDE's Packages list, you can see exact where it loads installed BPLs from.

[giomach 1]

Many thanks again for your patience.

 

I've now compiled the five .dpks.  The new files created are:
• In "Package Output Directory": IndySystem150.bpl, IndyCore150.bpl, IndyProtocols150.bpl, dclIndyCore150.bpl, dclIndyProtocols150.bpl
• In "DCP Output Directory":     IndySystem150.dcp, IndyCore150.dcp, IndyProtocols150.dcp, dclIndyCore150.dcp, dclIndyProtocols150.dcp

The above directories were empty before compilation.

There were also loads of .dcu files and a few .proj files created.
 

I'm satisfied that all the files of my original (10.1.1) Indy installation are unchanged.
Note that I have NOT (yet) uninstalled anything.

 

The next step seems to be "installation", but I'm not clear what that means.
Is it about making the packages appear (or rather, updating them) in the IDE's Tool Palette?  And is it then only the two design-time packages that require installation?
In the IDE, do I: Open dclIndyCore150.proj, then Component/Install Packages?  And then the same for dclIndyProtocols.proj?
What files will that create, and how will I avoid disabling 10.1.1, which I might need for DataSnap in the future?
It doesn't look like I can have two versions of Indy installed in the IDE at the same time.

 

> you can install the 2 dcl Packages in the IDE if you want to (replacing the old one), or just update individual projects to reference the newer non-dcl packages as needed

Does that mean that I might not need to (re)install anything, but just change Project Options to pick up the new files?

 

Looking at the Indy 10.1.1 files, there are the five .bpl files in the \bin directory, all WITH the "150" suffix in their names
and three .dcp files, all WITHOUT the "150" suffix, in lib\win32\debug and three others (smaller) in lib\win32\release.

I suppose that's the structure I should be aiming for, but in different directories from 10.1.1.  How do I get there, please?

 

[Remy Lebeau 1401]

On 11/13/2021 at 11:59 AM, giomach said:

Is it about making the packages appear (or rather, updating them) in the IDE's Tool Palette?

Only if you want to be able to use Indy components in a Form Designer at design-time.  Otherwise, you can just create the components dynamically in code at runtime.

On 11/13/2021 at 11:59 AM, giomach said:

And is it then only the two design-time packages that require installation?

Yes.  Though, the runtime package binaries do need to be located where the IDE can find them when loading the design-time package binaries.

On 11/13/2021 at 11:59 AM, giomach said:

In the IDE, do I: Open dclIndyCore150.proj, then Component/Install Packages?  And then the same for dclIndyProtocols.proj?

Since you already compiled the binaries, you don't really need to compile them again, so you don't need to open the projects.  The "Install Packages" dialog is just looking for the .BPL binaries.  But yes, it would just be the two DCL packages.

On 11/13/2021 at 11:59 AM, giomach said:

What files will that create

None. You already created them.

On 11/13/2021 at 11:59 AM, giomach said:

how will I avoid disabling 10.1.1, which I might need for DataSnap in the future?

Basically, you can't.  But you can re-enable it when needed.

On 11/13/2021 at 11:59 AM, giomach said:

It doesn't look like I can have two versions of Indy installed in the IDE at the same time.

No, you can't.  But you can install packages on a per-project basis.  So, make sure no project is loaded, and then go into the "Install Packages" dialog and remove the Indy packages.  Then, load a project and re-add the appropriate Indy packages you want to use for that project.  Then close the project, load another project, and repeat.  As long as you maintain the separate Indy versions, you should be able to pick which version you want to use for each project.

 

Of course, this is all just contingent on installing Indy in the IDE at all.  If you create Indy components dynamically in code instead, then this matter becomes moot, since you can just make each project reference the appropriate Indy source/binaries folder as needed.

On 11/13/2021 at 11:59 AM, giomach said:

Does that mean that I might not need to (re)install anything, but just change Project Options to pick up the new files?

Yes.

[giomach 1]

Many thanks again.

 

I have to leave this project aside for a while, but I think I should be able to complete installation when I return to it, with the help I have received here.

[giomach 1]

I'm happy to report that the problem is solved, thanks of course to all the help I have had.

 

All I had to do to finish off was to uninstall (using Component/Install Packages) the old dclIndyCore150.bpl and dclIndyProtocols150.bpl (taking careful note of where they were to allow reinstallation if necessary), and install the new versions from the same menu.

 

Then, anywhere in the code that I had created      LHandler := TIdSSLIOHandlerSocketOpenSSL.Create(nil);
to introduce         LHandler.SSLOptions.SSLVersions := [sslvTLSv1, sslvSSLv2, sslvSSLv23, sslvSSLv3];

which statement had either been absent or had only "sslvTLS1" as parameter.

 

For the three runtime-only bpls, I had the three old versions in one directory and the three new versions in another.  Both directories were on the Windows PATH variable.  I simply renamed the three old versions to something else.

 

The dcp files promised to be a problem.  The old system had three run-time ones in a "debug" directory (on the project's "Debug DCU path") and three run-time ones in a "release" directory (on the project's "Library path").  The new system had created two design-time and three run-time ones, all in one directory, which is on the project's "Library path".  I didn't make any changes there, and was surprised to find that the project now worked.  Perhaps I was just lucky, for the moment.

 

The changes should be easy to reverse if I ever need  the old Indy version 10.1.1 again.  Thanks again for all the help.

[Remy Lebeau 1401]

1 hour ago, giomach said:

Then, anywhere in the code that I had created      LHandler := TIdSSLIOHandlerSocketOpenSSL.Create(nil);

to introduce         LHandler.SSLOptions.SSLVersions := [sslvTLSv1, sslvSSLv2, sslvSSLv23, sslvSSLv3];

which statement had either been absent or had only "sslvTLS1" as parameter.

Don't include sslvSSLv23 with other versions, that is a wildcard the IOHandler uses internally, it is not needed in this case. Also, you definitely should not include sslvSSLv2 and sslvSSLv3 at all (unless you really need them), as those are old and no longer secure.  Typically, you should include only the TLS versions:

LHandler.SSLOptions.SSLVersions := [sslvTLSv1, sslvTLSv1_1, sslvTLSv1_2];

 

[giomach 1]

sslvTLSv1_1 and sslvTLSv1_2 both still come up "undeclared identifier".

 

According to "About Delphi XE", I now have Indy 10.6.2.0 installed.

 

Could I be picking up the wrong .dcp file?

 

At the moment, the following parameter combinations work (with this server anyway): 23 ; 1 & 2 ; 1 & 23 ; 1 & 3 ; 2 & 23 ; 1 & 2 & 23 ; 1 & 2 & 3 ; 1 & 23 & 3 ; 1 & 2 & 23 & 3

 

Other combinations give the original error (1); error creating sll context (2); handshake failure (3 ; 2 & 3 ; 23 & 3 ; 2 & 23 & 3)

 

There are some strange results there, eg 1 and 2 each fail on their own, but work together.  I can see no pattern.

[Lajos Juhász 293]

12 hours ago, giomach said:

sslvTLSv1_1 and sslvTLSv1_2 both still come up "undeclared identifier".

 

According to "About Delphi XE", I now have Indy 10.6.2.0 installed.

Did you have IdSSLOpenSSL in uses?

[giomach 1]

I've got two source versions of IdSSLOpenSSL.pas on my machine, one is Indy 10.1.1 and one is Indy 10.6.2.

The reason I have both is that I'm trying to upgrade from 10.1.1 to 10.6.2, while keeping 10.1.1 available where I can reinstall it if necessary later.

 

I've tried to follow a correct upgrading process, and Delphi informs me that 10.6.2.0 is installed.

 

But clearly the Delphi compiler is still using the variable definitions from 10.1.1, even though the 10.6.2 source has been compiled.

 

I need to know where the compiler is getting these old definitions from.  I've tried disabling (by renaming) all the IndyProtocols.dcp files on my computer — I think that's where the compiled source goes — but it makes no difference.

 

One thing I have not done is to delete the old Indy components from the project and recreate them.  I don't think that is necessary?

 

About the .dcp files:

When I compiled Indy 10.6.2.0, I got five files called IndySystem150.dcp, IndyCore150.dcp, IndyProtocols150.dcp, dclIndyCore150.dcp, dclIndyProtocols150.dcp

With Indy 10.1.1, I had two sets of three files each: IndySystem.dcp, IndyCore.dcp, IndyProtocols.dcp — a set in release and a set in debug.

Should I have done something to convert the new dcps into two sets of three, dropping the 150 suffix, and ignoring the last two? How?
 

Edited December 7, 2021 by giomach
More info

[Remy Lebeau 1401]

On 12/6/2021 at 12:26 PM, giomach said:

sslvTLSv1_1 and sslvTLSv1_2 both still come up "undeclared identifier".

Then you are using a VERY old version of Indy and really should upgrade to the latest.

Quote

According to "About Delphi XE", I now have Indy 10.6.2.0 installed.

Most likely NOT 10.6.2.0 specifically, but some later version of 10.6.2.x, where x was unknown at the time your copy of Indy was compiled.

Quote

At the moment, the following parameter combinations work (with this server anyway): 23 ; 1 & 2 ; 1 & 23 ; 1 & 3 ; 2 & 23 ; 1 & 2 & 23 ; 1 & 2 & 3 ; 1 & 23 & 3 ; 1 & 2 & 23 & 3

Specifying multiple SSL/TLS versions will automatically enable sslvSSLv23 internally.  That is the wildcard that actually handles version negotiation at runtime.  You should not be specifying sslvSSLv23 explicitly at all.

Quote

Other combinations give the original error (1); error creating sll context (2); handshake failure (3 ; 2 & 3 ; 23 & 3 ; 2 & 23 & 3)

Makes sense, because nobody uses SSL v2.0 and v3.0 anymore, as they are no longer secure.  Don't use anything less than TLS v1.0, but even that is being phased out of modern servers nowadays, so you really need TLS v1.1 and v1.2 as an absolute minimum.

12 hours ago, Lajos Juhász said:

Did you have IdSSLOpenSSL in uses?

If that weren't the case, the other values (sslvSSLv2, sslvSSLv3, sslvSSLv23, and sslvTLSv1) wouldn't be compiling, either.

Edited December 7, 2021 by Remy Lebeau

[giomach 1]

22 hours ago, Remy Lebeau said:

Then you are using a VERY old version of Indy and really should upgrade to the latest.

Yes, that's what I'm trying to do.

 

The present state of play is as described in my reply yesterday to Lajos, which may have crossed with your message above.

[giomach 1]

I think the situation is not retrieveable, and I need to start the upgrade of Indy over again.  The problem appears to have been my reluctance to "remove" the various facets of the old version until after I had at least compiled the new one.  I still won't be deleting them, but I can make sure to move or rename them in advance.  The experience of packages gained so far will be a help, so grateful thanks for the help with that.

[giomach 1]

I have repeated the upgrade from Indy 10.1.1 to Indy 10.6.2, after renaming or moving every vestige of 10.1.1 source or dcps or dcus (including some buried in ProgramData, and including those from Delphi 10.4 community edition, which I installed but never use), and otherwise following the instructions (or so I believe).  The result was the same as before.

 

In the IDE, sslvTLSv1_1 and sslvTLSv1_2 are still "undeclared identifiers".  The line numbers shown when the cursor rests on sslvTLS1 or sslvSSLv2 or sslvSSLv23 or sslvSSLv3 is line 232, which is the line number in the 10.1.1 source file.

 

The removal of 10.4 did make one small difference.  With 10.4 present, the problem identifiers are underlined in red in the (XE) IDE.  With 10.4 absent, they are not underlined, and when the cursor rests on them, we see "erroneous type".  In either case, compilation produces "undeclared identifier".

 

I am still uncertain about the following points:

 

1. I have not deleted the old Indy components from the project and recreated them.  I don't think that is necessary?

 

2. About the .dcp files:

When I compile Indy 10.6.2, I get five files called IndySystem150.dcp, IndyCore150.dcp, IndyProtocols150.dcp, dclIndyCore150.dcp, dclIndyProtocols150.dcp

With Indy 10.1.1, I had two sets of three files each: IndySystem.dcp, IndyCore.dcp, IndyProtocols.dcp — a set in release and a set in debug.

Should I have done something to convert the new dcps into two sets of three, dropping the 150 suffix, and ignoring the last two? How?

 

I am getting close to giving up on performing this upgrade in the recommended way, and leaving the project in the deprecated (but working!) position of using sslvTLS1 in combination with one or more of the (older) SSL versions.

 

Edited December 9, 2021 by giomach
Correction to file extension

[Remy Lebeau 1401]

21 hours ago, giomach said:

In the IDE, sslvTLSv1_1 and sslvTLSv1_2 are still "undeclared identifiers".

Then you still have old files lingering somewhere. Or maybe the new LSP server hasn't parsed the newer files. I don't know.  It has been a long time since I last did an upgrade.  Try using a tool like SysInternals Process Monitor to see what files the IDE is actually touching as it is loading/compiling, maybe you will see something out of place.

Quote

1. I have not deleted the old Indy components from the project and recreated them.  I don't think that is necessary?

If you are referring to the DFMs, then probably not.  But it probably wouldn't hurt either, as there have been some declaration changes to properties/events over the years, depending on which components you are using.

Quote

2. About the .dcp files:

When I compile Indy 10.6.2, I get five files called IndySystem150.dcp, IndyCore150.dcp, IndyProtocols150.dcp, dclIndyCore150.dcp, dclIndyProtocols150.dcp

With Indy 10.1.1, I had two sets of three files each: IndySystem.dcp, IndyCore.dcp, IndyProtocols.dcp — a set in release and a set in debug.

There should have been dcl files produced, too, since those are part of the design-time packages that get installed on the IDE's Palette.

Quote

Should I have done something to convert the new dcps into two sets of three, dropping the 150 suffix, and ignoring the last two? How?

Embarcadero doesn't use the default DPK projects to compile the shipped version of Indy.  They use their own DPKs, for instance to enable the use of {$LIBSUFFIX}, which Indy hasn't adopted yet, but will eventually.  So, getting 5 DCPs with suffixes in their names is expected behavior, albeit not ideal behavior for modern IDEs.  Having the suffixes present only becomes an issue when you upgrade between major IDE versions, then you need to update any projects that refer to the suffixed DCPs.  LIBSUFFIX was introduced WAY back in Delphi 6 to avoid that.

Quote

I am getting close to giving up on performing this upgrade in the recommended way, and leaving the project in the deprecated (but working!) position of using sslvTLS1 in combination with one or more of the (older) SSL versions.

That really won't work when communicating with modern servers on the Internet.  SSL v2.0 and v3.0 are dead, nobody using them anymore.  And TLS v1.0 is fast being phased out.  You really need TLS v1.1 and v1.2 to communicate with current servers, with TLS v1.3 slowly being adopted, too.

Edited December 10, 2021 by Remy Lebeau

[giomach 1]

EDIT: PUT THIS ON HOLD UNTIL I INVESTIGATE FURTHER

 

Process Monitor revealed a load of Indy 10.1.1 .dcu files in the release and debug directories, where they were placed by the Delphi XE installation.

I moved these 10.1.1 dcu files out to new directories not on any path, and added the directories containing the new 10.6.2 dcu files to the search path.

The project now compiles, with sslvTLSv1, sslvTLSv1_1, sslvTLSv1_2 ... BUT ... when run it gives the original error "tlsv1 alert protocol version".

I don't think this can be the fault of the server or of the openssl dlls, for the following reason.

 

I cloned the project to another directory and ran it under the Delphi 10.4 community edition. It works perfectly there, to the same server, with Indy 10.6.2.0 (from Embarcadero), the same OpenSSL dlls (1.0.2u), the same selection of TLS versions (v1, v1_1, v1_2).  But I don't want to be using two versions of Delphi, so I still want to get this project working in XE, like my other (non-SSL) projects.

There must be something still not right about my upgrade of Indy under XE, but I have no idea what it could be.

 

Just to be clear about your answer to a previous question: all I should have to do with the five created 10.6.2 .dcp files is to ensure they are on the Library path, and there is no need to drop the 150 suffixes — is that correct? (And of course to have removed the 10.1.1 files.)

 

Edited December 12, 2021 by giomach
Putting query on hold pending more investigation

[Remy Lebeau 1401]

On 12/11/2021 at 1:32 PM, giomach said:

The project now compiles, with sslvTLSv1, sslvTLSv1_1, sslvTLSv1_2 ... BUT ... when run it gives the original error "tlsv1 alert protocol version".

I can't address that without seeing the actual TLS handshake in a working scenario vs a non-working scenario.

On 12/11/2021 at 1:32 PM, giomach said:

I don't think this can be the fault of the server or of the openssl dlls, for the following reason.

All that tells me is that your XE is either not actually upgraded to the same Indy version that 10.4 is using, or your XE project is not configured the same way as the 10.4 project.

On 12/11/2021 at 1:32 PM, giomach said:

There must be something still not right about my upgrade of Indy under XE, but I have no idea what it could be.

Neither do I.

On 12/11/2021 at 1:32 PM, giomach said:

Just to be clear about your answer to a previous question: all I should have to do with the five created 10.6.2 .dcp files is to ensure they are on the Library path, and there is no need to drop the 150 suffixes — is that correct? (And of course to have removed the 10.1.1 files.)

AFAIK, yes.

[giomach 1]

Project is now working with Indy 10.6.2 under XE.  I don't know what made the difference — possibly I had missed adding sslvTLSv1_1 and sslvTLSv1_2 to one of the several SSLVersions assignments in the program.  Thanks for the incredible help received on this list, especially to Remy.

 

Now I want to re-enable Indy 10.1.1 alongside 10.6.2.   So I will create a project and try setting project options to make it use 10.1.1 instead of 10.6.2.

 

Without going into details, it seems that my 10.1.1 .dcu files are being picked up correctly, but I'm not so sure about my 10.1.1 .bpl and .dcp files.

I have added the directories containing my 10.1.1 files of all three types to the project's search path, but it looks as if the bpls or dcps or both are pushed aside by the 10.6.2 files.  So I want to exclude the 10.6.2 .bpl and .dcp files from this project.

My 10.6.2 .bpl files are located in C:\Users\Public\Documents\RAD Studio\8.0\Bpl which is on the Windows system PATH (it's also the package output directory).
Even if I remove this directory from the Windows path – which I can't do permanently as it may affect other projects — that does not help with the 10.1.1 project:
although the directory is no longer listed by Windows in the system path, and after I decline XE's offer on startup (before a project is loaded) to add it to my system path,
it nevertheless reappears prepended to the "path" as displayed by XE in Tools/Options/Environment Variables.
And then when I try to install the 10.1.1 dclIndyCore150.bpl in the 10.1.1 project, I get "Another package with the same base name is already loaded" viz. the 10.6.2 one,
even though no Indy package is showing in the "Install Packages" list.
 

My 10.6.2 .dcp files are located in C:\Users\Public\Documents\RAD Studio\8.0\Dcp which is on the XE default search path
("inherited from base" and "inherited from environment options" as well) and on the XE library path (it's also the DCP output directory).
I don't know how to remove it from "inherited from environment options", or how to do this without affecting my other projects.