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.
Probably.
> 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
change.
> 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.
Grüße,
Sven.
--
Sigmentation fault. Core dumped.
Reply to: