Upgrading OpenSSL on Windows 10

[Job Cacka]

Michael's point should be asked and answered first for your environment. 

To find all of the OpenSSL bits used on a windows system you would use
Powershell or a tool that flexes its use like PDQ Inventory. There is a
steep learning curve and it is probably off topic for this group but there
are several different ways to use powershell to gain this information from
different viewpoints (Installed files, registry, event log, etc...).

Thanks,
 Job

-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Michael
Wojcik via openssl-users
Sent: Monday, November 21, 2022 4:18 PM
To: openssl-users at openssl.org
Subject: Re: Upgrading OpenSSL on Windows 10

> From: openssl-users <openssl-users-bounces at openssl.org> on behalf of 
> Steven_M.irc via openssl-users <openssl-users at openssl.org>
> Sent: Monday, November 21, 2022 15:56
 
> However, I am running Windows 10, and since (unlike Linux) every piece 
> of software outside of Windows itself needs to be updated 
> individually, I don't know how to track down every single application that
might be using OpenSSL and make sure that the copy of OpenSSL it uses is
up-to-date.

You don't. There may be applications that have OpenSSL linked statically, or
linked into one of its own DLLs, or just with the OpenSSL DLLs renamed.

> As many of you would know, under repository-based systems (such as 
> most Linux distros), this would not be an issue as I could update every
single application (system or non-system) at once.

This is not true in the general case. There are applications which are
available on Linux which do not use the distribution's package manager.
There are applications which use their own OpenSSL build, possibly linked
statically or linked into one of their own shared objects or with the
OpenSSL shared objects renamed. Linux distributions have not magically
solved the problem of keeping all software on the system current.


Back to Windows: It is possible, with relatively little effort, to find all
the copies of the OpenSSL DLLs under their usual names on a system, and then
glean from them their version information. With significantly more effort,
you can search for exported OpenSSL symbols within third-party binaries,
which will detect some more instances. With quite a lot of additional
effort, you can winkle out binaries which contain significant portions of
code matching some OpenSSL release (see various research efforts on
function-point and code-block matching, and compare with alignment
strategies in other fields, such as genomics). If your definition of
"OpenSSL in an application" is not too ambitious, this might even be
feasible.

But to what end? Each application will either be well-supported, in which
case you can find out from the vendor what OpenSSL version it contains and
whether an update is available; or it is not, in which you'll be out of
luck.

This is true of essentially every software component, most of which are not
as well-maintained or monitored as OpenSSL. Modern software development is
mostly a haphazard hodgepodge of accumulating software of uncertain
provenance and little trustworthiness into enormous systems with
unpredictable behavior and failure modes. I'm not sure OpenSSL versions
should be particularly high on anyone's priority list.

What are you actually trying to accomplish? What's your task? Your threat
model?

--
Michael Wojcik