Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #185172 > unrolled thread

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

Back to article view | Back to linux.debian.user

Contents

  testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) songbird <songbird@anthive.com> - 2017-08-14 14:10 +0200
    Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) Stephan Seitz <stse+debian@fsing.rootsland.net> - 2017-08-14 15:20 +0200
      Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) kjonca@poczta.onet.pl (Kamil Jońca) - 2017-08-14 21:50 +0200
        Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) Sven Hartge <sven@svenhartge.de> - 2017-08-14 22:50 +0200
          Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) kjonca@poczta.onet.pl (Kamil Jońca) - 2017-08-15 09:30 +0200
      Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) songbird <songbird@anthive.com> - 2017-08-15 15:10 +0200
        Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) Michael Grant <mgrant@grant.org> - 2017-09-05 19:50 +0200
          Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) Gene Heskett <gheskett@shentel.net> - 2017-09-05 20:20 +0200
            Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) Michael Grant <mgrant@grant.org> - 2017-09-05 21:40 +0200
              Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) Michael Grant <mgrant@grant.org> - 2017-09-05 23:50 +0200
                Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) Sven Hartge <sven@svenhartge.de> - 2017-09-06 11:10 +0200
              Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) Sven Hartge <sven@svenhartge.de> - 2017-09-05 23:50 +0200
                Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) Michael Grant <mgrant@grant.org> - 2017-09-06 00:10 +0200
                  Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) songbird <songbird@anthive.com> - 2017-09-06 02:50 +0200
                Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) <tomas@tuxteam.de> - 2017-09-06 10:00 +0200
                  Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) Reco <recoverym4n@gmail.com> - 2017-09-06 17:10 +0200
                    Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) <tomas@tuxteam.de> - 2017-09-06 21:00 +0200
                      Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) Reco <recoverym4n@gmail.com> - 2017-09-07 16:30 +0200
                        Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) Michael Grant <mgrant@grant.org> - 2017-09-08 00:00 +0200
                          Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) Reco <recoverym4n@gmail.com> - 2017-09-08 09:10 +0200
                            Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) Sven Hartge <sven@svenhartge.de> - 2017-09-08 09:50 +0200
                            Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) Michael Grant <mgrant@grant.org> - 2017-09-08 11:30 +0200
                              Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) Reco <recoverym4n@gmail.com> - 2017-09-08 18:30 +0200
                          Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) Sven Hartge <sven@svenhartge.de> - 2017-09-08 09:40 +0200
                            Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) Brian <ad44@cityscape.co.uk> - 2017-09-08 20:20 +0200
                              Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) Sven Hartge <sven@svenhartge.de> - 2017-09-08 22:00 +0200
                        Re: testing, upgrade of openssl libssl1.1 ( 1.1.0f-3 => 1.1.0f-4 ) <tomas@tuxteam.de> - 2017-09-08 11:10 +0200

Page 2 of 2 — ← Prev page 1 [2]

#186602

Reco <recoverym4n@gmail.com> wrote:
> On Thu, Sep 07, 2017 at 10:50:00PM +0100, Michael Grant wrote:

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

Exactly.

I have my home and personal systems on Unstable+Experimental, but only
because a) I am adventurous, b) have been doing this for a very long
time an know how to get myself out of any mess and c) I am the only one
using this and if something breaks I don't harm anyone else.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#186605

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

First, using your LD_PRELOAD hack on the Debian server, if a client
connects and DOES support TLSv1.2, will use 1.2 or 1.0?

Second, reading the code, and I'm no expert with the openssl library,
does this cause "outbound" connections to be version 1.0? If I
understand you and your code properly, that's what it's going to do.
I don't know if there's a mechanism in TLS to start with 1.2 and fail
back to a lesser version if the other end doesn't support it.

> 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).

Yes of course!  I had no intention of trying to install this on the
clients!  I have not tried your hack yet either.

> 'if you have to do a
> server - you use Debian stable'.

Why am I using Debian Testing?  I have been using Testing for several
years now and this is the first such issue I've had where it wasn't
clear what to do.  And as stated, this issue will probably find it's
way into Stable too, this is just a preview.

Several years ago I was running Stable but I found that there were
many packages that did not make it into back-ports.  I was constantly
in situations where packages I needed to install simply were not
available in stable and they had dependencies which I could not easily
resolve.  I did not want to start building my own packages.  After
frustration upon frustration, I finally moved to testing and all my
problems like this disappeared.  I have been delighted with the
Testing branch.  It's very very stable and in the odd case where it
isn't, pinning a package for a while has not caused me problems.
However, this situation is different as this package might need to be
pinned for YEARS. And as we've said, it's probably going to affect
Stable as well at some point and then I may be forced to do something
different.

What about publicly forking the libssl1 package (like Sven did
privately) and having a version of this that tracks all the bug fixes
and improvements except the 1.2 requirement?  Once you install it, it
over-rides/replaces the original.  There is probably a right way to do
this.

Ok so I'm not running a university or a large business.  I'm just
doing this for a bunch of professional friends and family, still I
treat it like real infra since we all have livelihoods that depend on
this infra.

[toc] | [prev] | [next] | [standalone]

#186611

	Hi.

