Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 )
On Thu, Sep 07, 2017 at 10:50:00PM +0100, Michael Grant 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?
There are few that are running servers on Debian testing. Most are
running desktops. The most popular program on desktop is a browser, and
I know no popular GUI browser that's using openssl for cryptography.
Imagine, for instance if Mozilla said "we're dropping support of
anything except TLS1.2". Now *that* would produce a real dungstorm here.
> 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?
Highly unlikely. Debian stable is called "stable" because they don't
change behavior of binaries and libraries like that *unless* there is a
compelling reason. Like, for instance, a grave zero-day bug that
upstream fixes in the most recent version only and the fix is impossible
to backport to a current stable Debian package.
Exactly this happened to samba last year.
I suppose they could disable "anything but TLS1.2 by default" in
stable's openssl *if* someone manage to show a series of unfixable
security bugs in TLS1.1 (already happened for SSL3.0 and TLS1.0).
> 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?
See above.
> By pinning this library at 1.1.0f-3 on my system, I feel somehow I've
> done the wrong thing. 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.
No, it won't work that way.
First, this LD_PRELOAD library does exactly one thing - it downgrades
default TLS version to TLS1.0. If your users have the trouble connecting
to your mailserver because their clients cannot do TLS1.2 and that's the
only thing your mailserver advertizes - your users still won't be able
to connect after downgrading *their* end to TLS1.0.
Second, I somehow doubt that your users' MUAs are based on openssl.
Third, since then LD_PRELOAD works on Windows?
What you *can* do with this library is to deploy it on your *server* and
LD_PRELOAD cirrus/dovecot/exim/postfix/whatever you have there. It may
even work (I haven't tried it though).
> Or maybe I
> should follow Stretch (and it's security fixes) for only this package
> instead of pinning it to this version.
This approach will buy you some time, but …<drumroll>… sooner or later
Debian maintainer decides to migrate to openssl 1.2. Or introduce an
incompatible ABI change in openssl 1.1 - OpenSSL upstream in (in)famous
for that.
Then they will rebuild the whole main and contrib archive and your
pinning will cease to do anything meaningful.
> 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.
>
> In doing some reading about TLS and it's problems, there are problems
> with TLSv1 and I understand those were fixed in Debian's libssl1.
> TlSv1.1 had some problems but were more minor and the move to 1.2
> seemed more about enhancing security versus some removing design
> flaws. Clearly the vendors like Microsoft and Apple did not think it
> critical to move away from TLSv1 and TLS1.1 and probably patched it
> like Debian. Hence they consider their versions of TLSv1 and TLSv1.1
> safe enough.
>
> While I am totally sympathetic to getting the world onto TLSv1.2 and
> greater, this seems like a support disaster waiting to happen.
>
> What is the right way for an admin to handle this problem on Debian Testing?
The only thing they told me back in the day was 'if you have to do a
server - you use Debian stable'. This openssl incident and may others
only prove this principle right.
Reco
Reply to: