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@xxxxxxxxxxx> On Behalf Of Michael Wojcik via openssl-users Sent: Monday, November 21, 2022 4:18 PM To: openssl-users@xxxxxxxxxxx Subject: Re: Upgrading OpenSSL on Windows 10 > From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> on behalf of > Steven_M.irc via openssl-users <openssl-users@xxxxxxxxxxx> > 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
