Upgrading OpenSSL on Windows 10

[Steven_M.irc]

Hi Job,
Thanks very much for your reply. Apologies for the lateness of mine.

I will ask around and get more information about Powershell and PDQ Inventory.

Thanks again,
Steven




Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, November 23rd, 2022 at 5:36 AM, Job Cacka <job at ccbox.com> wrote:


> 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