Where do I get IdHTTP, IdSSL, IdGlobal and IdSSLOpenSSL Units?

[Thaddy]

So? OpenSSL is not installed, has the wrong bitness (32 or 64) or is not correctly installed.
For 32 bit programs you need 32 bit OpenSSL binaries
For 64 bit programs you need 64 bit OpenSSL binaries
And your program needs to be able to find them.
OpenSSL as such is not part of Indy, although the official Indy website does provide OpenSSL binaries in both 32 and 64 bit flavors for your convenience.

[DragoRosso]

You must use for your convenience the two dll:

- libeay32.dll
- ssleay32.dll

These file are inside the zip files:

for 64 bit application
- openssl-1.0.2u-x64_86-win64.zip

for 32 bit application
- openssl-1.0.2u-i386-win32.zip

This is the repository of Indy:

https://github.com/IndySockets/OpenSSL-Binaries

[Thaddy]

Tnx for adding the paths, I forgot, because I do not use Indy. I use fcl-net/fcl-web only and compile openssl from source.(not recommended for casual users! be warned.)
But those also need the proper OpenSSL or alternative installed.

[OC DelGuy]

So? OpenSSL is not installed, has the wrong bitness (32 or 64) or is not correctly installed.

I'm running Windows11 64 bit, so I assume Laz is compiling in 64bit.  How do I check if it's installed, if it's 64 bit, and if it's installed correctly?

And your program needs to be able to find them.

How do I make sure it does?


And how do I install the .DLL's (if indeed they're not installed).  I downloaded a Zip file and it just has the .DLL files.  Do I need to just copy them to a specific directory?  Do I need to do something in the IDE settings so it knows they're there? 

[rvk]

And how do I install the .DLL's (if indeed they're not installed).  I downloaded a Zip file and it just has the .DLL files.  Do I need to just copy them to a specific directory?  Do I need to do something in the IDE settings so it knows they're there?

Just copy them to your exe directory.

(I know not everyone agrees but it's the easiest and safest way.)

[Remy Lebeau]

Just copy them to your exe directory.

(I know not everyone agrees but it's the easiest and safest way.)

Agreed. However, you can copy the DLLs to whatever folder you want. But, if that folder is not on the system search path, you can use the IdOpenSSLSetLibPath() function to tell Indy where it is.

[OC DelGuy]

And how do I install the .DLL's (if indeed they're not installed).  I downloaded a Zip file and it just has the .DLL files.  Do I need to just copy them to a specific directory?  Do I need to do something in the IDE settings so it knows they're there?

Just copy them to your exe directory.
(I know not everyone agrees but it's the easiest and safest way.)

Hi Y'all.
Sorry it took me so long to answer...
I downloaded the right ZIP file.  I copied the two DLL files to the program directory, Still got an error.  Where the **boink** did I screw up this time?

[rvk]

Find out what TLS version the server uses. You didn't provide the url so we can't check.

It's either too old (TLS1) which openssl1.0.2u doesn't support anymore.
Or it's too new (TLS1.3+) which openssl1.0.2u doesn't support yet in which case you need to use openssl1.1.1.

[Thaddy]

Seems indeed too old. The error refers to tlsv1 as the cause and the server running openssl v3 reporting.
Btw, instead of openssl 1.1.1 you can also use client-side openssl v3, but I do not know if indy supports that. fcl-net in trunk does support that and that is what I use.

[Remy Lebeau]

The error refers to tlsv1 as the cause

The TIdSSLIOHandlerSocketOpenSSL component enables only TLS v1.0 by default. You have to configure it manually to enable TLS v1.1 and v1.2, by using the SSLOptions.SSLversions property, eg:

Code: Pascal  [Select][+][-]

1. var
2.   ...
3.   SSL: TIdSSLIOHandlerSocketOpenSSL;
4. ...
5. SSL := TIdSSLIOHandlerSocketOpenSSL.Create(HTTP);
6. SSL.SSLOptions.SSLVersions := [sslvTLSv1, sslvTLSv1_1, sslvTLSv1_2];
7. HTTP.IOHandler := SSL;

and the server running openssl v3 reporting.

The error message does not indicate that. The mention of ssl3 is just how OpenSSL implements TLS internally, as TLS v1.0 was originally based on SSL v3.0.

Btw, instead of openssl 1.1.1 you can also use client-side openssl v3, but I do not know if indy supports that.

It does not, yet. Long time work-in-progress. But there are a few 3rd party repos that add v3 support on top of the stock Indy.

[Thaddy]

The error refers to tlsv1 as the cause

The TIdSSLIOHandlerSocketOpenSSL component enables only TLS v1.0 by default. You have to configure it manually to enable TLS v1.1 and v1.2, by using the SSLOptions.SSLversions property, eg:

Then that should be fixed in a similar manner that the core team used on my request: greedy, i.e. highest first in all cases until a supported handshake is found, else abort with error. This also scales better to future versions.
That is quite a serious bug, Remy.
The average user is not very protocol savvy - if at all - so better to prevent the ever recurring questions regarding this subject by fixing the code in a way we know will work.
There are two thinks needed:
- High to low protocol support.
- A damned well worded error message that explicitly explains to the user's  encryption libs are not up-to-date and that that is user error.

[DragoRosso]

That is quite a serious bug, Remy.

Talking about "bugs" seems a bit extreme to me.
We could talk about a proposal for improvement, which is more appropriate to the situation.
Indy has been like this since TLS support existed and it is for compatibility with the past that it is better to stay that way.
Changes like this should be made with new versions.
For error messages, I do not agree with "simplifying" them because now they give exactly the precise point on what is wrong.
Maybe they are a bit "technical", but honestly I prefer a precise technical message than a generic message that does not lead me anywhere.
I agree that not everyone is a specialist in security protocols, but in any case it is being implemented and therefore a minimum of knowledge must be put into play, we are programmers not end users.

[rvk]

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

Yes, but is sslvTLSv1 still present in openssl1.0.1u ??
I thought it was stripped from there.
So if the error is about the server expecting TLS1, you would need an older openssl version dll.

[Thaddy]

From u it is stripped, you are correct. It is the component with a hard-coded!!!! default. It should be soft-coded and high to low.
Hence I wrote to Remy that I consider that a big bug.

[DragoRosso]

Yes, but is sslvTLSv1 still present in openssl1.0.1u ??
I thought it was stripped from there.

From u it is stripped, you are correct. It is the component with a hard-coded!!!! default. It should be soft-coded and high to low.
Hence I wrote to Remy that I consider that a big bug.

What makes you write this? Do you have any official links on this?
I use Indy with OpenSSL 1.0.2u, 1.1.1w and 3.1.7

In 1.0.2 and 1.1.1 TLSv1 through TLSv1_1 is still available and working.

IT'S NOT A BUG SUPPORT THEM ... It's a bug doesn't support them, although I think they shouldn't be used normally.

EDIT: I'm talking about the use, not the hard coding default. You can simple change it with one line of code (may be 3 lines of code ...)