OpenSSL v0.9.8m for Indy


I just prepared and published an updated precompiled version of the OpenSSL libraries. As always they are available on the official Indy Mirror, the Fulgan Mirror.

Direct Link:

You’ll find a ReadMe, License Information and File Hashes inside the zip archive. This version is including important bug and security fixes, using it is strongly recommended.



9 thoughts on “OpenSSL v0.9.8m for Indy

  1. I didn’t know Arvid would post this today, so I tried a few things.

    My findings were surprising.

    I was unable to build OpenSSL 0.98m using Embarcadero C++ 2010.

    I tried building OpenSSL 0.98m with Microsoft Visual C++ 2008 using the instructions in INSTALL.W32. But the default settings require deploying MSVC runtime DLL.

    I changed “/MD” to “/MT” in ms/ntdll.mak and resulting DLL’s don’t require any more runtime DLL’s than MinGW.

    No MSVC++ runtime DLL’s needed and OpenSSL binaries are smaller compared to ones compiled by MinGW! If I had time, I’d do benchmarks.

    So far, it is working great with Delphi 2010 apps using Synapse. I haven’t done multithreaded stress tests, yet.

    Embarcadero needs to work with the OpenSSL team, because Borland C++ 5.0 is the latest version mentioned by OpenSSL. That is embarrassing as not being able to compile.

    • Hi Salvor,

      yes the lack of C++ Builder support is one of the reasons to use gcc. The DLLs you created are usable with any newer Indy version too, there are no more adjustments needed. We are “just” publishing them in order to provide something like an out-of-the-box experience when using Indy and SSL/TLS (without the need for MS VC Runtime DLLs as you already mentioned and most precompiled OpenSSL libraries available need).

      The drawback of using gcc is a slightly larger size of the resulting files.

      One thing regarding your experience: Are you sure there are no dependencies? I mean did you check it with Dependency Walker or something like that? If so, I will need to check that again, regarding Win32 we might move to that build environment after doing some tests.


  2. Hi Arvid,

    Yes, I checked using Dependency Walker.
    Here’s what I did using Microsoft Visual C++ 2008 SP1:

    1. perl Configure VC-WIN32 –prefix=c:/temp
    2. notepad.exe msntdll.mak // replace “/MD” with “/MT”
    3. msdo_masm
    4. nmake -f msntdll.mak
    5. nmake -f msntdll.mak test
    6. editbin.exe /rebase:base=0x11000000 libeay32.dll
    7. editbin.exe /rebase:base=0x12000000 ssleay32.dll

    IMHO, building with Embarcadero C++ 2010 and being able to static link into a Delphi or Embarcadero C++ EXE would be super. I hate using DLLs for crypto since calls are so easy to intercept (no programming skills needed.)

  3. @Salvor

    Nice solution, despite I think we will get troubles with our internal test regarding the FIPS versions of OpenSSL when we adjust the build process.

    I would suggest you open a ticket at the RT of the OpenSSL team for a feature request about. I will of course support this approach!

    Regarding C++ Builder I am still looking forward for David Dean’s tests:

    He says he has this on his list.


  4. Hei

    I have a problem with OpenSSL v0.9.8m for Indy (I use 10.5.5). My code works fine with Indy 9.X and OpenSSL v0.9.7, but now I use Delphi 2010 with Indy 10.5.5 and OpenSSL v0.9.8m and there is access violation. Any suggestions?

    uses IdSSL, IdSSLOpenSSL, IdSSLOpenSSLHeaders

    function RSA_new:pRSA; cdecl; external ‘libeay32.dll’;//this function was not described in IdSSLOpenSSLHeaders.pas
    function BN_bin2bn(const _from: pointer; len: integer; ret: pBIGNUM): pBIGNUM; cdecl; external ‘libeay32.dll’;//this function was not described in IdSSLOpenSSLHeaders.pas

    procedure TForm1.Button1Click(Sender: TObject);
    publicKey, Signature, ResultArray : array[1..256] of AnsiChar;
    publicKeyExponent : array [1 .. 3] of ansichar;
    resultValue, keyLen, exponentLen : Integer;
    CryptLibHandle : Cardinal;
    rsaMethods : IdSSLOpenSSLHeaders.RSA_METHOD;
    rsaBody : IdSSLOpenSSLHeaders.pRSA;

    //publicKey, Signature, publicKeyExponent are assigned, also keyLen and exponentLen gets his value

    if not IdSSLOpenSSL.LoadOpenSSLLibrary then begin
    MessageDlg(‘Unable to load SSL library’,mtInformation,[mbOK],0);

    rsaBody := RSA_new;

    CryptLibHandle := IdSSLOpenSSLHeaders.GetCryptLibHandle;
    rsaMethods.rsa_pub_dec := GetProcAddress(CryptLibHandle, PChar(‘RSA_public_decrypt’));//this method was not initilaized in LoadOpenSSLLibrary

    if @rsaMethods.rsa_pub_dec = nil then begin
    MessageDlg(‘Unable to load function rsa_pub_dec’,mtInformation,[mbOK],0);

    rsaBody.n := BN_bin2bn(@publicKey, keyLen, rsaBody.n);
    rsaBody.e := BN_bin2bn(@publicKeyExponent, exponentLen, rsaBody.e);

    resultValue := rsaMethods.rsa_pub_dec(keyLen,@Signature,@ResultArray,rsaBody,OPENSSL_RSA_NO_PADDING);//access violation at address 61D9484F in module libeay32.dll šŸ˜¦

  5. @Joe
    Shalom Joe šŸ˜‰

    No, I disagree that a version information makes a file unsuspicious. We build the files 1:1 using the OpenSSL make process, any change to that process will actually make the files “suspicious”, even if those changes are just related to version info.

    OpenSSL provides version information through it’s API, that’s the way to go, especially when talking about our experimental FIPS versions.


  6. Pingback: Arvid’s Blog @ digivendo » Important Compatibility Announcement regarding OpenSSL

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s