> From: Steven_M.irc <steven_m....@proton.me> > 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
