#924621 openssl 1.1.1b-1 make fetchmail unusable

#924621#5
Date:
2019-03-15 02:42:37 UTC
From:
To:
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

#924621#14
Date:
2019-03-15 21:08:13 UTC
From:
To:
Do you have somewhere more information what failed on the fetchmail
side? Is the server using by any chance a small DH key?

Sebastian

#924621#19
Date:
2019-03-16 00:06:06 UTC
From:
To:
Hi Sebastian,

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

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

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

#924621#24
Date:
2019-03-16 13:59:16 UTC
From:
To:
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

#924621#29
Date:
2019-03-17 11:04:25 UTC
From:
To:
Hi Kurt,

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)

#924621#34
Date:
2019-03-18 04:55:50 UTC
From:
To:
Hi Kurt,
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)

#924621#41
Date:
2019-03-18 11:06:59 UTC
From:
To:
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?

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

#924621#46
Date:
2019-03-18 19:34:04 UTC
From:
To:
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).

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.

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

#924621#51
Date:
2019-03-18 23:30:29 UTC
From:
To:
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.

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

#924621#56
Date:
2019-03-18 23:39:37 UTC
From:
To:
Hi Sebastian,

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.
Best regards,			2019-3-19(Tue)

#924621#61
Date:
2019-03-19 07:27:32 UTC
From:
To:
Hi, Atsuhito

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

#924621#66
Date:
2019-03-19 11:33:24 UTC
From:
To:
Hi Sebastian,

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)