[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 )

Michael Grant <mgrant@grant.org> wrote:

> Nifty, been a while since I used the LD_PRELOAD trick myself.

> This whole thing has been bothering me over the last couple days.  Why
> are so few people having this issue?  18 or so posts on this, only 3
> or so of us have done anything about this.  I backed out libssl (and
> pinned it).  Reco makes a LD_PRELOAD hack.  Sven recompiles OpenSSL
> with patch removed.

> Did this or will this patch get into Stretch Stable yet as a security
> patch?  If yes, then won't there be hundreds if not thousands of
> people screaming about this?

No, it won't.

> I am wondering why it's so few of us who seem to be affected?  I
> suspect it's because 1) we're running Debian Testing and most of the
> Debian world runs Stable, 2) more and more people are turning to gmail
> and outlook.com instead of running their own mail servers and 3) the
> few remaining people who do go to the trouble of using Debian Testing
> as a mail server probably wouldn't care that much about getting TLS
> set up with imap/pop/smtp working at all.


> If this patch won't go to Stretch as a security fix, then the world is
> hidden from this until Buster comes out in about 2 years.

Exactly. Read the discussion(s) in debian-devel about this. The last
idea was to have Buster semi-broken until shortly before the release and
then switch back on TLS1.0 and TLS1.1 support.

> But what's going to happen if there is some other security fix which
> is needed in Stretch's libssl1.1 (1.1.0f-3)?  Will there be some fork
> of this library for Stretch without this patch?  Or will at that time
> this patch get swept in with some other future security patch and the
> hit the wild with Stretch stable + security patches?

Since this patch is a Debian-only change and in no way included in
upstream in any way, a security update for Stretch will not contain this

> By pinning this library at 1.1.0f-3 on my system, I feel somehow I've
> done the wrong thing.

We all habe done the wrong thing by diverting from the main development
path of Buster.

> I started to think I should put in Reco's hack until these Windows 7
> and Mac 10.11 users move to more modern releases or MS and Apple send
> out patches for their older stuff.  Or maybe I should follow Stretch
> (and it's security fixes) for only this package instead of pinning it
> to this version.

Pinning this package to Stretch will not work very long, I think. At
some point Stretch and Buster will have diverged to far for the library
from Stretch being compatible with the rest of Buster.

> And by the way, this isn't just limited to mail clients.  It's also
> affecting MTAs.  I see a large number of mail servers connecting to my
> server that only do TLSv1 and TLSv1.1.  When they can't do TLS, I
> think they just fall back to SMTP in the clear.  So the problem isn't
> obvious to any user and mail in general is just less secure.

It is far more problematic for WLAN+freeradius. Currently ~50% of
Android phones can't use TLS1.2 for the SSL handshake during the EAP
phase of the WPA-Enterprise login.

Also Windows 7 and Windows 8/8.1 are unable to connect because of the
same problem.

> While I am totally sympathetic to getting the world onto TLSv1.2 and
> greater, this seems like a support disaster waiting to happen.

Oh yes, absolutley. I admin many servers and infrastructure in an
University network and if this change happens to be included in Buster,
I will either have to recompile OpenSSL forever, backing out the change,
or, more likely, switch all systems to a different distribution,
probably CentOS.

I can't just tell the majority of my students to get a new phone or
laptop because some Developer thaught he could pressure the world to
rotate in a different direction by decree.

In two years when Buster is release, adoption of TLS1.2-only will not be
high enough to just switch off everything else.

> What is the right way for an admin to handle this problem on Debian Testing?

Don't use Debian Testing on production systems.


Sigmentation fault. Core dumped.

Reply to: