Subject: openssl 1.1.1b-1 make fetchmail unusable

From: Atsuhito Kohda <[email-masked]>
Date: Fri, 15 Mar 2019 11:42:37 +0900

Package: openssl
Version: 1.1.1b-1
Severity: important

Dear Maintainer,

I updated openssl 1.1.1a-1 to 1.1.1b-1 then fetchmail failed
to get new email.
So I downgraded openssl to 1.1.1a-1 then fetchmail worked
fine again.
I believe there is a bug in openssl 1.1.1b-1 .
I heard that new Debian will be released soon so please
fix the problem before the new release.

A bit precise info:
I upgraded openssl on both server and local macheines.
Then the problem happened so, first, I downgraded openssl
on local machine but the problem remained. So I downgraded
openssl on server machine then fetchmail worked fine.

Thanks for your maintenance.
Best regards,			2019-3-15(Fri)

     				Atsuhito Kohda

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openssl depends on:
ii  libc6      2.28-8
hi  libssl1.1  1.1.1a-1

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20190110

-- no debconf information

---

From: Sebastian Andrzej Siewior <[email-masked]>
Date: Fri, 15 Mar 2019 22:08:13 +0100

> openssl on server machine then fetchmail worked fine.

Do you have somewhere more information what failed on the fetchmail
side? Is the server using by any chance a small DH key?

> Best regards,			2019-3-15(Fri)

Sebastian

---

From: Atsuhito Kohda <[email-masked]>
Date: Sat, 16 Mar 2019 09:06:06 +0900 (JST)

Hi Sebastian,

On Fri, 15 Mar 2019 22:08:13 +0100, Sebastian Andrzej Siewior wrote:

> side? 

Yes, I have error messages of fetchmail but they contains
some Japanese characters. (I added simple translations of
them but not precise translations.)

fetchmail: System error during SSL_connect(): 接続が相手からリセットされました
fetchmail: SSL による接続に失敗しました。
fetchmail: socketエラーが **server name** よりメールを受信している最中に発生しました。
fetchmail: Query status=2 (SOCKET)

line #1:connection is reset by server
line #2:connection by SSL is failed
line #3:during receiving mail from **server name**, a socket error occured

> Is the server using by any chance a small DH key?

Not sure but on the server dovecot (of Debian package) is running.

Thanks for your response.
Best regards,			2019-3-16(Sat)

-- 
 **************************
 Atsuhito Kohda
 atsuhito_k AT tokushima-u.ac.jp

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 16 Mar 2019 14:59:16 +0100

> Not sure but on the server dovecot (of Debian package) is running.

So from what I understand, the problem is really on the dovecot
side. What does dovecot's log show?

Dovecot can configure DH, which seems to default to:
ssl_dh = </usr/share/dovecot/dh.pem

That file should be fine, it's 4096 bit.

Kurt

---

From: Atsuhito Kohda <[email-masked]>
Date: Sun, 17 Mar 2019 20:04:25 +0900 (JST)

Hi Kurt,

> That file should be fine, it's 4096 bit.

Today is sunday and I am at home now.  The machines
of problems are in my office so, perhaps, at tommorow
I will check the settings of dovecot.

Thanks in advance.
Best regards,			2019-3-17(Sun)

---

From: Atsuhito Kohda <[email-masked]>
Date: Mon, 18 Mar 2019 13:55:50 +0900 (JST)

Hi Kurt,

> That file should be fine, it's 4096 bit.

I generated 4096 bit dh_key:
openssl dhparam -out /path/to/dh.pem 4096

then I modified a configuration file of dovecot as follows:
ssl_dh=</path/to/dh.pem

then I restarted dovecot. Now fetch mail works fine
after I upgraded openssl 1.1.1b-1 .

I thinkf if this 4096 bit key is critical for fetchmail
to work fine under openssl 1.1.1b-1, it should be documented
somewhere like NEWS.Denian of openssl etc.

Thanks for your valuable advice.

Best regards,			2019-3-18(Mon)

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 18 Mar 2019 12:06:59 +0100

> then I modified a configuration file of dovecot as follows:

