Direct Links:
http://indy.fulgan.com/SSL/openssl-0.9.8y-i386-win32.zip
http://indy.fulgan.com/SSL/openssl-0.9.8y-x64_86-win64.zip
http://indy.fulgan.com/SSL/openssl-1.0.0k-i386-win32.zip
http://indy.fulgan.com/SSL/openssl-1.0.0k-x64_86-win64.zip
http://indy.fulgan.com/SSL/openssl-1.0.1e-i386-win32.zip
http://indy.fulgan.com/SSL/openssl-1.0.1e-x64_86-win64.zip

Recommended Versions highlighted.

I am going to post about the changes to my blog, the DEC and so on in a few weeks. Stay tuned! Had been a busy time

Direct Links:
http://indy.fulgan.com/SSL/openssl-0.9.8x-i386-win32.zip
http://indy.fulgan.com/SSL/openssl-0.9.8x-x64_86-win64.zip
http://indy.fulgan.com/SSL/openssl-1.0.0j-i386-win32.zip
http://indy.fulgan.com/SSL/openssl-1.0.0j-x64_86-win64.zip
http://indy.fulgan.com/SSL/openssl-1.0.1c-i386-win32.zip
http://indy.fulgan.com/SSL/openssl-1.0.1c-x64_86-win64.zip

Recommended Versions highlighted.

Please note: Further Updates will be slightly delayed during this summer for personal reasons.

Direct Links:
http://indy.fulgan.com/SSL/openssl-0.9.8w-i386-win32.zip
http://indy.fulgan.com/SSL/openssl-0.9.8w-x64_86-win64.zip
http://indy.fulgan.com/SSL/openssl-1.0.0i-i386-win32.zip
http://indy.fulgan.com/SSL/openssl-1.0.0i-x64_86-win64.zip
http://indy.fulgan.com/SSL/openssl-1.0.1b-i386-win32.zip
http://indy.fulgan.com/SSL/openssl-1.0.1b-x64_86-win64.zip

Recommended Versions highlighted.

Direct Links:
http://indy.fulgan.com/SSL/openssl-0.9.8u-i386-win32.zip
http://indy.fulgan.com/SSL/openssl-0.9.8u-x64_86-win64.zip
http://indy.fulgan.com/SSL/openssl-1.0.0h-i386-win32.zip
http://indy.fulgan.com/SSL/openssl-1.0.0h-x64_86-win64.zip

New (yet untested) is the 1.0.1 branch. Feel free to try and report issues (or success):
http://indy.fulgan.com/SSL/openssl-1.0.1-i386-win32.zip
http://indy.fulgan.com/SSL/openssl-1.0.1-x64_86-win64.zip

Cheers
Arvid

Direct links for the updated versions:
http://indy.fulgan.com/SSL/openssl-0.9.8t-i386-win32.zip
http://indy.fulgan.com/SSL/openssl-0.9.8t-x64_86-win64.zip
http://indy.fulgan.com/SSL/openssl-1.0.0g-i386-win32.zip
http://indy.fulgan.com/SSL/openssl-1.0.0g-x64_86-win64.zip

The update fixes a possible DTLS DoS attack. This is related to encrypted Datagrams, e.g. encrypted VoIP or Audio/Video Streams (and encrypted UDP in general).

- Arvid

P.S.: Update has been on the server for a few days, forget to publish this post. Sorry about.

Direct links for the updated versions:
http://indy.fulgan.com/SSL/openssl-0.9.8s-i386-win32.zip
http://indy.fulgan.com/SSL/openssl-0.9.8s-x64_86-win64.zip
http://indy.fulgan.com/SSL/openssl-1.0.0f-i386-win32.zip
http://indy.fulgan.com/SSL/openssl-1.0.0f-x64_86-win64.zip

Those updates include important Bug and Security Fixes, updating is recommended.

- Arvid

Direct Download
for Win32: http://indy.fulgan.com/SSL/openssl-1.0.0e-i386-win32.zip
for Win64: http://indy.fulgan.com/SSL/openssl-1.0.0e-x64_86-win64.zip

As usual you’ll find the ReadMe, Hashes and the OpenSSL binary inside of the ZIP.

Cheers,
Arvid

after some weeks of extensive testing I am now releasing updated versions of the above mentioned OpenSSL DLLs. Those libraries are now tested with Windows 2000 up to Windows 7 (x32 and x64 where available). As usual there are no dependencies to any runtime libraries beside the common Kernel/WinSock2 etc.pp.

As I mentioned in the Important Compatibility Announcement two weeks ago I had made a mistake during the compilation of the last two published OpenSSL versions which led to an incompatibility with Windows 2000 and early XP versions. Check the linked post for a list of affected versions.

The issue is now fixed.

Here are the direct links for the updated release for Win32/64:
http://indy.fulgan.com/SSL/openssl-0.9.8r-i386-win32-rev2.zip
http://indy.fulgan.com/SSL/openssl-1.0.0d-i386-win32-rev2.zip
http://indy.fulgan.com/SSL/openssl-0.9.8r-x64_86-win64-rev2.zip
http://indy.fulgan.com/SSL/openssl-1.0.0d-x64_86-win64-rev2.zip

