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 1 of 2  [1] 2  Next page →

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

  fyi,

  may break your getting of mail process.
(i'm using getmail).

  luckily downgrading the two packages restores
things to working again.

  no time right now for me to find the magic
words to fiddle with to allow this to go
through.


  songbird

[toc] | [next] | [standalone]

#185174

[Multipart message — attachments visible in raw view] — view raw

On Mo, Aug 14, 2017 at 08:02:40 -0400, songbird wrote:
>  may break your getting of mail process.
>(i'm using getmail).
>
>  luckily downgrading the two packages restores
>things to working again.
>
>  no time right now for me to find the magic
>words to fiddle with to allow this to go
>through.

As announced the new version of openssl has disabled TLSv1 and TLSv1.1 
leaving only TLSv1.2.
So if you have an old server without TLSv1.2, you can’t connect anymore.

Shade and sweet water!

	Stephan

-- 
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |

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

#185212

Stephan Seitz <stse+debian@fsing.rootsland.net> writes:

> On Mo, Aug 14, 2017 at 08:02:40 -0400, songbird wrote:
>>  may break your getting of mail process.
>>(i'm using getmail).
>>
>>  luckily downgrading the two packages restores
>>things to working again.
>>
>>  no time right now for me to find the magic
>>words to fiddle with to allow this to go
>>through.
>
> As announced the new version of openssl has disabled TLSv1 and TLSv1.1
> leaving only TLSv1.2.
> So if you have an old server without TLSv1.2, you can’t connect anymore.

It is also break lot of other thigs:
for example: my radius server start to refuse to authenticate win8 and
win8 clients and android tablets.
KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Computer programs expand so as to fill the core available.

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

#185223

Kamil Jońca <kjonca@poczta.onet.pl> wrote:
> Stephan Seitz <stse+debian@fsing.rootsland.net> writes:

>> As announced the new version of openssl has disabled TLSv1 and
>> TLSv1.1 leaving only TLSv1.2.  So if you have an old server without
>> TLSv1.2, you can’t connect anymore.

> It is also break lot of other thigs: for example: my radius server
> start to refuse to authenticate win8 and win8 clients and android
> tablets.

Windows 8, too? It would be nice if you could add this to the thread on
debian-devel concerning this change in OpenSSL.

I already commented that anything Android 5.1 and older is affected by
that change.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

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

#185236

Sven Hartge <sven@svenhartge.de> writes:

> Kamil Jońca <kjonca@poczta.onet.pl> wrote:
>> Stephan Seitz <stse+debian@fsing.rootsland.net> writes:
>
[...]
>
>> It is also break lot of other thigs: for example: my radius server
>> start to refuse to authenticate win8 and win8 clients and android
>> tablets.
>
> Windows 8, too? It would be nice if you could add this to the thread on
Yes, strictly speaking 8.1 (which is even worse)
KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

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

#185254

Stephan Seitz wrote:
> On Mo, Aug 14, 2017 at 08:02:40 -0400, songbird wrote:

>>  may break your getting of mail process.
>>(i'm using getmail).
>>
>>  luckily downgrading the two packages restores
>>things to working again.
>>
>>  no time right now for me to find the magic
>>words to fiddle with to allow this to go
>>through.
>
> As announced the new version of openssl has disabled TLSv1 and TLSv1.1=20
> leaving only TLSv1.2.
> So if you have an old server without TLSv1.2, you can=E2=80=99t connect any=
> more.

  i'm not sure if anyone cares or if filing a bug is
needed here?  (getmail or openssl)

  i will have time later today where i can file a bug.

  also,

  if the real answer is that i need to encourage my
ISP to update things on their end it would be good
for me to be able to tell them what they do need to
upgrade.  i'm assuming this is openssl and libssl1.1
...


  songbird

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

#186470

I upgraded openssl today in my server running testing.  It installed
version 1.1.0f-5.  To my surprise, my mac clients can no longer send
and receive email!

How do I roll back to the previous version of openssl?

"apt-cache showpkg openssl" only shows version 1.1.0f-5.

apt install openssl=1.1.0f-3
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Version '1.1.0f-3' for 'openssl' was not found

I gather I need to add something to my sources.list to get at the
older versions.

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

#186471

On Tuesday 05 September 2017 13:40:00 Michael Grant wrote:

> I upgraded openssl today in my server running testing.  It installed
> version 1.1.0f-5.  To my surprise, my mac clients can no longer send
> and receive email!
>
As that is a security related upgrade, I would next push the Mac people 
to match it, or if possible, configure the Macs to use the more secure 
protocol.

> How do I roll back to the previous version of openssl?
>
> "apt-cache showpkg openssl" only shows version 1.1.0f-5.
>
> apt install openssl=1.1.0f-3
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Version '1.1.0f-3' for 'openssl' was not found
>
> I gather I need to add something to my sources.list to get at the
> older versions.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#186474

On 5 September 2017 at 19:15, Gene Heskett <gheskett@shentel.net> wrote:
> On Tuesday 05 September 2017 13:40:00 Michael Grant wrote:
>
>> I upgraded openssl today in my server running testing.  It installed
>> version 1.1.0f-5.  To my surprise, my mac clients can no longer send
>> and receive email!
>>
> As that is a security related upgrade, I would next push the Mac people
> to match it, or if possible, configure the Macs to use the more secure
> protocol.

Any clues how to configure the Mac to use the more secure protocol?
All the software is up-to-date on the Mac side.  I don't see any
obvious option in any of the mail settings on the Mac side.

This is the error I see in the mail logs for both dovecot and sendmail:

dovecot:
TLS handshaking: SSL_accept() failed: error:1417D102:SSL
routines:tls_process_client_hello:unsupported protocol, session=<...>

sendmail:
STARTTLS=server: 0:error:1417D102:SSL
routines:tls_process_client_hello:unsupported
protocol:../ssl/statem/statem_srvr.c:974:

I realize this isn't a MacOS forum but the error message here is on
the Debian side.  Other mail clients like Windows Mail connect fine.

Is there something I can set on Debian side to force this newer
openssl to accept older 1.x connections?

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

#186477

On 5 September 2017 at 20:29, Michael Grant <mgrant@grant.org> wrote:
> On 5 September 2017 at 19:15, Gene Heskett <gheskett@shentel.net> wrote:
>> On Tuesday 05 September 2017 13:40:00 Michael Grant wrote:
>>
>>> I upgraded openssl today in my server running testing.  It installed
>>> version 1.1.0f-5.  To my surprise, my mac clients can no longer send
>>> and receive email!
>>>
>> As that is a security related upgrade, I would next push the Mac people
>> to match it, or if possible, configure the Macs to use the more secure
>> protocol.
>
> Any clues how to configure the Mac to use the more secure protocol?
> All the software is up-to-date on the Mac side.  I don't see any
> obvious option in any of the mail settings on the Mac side.
>
> This is the error I see in the mail logs for both dovecot and sendmail:
>
> dovecot:
> TLS handshaking: SSL_accept() failed: error:1417D102:SSL
> routines:tls_process_client_hello:unsupported protocol, session=<...>
>
> sendmail:
> STARTTLS=server: 0:error:1417D102:SSL
> routines:tls_process_client_hello:unsupported
> protocol:../ssl/statem/statem_srvr.c:974:
>
> I realize this isn't a MacOS forum but the error message here is on
> the Debian side.  Other mail clients like Windows Mail connect fine.
>
> Is there something I can set on Debian side to force this newer
> openssl to accept older 1.x connections?

I could not find any option I could set in the dovecot.conf or the
sendmail.mc file to make libssl accept tls 1.1.  I managed to revert
back libssl to get back to a working situation until the client's get
updated.

I downloaded libssl1.1_1.1.0f-3_amd64.deb

and did:

dpkg -i libssl1.1_1.1.0f-3_amd64.deb

restarted sendmail and dovecot and everyone can now connect.

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

#186503

Michael Grant <mgrant@grant.org> wrote:

> I downloaded libssl1.1_1.1.0f-3_amd64.deb

> and did:

> dpkg -i libssl1.1_1.1.0f-3_amd64.deb

> restarted sendmail and dovecot and everyone can now connect.

Be sure to either pin or hold the package at that version:
"apt-mark hold libssl" or the next "apt dist-upgrade" will upgrade it
again.

S°

-- 
Sigmentation fault. Core dumped.

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

#186478

Michael Grant <mgrant@grant.org> wrote:

> Is there something I can set on Debian side to force this newer
> openssl to accept older 1.x connections?

No, you can't.

Kurt Roeckx, the DD maintaining OpenSSL, patched it in such a way that a
program needs to call a special function of OpenSSL to override the
default minimum TLS-version of TLS1.2.

Problem is: next to no program implements this as of yet.

The Dovecot developers may introduce the needed change in some of the
coming versions, with sendmail I believe you will be out of luck.

First help: Grab an older OpenSSL version from snapshots.debian.org to
get going again.

My solution (other than complaining on the debian-devel mailinglist) was
to recompile OpenSSL with the patch in question removed.

Of course in doing so I burdened myself with tracking any new release of
the OpenSSL packages and recompile them until this situation has been
resolved in some other way.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

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

#186479

On 5 September 2017 at 22:40, Sven Hartge <sven@svenhartge.de> wrote:
> Michael Grant <mgrant@grant.org> wrote:
>
>> Is there something I can set on Debian side to force this newer
>> openssl to accept older 1.x connections?
>
> No, you can't.
>
> Kurt Roeckx, the DD maintaining OpenSSL, patched it in such a way that a
> program needs to call a special function of OpenSSL to override the
> default minimum TLS-version of TLS1.2.
>
> Problem is: next to no program implements this as of yet.
>
> The Dovecot developers may introduce the needed change in some of the
> coming versions, with sendmail I believe you will be out of luck.

Ugh no!

> First help: Grab an older OpenSSL version from snapshots.debian.org to
> get going again.
>
> My solution (other than complaining on the debian-devel mailinglist) was
> to recompile OpenSSL with the patch in question removed.
>
> Of course in doing so I burdened myself with tracking any new release of
> the OpenSSL packages and recompile them until this situation has been
> resolved in some other way.

Thanks for confirming that I did the best thing I could: reinstall the
previous version of libssl.

I was surprised that this problem affected fairly recent MacOS and
Windows Outlook users.  I was also surprised that not many people had
reported this and as I continued to google around for this, I found
only this chain of posts!  And this has been in the wild now for about
10 days.

I'm sure this fix needs to be in there, forcing it on people without
making sure major mailers are going to accept it is just going to
create more problems.  It probably would have been a good idea to put
a loud warning in the log files about this.  The message given by apt
during the update:

  By default the minimum supported TLS version is 1.2. If you still need to
  talk to applications that only support TLS 1.0 you should configure the
  application to set the minimum supported version.

This is highly misleading that it is easy to do this!

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

#186480

Michael Grant wrote:
...
> I was surprised that this problem affected fairly recent MacOS and
> Windows Outlook users.  I was also surprised that not many people had
> reported this and as I continued to google around for this, I found
> only this chain of posts!  And this has been in the wild now for about
> 10 days.

  you are running Debian Testing/Unstable to see this
change, it won't be pushed to "stable" for a few years
(maybe, we'll see).

  my conversation with the getmail package maintainer
left it at "wontfix".  i have not yet filed a bug with
the openssl maintainer, i'm not sure i will bother.

  in the meantime i'll be stuck at compatible versions
of ssl and the lib and not able to test anything more
recent.


  songbird

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

#186496

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

On Tue, Sep 05, 2017 at 11:40:46PM +0200, Sven Hartge wrote:
> Michael Grant <mgrant@grant.org> wrote:
> 
> > Is there something I can set on Debian side to force this newer
> > openssl to accept older 1.x connections?
> 
> No, you can't.
> 
> Kurt Roeckx, the DD maintaining OpenSSL, patched it in such a way that a
> program needs to call a special function of OpenSSL to override the
> default minimum TLS-version of TLS1.2.
> 
> Problem is: next to no program implements this as of yet.

Isn't there any LD_PRELOAD [1] [2] [3] trick one could play? I mean
interposing something between the executable and the lib to slightly
modify the lib's default behaviour?

Sorry, I haven't the spare cycles ATM to give it a shot (although it
would be tempting...)

[1] http://www.catonmat.net/blog/simple-ld-preload-tutorial/
[2] https://rafalcieslak.wordpress.com/2013/04/02/dynamic-linker-tricks-using-ld_preload-to-cheat-inject-features-and-investigate-programs/
[3] http://www.linuxjournal.com/article/7795

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlmvqlUACgkQBcgs9XrR2kZ+pQCeN8zhZhk77lZTpY1ObE/7x0RC
5V8AniopvriAqZjMwNTS2olo2dnlciS/
=qa6N
-----END PGP SIGNATURE-----

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

#186514

	Hi.

On Wed, Sep 06, 2017 at 09:57:09AM +0200, tomas@tuxteam.de wrote:
> On Tue, Sep 05, 2017 at 11:40:46PM +0200, Sven Hartge wrote:
> > Michael Grant <mgrant@grant.org> wrote:
> > 
> > > Is there something I can set on Debian side to force this newer
> > > openssl to accept older 1.x connections?
> > 
> > No, you can't.
> > 
> > Kurt Roeckx, the DD maintaining OpenSSL, patched it in such a way that a
> > program needs to call a special function of OpenSSL to override the
> > default minimum TLS-version of TLS1.2.
> > 
> > Problem is: next to no program implements this as of yet.
> 
> Isn't there any LD_PRELOAD [1] [2] [3] trick one could play? I mean
> interposing something between the executable and the lib to slightly
> modify the lib's default behaviour?

There'll be once someone writes it. Maybe I'll do it this weekend.

Looking at tls1_2_default.patch from Debian's openssl, the only thing
that needs to be done is to override this change:

@@ -2372,7 +2372,10 @@ SSL_CTX *SSL_CTX_new(const SSL_METHOD *meth)
         goto err;

     ret->method = meth;
-    ret->min_proto_version = 0;
+    if (meth->version == TLS_ANY_VERSION)
+        ret->min_proto_version = TLS1_2_VERSION;
+    else
+        ret->min_proto_version = 0;
     ret->max_proto_version = 0;
     ret->session_cache_mode = SSL_SESS_CACHE_SERVER;
     ret->session_cache_size = SSL_SESSION_CACHE_MAX_SIZE_DEFAULT;

I.e. intercept a call to SSL_CTX_new, set meth->version to, say
TLS1_0_VERSION and call a real SSL_CTX_new.

I'll need it anyway once buster becomes stable as I'm forced to use a
certain cirrus IMAP server which only advertises TLS 1.0.

Reco

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

#186531

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

On Wed, Sep 06, 2017 at 06:01:18PM +0300, Reco wrote:
> 	Hi.
> 
> On Wed, Sep 06, 2017 at 09:57:09AM +0200, tomas@tuxteam.de wrote:

[...]

> > Isn't there any LD_PRELOAD trick one could play? [...]

> There'll be once someone writes it. Maybe I'll do it this weekend.

\o/

;-)

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

iEYEARECAAYFAlmwRTEACgkQBcgs9XrR2kbSFACfQqbeL6Xx3lOYy3z4aSxEYbR7
IykAn3Q+exuCEXL0ska0TalcDixzNYII
=wWaQ
-----END PGP SIGNATURE-----

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

#186564

[Multipart message — attachments visible in raw view] — view raw

	Hi.

On Wed, Sep 06, 2017 at 08:57:53PM +0200, tomas@tuxteam.de wrote:
> > On Wed, Sep 06, 2017 at 09:57:09AM +0200, tomas@tuxteam.de wrote:
> 
> [...]
> 
> > > Isn't there any LD_PRELOAD trick one could play? [...]
> 
> > There'll be once someone writes it. Maybe I'll do it this weekend.
> 
> \o/
> 
> ;-)

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

1) The code is public domain.

2) The code is fugly so I don't claim the authorship. It's bound to
break in next version of openssl anyway.

3) It was tested on Debian GNU/Linux amd64 only, although I don't see
why it should not work elsewhere.

4) Nor the code nor the library are supported by Debian project or the
upstream. I won't support it either.

5) There is no guaranties. If it breaks anything it's your problem, not
mine.


Usage:

apt install gcc-7 libssl-dev
tar xf tls10.tar.gz
# might add -funroll-oops and -fvomit-frame-pointer here
gcc -fPIC -shared -O4 -pipe -g -s -o tls10.so tls10.c
strip tls10.so

LD_PRELOAD=$PWD/tls10.so <ur_ssl_client_here>

Reco

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

#186590

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?

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.

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?

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.  Or maybe I
should follow Stretch (and it's security fixes) for only this package
instead of pinning it to this version.

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?

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

#186599

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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web