On Fri, Sep 08, 2017 at 10:20:22AM +0100, Michael Grant wrote:
> > 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?
> 
> First, using your LD_PRELOAD hack on the Debian server, if a client
> connects and DOES support TLSv1.2, will use 1.2 or 1.0?

Untested. Since I know next to nothing about MTAs - all that's required
of me is to setup a smarthost and that's it - I can not setup a
meaningful test environment. I could try to poke a dovecot though, but
it will take time.

My best understanding of this is if a TLS server does not specify an
exact version of protocol used then "old" openssl just assumes that
TLS1.0, TLS1.1 and TLS1.2 should be used at once. "New" openssl just
provides TLS1.2 *unless* you find a way to specify exact version of TLS
that's to be used (nginx can be told to do so for instance). LD_PRELOAD
hack (please stop calling it mine - I've forsaken authorship of it)
forces it to be TLS1.0 *only*.

Unless you change the code, of course.


> Second, reading the code, and I'm no expert with the openssl library,
> does this cause "outbound" connections to be version 1.0?

That was the original idea. The code was written to scratch a particular
itch, and it was to force plain openssl and ncat (from nmap) to use
TLS1.0.


> If I
> understand you and your code properly, that's what it's going to do.
> I don't know if there's a mechanism in TLS to start with 1.2 and fail
> back to a lesser version if the other end doesn't support it.

That's where an openssl expert is needed. I won't claim to be the one.


> > 'if you have to do a
> > server - you use Debian stable'.
> 
> Why am I using Debian Testing?  I have been using Testing for several
> years now and this is the first such issue I've had where it wasn't
> clear what to do.  And as stated, this issue will probably find it's
> way into Stable too, this is just a preview.

True. But by that time the dust should settle and the suitable
workaround would be found.
The difference between "stable" and "testing" is that the users of the
latter need it now. The users of the former can afford to wait and see
how it plays out.


> Several years ago I was running Stable but I found that there were
> many packages that did not make it into back-ports. I was constantly
> in situations where packages I needed to install simply were not
> available in stable and they had dependencies which I could not easily
> resolve.  I did not want to start building my own packages.  After
> frustration upon frustration, I finally moved to testing and all my
> problems like this disappeared.  I have been delighted with the
> Testing branch.

Interesting. Care to share which packages did you lack for *server*
purposes?


> What about publicly forking the libssl1 package (like Sven did
> privately) and having a version of this that tracks all the bug fixes
> and improvements except the 1.2 requirement?  Once you install it, it
> over-rides/replaces the original.  There is probably a right way to do
> this.

I don't know since I'm way too lazy to fork an openssl singlehandedly.

I trust Debian project as I've installed their OS numerous times. Why
should I trust some guy or gal (whom I don't acquainted with, no offence
meant) to provide me with such security-sensitive package?

Reco

[toc] | [prev] | [next] | [standalone]

#186601

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.

[toc] | [prev] | [next] | [standalone]

#186613

On Fri 08 Sep 2017 at 09:33:59 +0200, Sven Hartge wrote:

> Michael Grant <mgrant@grant.org> wrote:
> 
> > 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.

I didn't quite read it like this. The -devel discussions had a broad
consensus regarding the change in buster but the maintainer has laid
his stall out.

 > My problem is that if we don't do something, TLS 1.0 will be used
 > for an other 10 year, and that's just not acceptable. So I would
 > like to do something so that hopefully by the time Buster releases
 > you can disable TLS 1.0 by default, and that almost no users would
 > need to enable it again.
 >
 > Disabling the protocols is the only way I know how to identify
 > all the problems. And I would like to encourage everybody to
 > contact the other side if things break and get them to upgrade.

There you are. Everyone who is affected by this change can use their
persuasive powers to bring about change. Microsoft, Google etc will
be overwhelmed by the Debian shock troops and fall into line.

And again:

 > I have a patch for that at:
 > https://github.com/openssl/openssl/pull/4128
 >
 > I might upload this soon. The intention is still to ship Buster
 > with TLS 1.0 and 1.1 completly disabled.

Couldn't be clearer. The maintainer does not plan to switch back to
TLS1.0 and TLS1.1 support, even as a configurable option. Fancy
being cannon fodder? ;)

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#186614

Brian <ad44@cityscape.co.uk> wrote:

> And again:

>> I have a patch for that at:
>> https://github.com/openssl/openssl/pull/4128
>>
>> I might upload this soon. The intention is still to ship Buster
>> with TLS 1.0 and 1.1 completly disabled.

> Couldn't be clearer. The maintainer does not plan to switch back to
> TLS1.0 and TLS1.1 support, even as a configurable option. Fancy being
> cannon fodder? ;)

I see a decisision from the CTTE on that matter in the future.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#186604

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Sep 07, 2017 at 05:23:11PM +0300, Reco wrote:
> 	Hi.

[...]

> So I got bored and wrote the thing today. A customary disclaimer
> follows:

Wow. That was quick. Although I'm probably not going to use it:

 - hey, thanks a bunch!
 - I'm sure going to read it and play around with a bit

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlmyXOkACgkQBcgs9XrR2kZbcACdEJt50L0KBimk2ndn467lOk7t
wj8An1c5s3MewdxrwJ1a4g9Atzk4SKFl
=CAni
-----END PGP SIGNATURE-----

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web