I am sorry for the inconvenience caused and I would like to thank Jason Smith again for bringing this issue to my attention and Salvor Hardin for his help!

As Salvor stated in one of his comments using Visual C++ 2008 with an adjusted makefile works (the /MT switch as mentioned in the previous post). We should keep in mind that this way of building the DLLs may not work in future but for now and the next few years it should do the trick. To make it short – @Savlor: You were right!

Cheers,
Arvid

The affected OpenSSL versions are:
0.9.8 q, 0.9.8 r, 1.0.0 c and 1.0.0 d.

Technical Background:

The mentioned libraries statically link against a version of msvcrt.lib which include references to EncodePointer/DecodePointer and _except_handler4_common. EncodePointer and DecodePointer are only available with the aforementioned OS versions. The CRT exception handler 4 has been introduced with newer versions of msvcrt.dll too (XP iirc).

Since mid 2010 I used a different approach in building the libraries, instead of my old-fashined mingw gcc 3.4.5 build chain Salvor came up with the idea to use VC++ with special adjustments as posted in his comment here.

Typically DLLs created with VC newer than 6 have dependencies to the corresponding runtime libraries (the well-known msvcrt##.dll). Using his approach removed this dependencies. My initial tests with XP, 2003, Vista and Win 7 didn’t show any problems, Dependency Walker had not shown problems too. But as it turns out now Salvor didn’t take the changed feature set of msvcrt.dll into account. And I didn’t do either.

I spend a large amount of time within the past two weeks to test all available build chains possible, including VC 2008 and 2010 together with masm and nasm, mingw with gcc 3.4.5 up to gcc 4.5.2 and today even the Windows Device Driver Kit 7.1 together with PSDK 2003 and SDK for Win 7 and .NET 4. Using the DDK was an interesting approach to circumvent the mentioned problems (Thanks to Mladen Turk for his interesting post titled Fighting the MSVCRT.DLL hell), but fails with the exception handler 4 too.

I am aware of the stubs published at StackOverflow regarding this issue with Encode/DecodePointer, but believe me that’s nothing we want in productive code.

Currently the only two working alternatives are:

• gcc 3.4.5
• VC++ 6

As we switched away from gcc 3.4.5 for several reasons (size and performance of the created libraries) I would prefer using VC++ 6.0. The OpenSSL build chain for gcc 4 is broken like the BCB chain is for years now. I cannot afford spending so much time on fixing the perl scripts with every OpenSSL release. Currently I publish four sets of files with every OpenSSL release (0.9.8.x for x32 and x64, 1.0.0.x for x32 and x64) and create 2 additional ones for internal FIPS 140 tests. Together with testing the libraries and the preps needed for publishing this became a lot of work compared to the past years.

Why don’t you just use other precompiled binaries?

I know what you’re talking about. The precompiled libraries other vendors like Shining Light publish do require the MS VC runtime dlls. We want to give the Indy the possibility to ship OpenSSL without any VCRT dlls. Afaik the newer VCRT requires that you include the official MSI packages. This has many drawbacks.

What do you need to do now?

Please check if you use any of the above mentioned Indy OpenSSL libraries in a productive environment together with an OS older than the supported ones. If that may be true I would suggest updating your release information, platform requirements or inform your users / customers where needed.

This is only required if you use our libraries (as published on the Fulgan mirror).

Note the reverting back to an older version of OpenSSL is not an option due to well-known security issues as published on the OpenSSL site or US CERT.

What can you do to help?

I would like to ask for a donation of a single copy license of MS VC++ 6 or MS Visual Studio 6 (English). This would help tremendously with the effort to keep the old OSs like Win 2000 supported way beyond what MS does on it’s own. We have a bunch of licenses, tools and compilers available here at the office but nothing that old as the ancient VC 6

So, if anybody is willing to help the Indy team (and me) drop a mail to winkelsdorf [at] gmail [dot] com.

Thanks to Jason Smith for bringing up this issue to the Indy team at the Atozed Newsgroup!

Cheers,
Arvid

[Edit2]
Removed my rant about those DelphiFeeds Off-Topic Voters
[/Edit2]

You can download precompiled versions of the new OpenSSL libaries from our official Indy Mirror (The Fulgan Mirror).

Direct Links for the x32 versions:
http://indy.fulgan.com/SSL/openssl-0.9.8r-i386-win32.zip
http://indy.fulgan.com/SSL/openssl-1.0.0d-i386-win32.zip

The 0.9.8 branch is only made available for compatibility reasons, if you have the choice take the newer 1.0 version. Both versions are supported by Indy, so it’s up to you.

You’ll find a “ReadMe”, License Information and File Hashes inside the zip archives. This version is including important bug and security fixes, using it is strongly recommended. The DLLs have no dependencies and are ready to use (ready for shipping with your application).

We include the OpenSSL.exe in the download, too. This file is not required for deployment of your own application, but it may be useful for handling certificates on your own during app development.

Regards,
Arvid