​​> 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

Reply via email to