Re: Upgrading OpenSSL on Windows 10
> From: Steven_M.irc > Sent: Thursday, November 24, 2022 21:21 > > 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. > That's disheartening. My next computer will be running Linux and I was > thinking that (as long as I stick to > installing software from appropriate repositories) my update worries would be > over soon. That's the state of general-purpose software development. Believe me, having software automatically updated would by no means solve the most pressing security issues in the current software industry. > > It is possible, with relatively little effort, to find all the copies of > > the OpenSSL DLLs under their usual names on a system > Could you please provide me with a list of the usual names? At the moment I'm not in a position to do that, and it wouldn't achieve anything useful anyway. > I've got a lot of libssl DLL's on my system, but I'm not sure if they're part > of OpenSSL or some other implementation > of SSL. Filenames wouldn't prove anything anyway. > >I'm not sure OpenSSL versions should be particularly high on anyone's > >priority list. > As I understand it, OpenSSL is responsible for establishing HTTPS > connections, the primary protocol > for ensuring security and authenticity over the Internet, and you *don't* > think OpenSSL versions should > be a high priority? I don't understand your lack of alarm here. I'm not alarmed because I'm operating under a sensible threat model. What vulnerabilities are you concerned about? Why? What versions of OpenSSL do those apply to? Being "alarmed" without being able to answer those questions just means you're shooting in the dark. Frankly, after 2012 -- the year that brought us Heartbleed, Goto Fail, and severe vulnerabilities in most major TLS implementations -- there have been few published vulnerabilities of much concern to client-side TLS use, and most of those only apply to very high-value targets. TLS connections are not the low-hanging fruit. Attackers have much better return and much lower cost exploiting other vulnerabilities, including on the user side phishing and other social-engineering attacks, typosquatting, credential stuffing, and so on. On the service-provider side, software supply-chain attacks and poor organizational defenses are common threat vectors. Very few people will bother attacking HTTPS at the protocol level. It's not worth the effort. > >What are you actually trying to accomplish? What's your task? Your threat > >model? > I want to be able to trust the HTTPS connections between my PC and servers on > the Internet again; "Again" since when? "Trust" in what sense? "Trust", like "secure", doesn't mean anything useful in an absolute sense. It's only meaningful in the context of a threat model. For a typical computer user, TLS implementations is the wrong thing to worry about. Most home and employee individual users who are successfully attacked will fall victim to some sort of social engineering, such as phishing; to poor personal security practices such as weak passwords or password reuse; or to a server-side compromise they have absolutely no control over. Some will be compromised due to a failure to install updates to the OS or major software packages such as Microsoft Office long after those updates are released, but that's a less-common vector. HTTPS compromise is statistically insignificant. In the vast majority of cases, the dangers with HTTPS are what people use it for -- online shopping at sites with poor security, for example, or downloading malicious software -- not with the channel itself. -- Michael Wojcik
Re: Upgrading OpenSSL on Windows 10
Steven_M.irc via openssl-users wrote: > Hi Michael, Thanks very much for replying to my e-mail/post. I > apologize for the lateness of my reply. >> 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. > That's disheartening. My next computer will be running Linux and I was > thinking that (as long as I stick to installing software from > appropriate repositories) my update worries would be over soon. It's not specific to Linux. Almost every single "big" application (Chrome, Firefox, OpenOffice) brings their own shared objects. Some of them contain security mechanisms. My impression is that you have just enough knowledge to be dangerous. >> It is possible, with relatively little effort, to find all the copies >> of the OpenSSL DLLs under their usual names on a system > Could you please provide me with a list of the usual names? I've got a > lot of libssl DLL's on my system, but I'm not sure if they're part of > OpenSSL or some other implementation of SSL. no, I can't/won't. Two reasons: 1) I can't because they don't have "usual names", 2) you should rely on your distribution to do the updates, and if you install packages using other means, then you should rely on those mechanisms. If someone tells you to "telnet fobar.com|sh", then you should be concerned that they are probably not clueful enough to keep your up-to-date. >> I'm not sure OpenSSL versions should be particularly high on anyone's >> priority list. > As I understand it, OpenSSL is responsible for establishing HTTPS > connections, the primary protocol for ensuring security and > authenticity over the Internet, and you *don't* think OpenSSL versions > should be a high priority? I don't understand your lack of alarm here. 1) Bugs show up everywhere. You should be concerned about all libraries that do all sorts of things. 2) Browsers tend to bring their own TLS implementation, which they auto-update. 3) Since your desktop is a client systems, it probably isn't subject to attack. >> What are you actually trying to accomplish? What's your task? Your >> threat model? > I want to be able to trust the HTTPS connections between my PC and > servers on the Internet again; whether I'm using a browser, a software > installer (that downloads data from the Internet before installing), a > peer-to-peer application, or any other network application. You can/should trust them as much this year as you did in 1997.
Re: Upgrading OpenSSL on Windows 10
On Friday, 25 November 2022 05:21:00 CET, Steven_M.irc via openssl-users wrote: Hi Michael, Thanks very much for replying to my e-mail/post. I apologize for the lateness of my reply. 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. That's disheartening. My next computer will be running Linux and I was thinking that (as long as I stick to installing software from appropriate repositories) my update worries would be over soon. I'm pretty sure what Michael had in mind, is that you can have software that runs on Linux that doesn't use system-provided OpenSSL (e,g. proprietary software). Well built distros, or even wll-built third party repos, will follow packaging guidelines of a given distribution. And many distributions forbid distributing copies of libraries that are already included in the distro proper. So if you stick to software from official repositories, you should generally be fine (unless you go for some very obscure and badly built distro). I'm not sure OpenSSL versions should be particularly high on anyone's priority list. As I understand it, OpenSSL is responsible for establishing HTTPS connections, the primary protocol for ensuring security and authenticity over the Internet, and you *don't* think OpenSSL versions should be a high priority? I don't understand your lack of alarm here. Not necessarily, you can have an application using multiple cryptographic libraries at the same time, but for different purposes. Application built for Windows may well use schannel for establishing HTTPS connections and OpenSSL for encrypting the local files. Then a security vulnerability in OpenSSL's TLS implementation won't affect the application. -- Regards, Hubert Kario Principal Quality Engineer, RHEL Crypto team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
RE: Upgrading OpenSSL on Windows 10
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 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-boun...@openssl.org On Behalf Of Michael > > Wojcik via openssl-users > Sent: Monday, November 21, 2022 4:18 PM > To: openssl-users@openssl.org > Subject: Re: Upgrading OpenSSL on Windows 10 > > > From: openssl-users openssl-users-boun...@openssl.org on behalf of > > Steven_M.irc via openssl-users openssl-users@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
Re: Upgrading OpenSSL on Windows 10
Hi Michael, Thanks very much for replying to my e-mail/post. I apologize for the lateness of my reply. > 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. That's disheartening. My next computer will be running Linux and I was thinking that (as long as I stick to installing software from appropriate repositories) my update worries would be over soon. >It is possible, with relatively little effort, to find all the copies of the >OpenSSL DLLs under their usual names on a system Could you please provide me with a list of the usual names? I've got a lot of libssl DLL's on my system, but I'm not sure if they're part of OpenSSL or some other implementation of SSL. >I'm not sure OpenSSL versions should be particularly high on anyone's priority >list. As I understand it, OpenSSL is responsible for establishing HTTPS connections, the primary protocol for ensuring security and authenticity over the Internet, and you *don't* think OpenSSL versions should be a high priority? I don't understand your lack of alarm here. >What are you actually trying to accomplish? What's your task? Your threat >model? I want to be able to trust the HTTPS connections between my PC and servers on the Internet again; whether I'm using a browser, a software installer (that downloads data from the Internet before installing), a peer-to-peer application, or any other network application. Thank you for your time. Steven
RE: Upgrading OpenSSL on Windows 10
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 On Behalf Of Michael Wojcik via openssl-users Sent: Monday, November 21, 2022 4:18 PM To: openssl-users@openssl.org Subject: Re: Upgrading OpenSSL on Windows 10 > From: openssl-users on behalf of > Steven_M.irc via openssl-users > 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
Re: Upgrading OpenSSL on Windows 10
> From: openssl-users on behalf of > Steven_M.irc via openssl-users > 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
Upgrading OpenSSL on Windows 10
Hi All, A few weeks ago I sent this e-mail to the group: https://mta.openssl.org/pipermail/openssl-users/2022-November/015613.html I received a couple of replies, but sadly I have been too busy to respond to them. Regardless, I need a bit more information please. In one of the replies, Viktor said "Just upgrade any affected systems and you'll be fine.". 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. 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. For those of you who may be thinking "but Windows doesn't use OpenSSL"; when the latest OpenSSL vulnerabilities were discovered I asked a Windows IRC channel whether or not Windows uses OpenSSL, the reply was that Windows itself does not use it, but many applications running on Windows do. Thank you all for your time.