So I assume that somewhere in the past you also did something like
that, and that the old file was still a 1024 bit file? Or did you
just not have an ssl_dh line in your config because the old config
files didn't have it and it wasn't added as part of the upgrade?

> after I upgraded openssl 1.1.1b-1 .

I have no idea which part of dovecot failed, but I think there
might still be some other issue.

Do you have any idea which version of TLS is being negotiated?
Since both use the same version of openssl, it should be able to
do TLS 1.3 and have used X25519 instead of DHE. It could be that
some side of the connection for some reasons blocks TLS 1.3.

The other reason it can fail is that the change between 1.1.1a and
1.1.1b now just caused dovecot to not properly set up TLS. That
you are in fact not using DHE, but that setting up DHE now failed,
causing the connection issue.

Kurt

---

From: Sebastian Andrzej Siewior <[email-masked]>
Date: Mon, 18 Mar 2019 20:34:04 +0100

I suggest to close this bug becuase I don't think it is an openssl bug
nor dovecot. The part about minimal key/cipher requirement is already
documented since 1.1.1-2 in NEWS.Debian.gz. The difference between a and
b release is simply that it now the return code is now set properly in
the error case (which cause dovecot to fail).

> might still be some other issue.

I think that was related to the part that setting a lower DH key did
fail (like it should) and was just fixed in 1.1.1b.
 
> some side of the connection for some reasons blocks TLS 1.3.

what happens if you specify allowed ciphers and you don't add the 1.3
ciphers? Then you would fallback to 1.2 because you don't have the 1.3
ciphers or is this case handled different?

Sebastian

---

From: Atsuhito Kohda <[email-masked]>
Date: Tue, 19 Mar 2019 08:30:29 +0900 (JST)

> files didn't have it and it wasn't added as part of the upgrade?

The old file was /usr/share/dovecot/dh.pem and it was
certainly the file of dovecot package but not a file
I generated.
There are 2 config files 10-ssl.conf, one is under /etc/dovecot/conf.d
and the other under /usr/share/dovecot/conf.d.
In 10-ssl.conf under /etc, there is no ssl_dh line (but there is
#ssl_dh_parameters_length = 1024) and in 10-ssl.conf under /usr,
there is "ssl_dh = </usr/share/dovecot/dh.pem" line.
(Note this dh.pem is not old as
ls -l /usr/share/dovecot/dh.pem 
-rw-r--r-- 1 root root 769  5 Feb. 23:19 /usr/share/dovecot/dh.pem
shows. "5 Feb." is a translation of Japanes text by me.)

I added ssl_dh = </path/to/dh.pem in 10-ssl.conf under /etc 
to fix the problem.  Of course this dh.pem was generated
4096 bit key by me.

> causing the connection issue.

Sorry but I have no idea here.
Thanks for your investigation.
Best regards,			2019-3-19(Tue)

---

From: Atsuhito Kohda <[email-masked]>
Date: Tue, 19 Mar 2019 08:39:37 +0900 (JST)

Hi Sebastian,

> the error case (which cause dovecot to fail).

I can understand the difference of return code might affect
the behavior of dovecot.  But under 1.1.1a dovecot works but
not under 1.1.1b.  It looks there is no error under 1.1.1a
but there is under 1.1.1b.  Are you sure that the problem is
the difference of return code?

Thanks for your advice.

---

From: Sebastian Andrzej Siewior <[email-masked]>
Date: Tue, 19 Mar 2019 08:27:32 +0100

> Hi Sebastian,
Hi, Atsuhito

> the difference of return code?

Yes. The problem was that setting a lower DH key was aborted but instead
of error the success code was returned. The github issue is
	https://github.com/openssl/openssl/issues/7677

and dovecot was not the only package that suddenly failed while it
worked before with the smaller key.

Sebastian

---

From: Atsuhito Kohda <[email-masked]>
Date: Tue, 19 Mar 2019 20:33:24 +0900 (JST)

Hi Sebastian,

> worked before with the smaller key.

I see.  Then my request is documentation (in NEWS.Debian.gz)
should be more elementary.

Thanks for your clarification.
Best regards,			2019-3-19(Tue)

-- 
 ***************************
 Atsuhito Kohda
 atsuhito_k AT tokushima-u.ac.jp