SSL tests failing with "ee key too small" error on Debian SID

Hi all,

On a rather freshly-updated Debian SID server, I am able to see failures
for the SSL TAP tests:
2018-09-17 22:00:27.389 JST [13072] LOG: database system is shut down
2018-09-17 22:00:27.506 JST [13082] FATAL: could not load server
certificate file "server-cn-only.crt": ee key too small
2018-09-17 22:00:27.506 JST [13082] LOG: database system is shut down
2018-09-17 22:00:27.720 JST [13084] FATAL: could not load server
certificate file "server-cn-only.crt": ee key too small

Wouldn't it be better to rework the rules used to generate the different
certificates and reissue them in the tree? It seems to me that this is
just waiting to fail in other platforms as well..

Thanks,
--
Michael

Hello.

At Mon, 17 Sep 2018 22:13:40 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in <20180917131340(dot)GE31460(at)paquier(dot)xyz>
> Hi all,
>
> On a rather freshly-updated Debian SID server, I am able to see failures
> for the SSL TAP tests:
> 2018-09-17 22:00:27.389 JST [13072] LOG: database system is shut down
> 2018-09-17 22:00:27.506 JST [13082] FATAL: could not load server
> certificate file "server-cn-only.crt": ee key too small
> 2018-09-17 22:00:27.506 JST [13082] LOG: database system is shut down
> 2018-09-17 22:00:27.720 JST [13084] FATAL: could not load server
> certificate file "server-cn-only.crt": ee key too small
>
> Wouldn't it be better to rework the rules used to generate the different
> certificates and reissue them in the tree? It seems to me that this is
> just waiting to fail in other platforms as well..

I agree that we could get into the same trouble sooner or later.

Do you mean that cert/key files are generated on-the-fly while
running 'make check'? It sounds reasonable as long as just
replaceing existing files with those with longer (2048bits?) keys
doesn't work for all supported platforms.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

On Tue, Sep 25, 2018 at 12:48:57PM +0900, Kyotaro HORIGUCHI wrote:
> Do you mean that cert/key files are generated on-the-fly while
> running 'make check'? It sounds reasonable as long as just
> replaceing existing files with those with longer (2048bits?) keys
> doesn't work for all supported platforms.

The files are present by default in the tree, but can be regenerated
easily by using the makefile rule "sslfiles". From what I can see, this
is caused by OpenSSL 1.1.1 which Debian SID has visibly upgraded to
recently. That's the version I have on my system. I have not dug much
into the Makefile to see if things could get done right and change the
openssl commands though..
--
Michael

At Tue, 25 Sep 2018 14:26:42 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in <20180925052642(dot)GJ1354(at)paquier(dot)xyz>
> On Tue, Sep 25, 2018 at 12:48:57PM +0900, Kyotaro HORIGUCHI wrote:
> > Do you mean that cert/key files are generated on-the-fly while
> > running 'make check'? It sounds reasonable as long as just
> > replaceing existing files with those with longer (2048bits?) keys
> > doesn't work for all supported platforms.
>
> The files are present by default in the tree, but can be regenerated
> easily by using the makefile rule "sslfiles". From what I can see, this
> is caused by OpenSSL 1.1.1 which Debian SID has visibly upgraded to
> recently. That's the version I have on my system. I have not dug much
> into the Makefile to see if things could get done right and change the
> openssl commands though..

# I have no experience in Debian..

In Debian /etc/ssl/openssl.cnf has been changed to
"CiperString=DEFAULT(at)SECLEVEL=2", which implies that "RSA and DHE
keys need to be at least 2048 bit long" according to the
following page.

https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1

It seems to be Debian's special feature and I suppose
(differently from the previous mail..) it won't happen on other
platforms.

Instead, I managed to cause "ee key too smal" by setting
ssl_ciphers in postgresql.conf as the follows with openssl
1.1.1. With the first attached it happens during
001_ssltests_master.

ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL(at)SECLEVEL=2' # allowed SSL ciphers

The attached second patch just changes key size to 2048 bits and
"ee key too small" are eliminated in 001_ssltests_master, but
instead I got "ca md too weak" error. This is eliminated by using
sha256 instead of sha1 in cas.config. (third attached)

By the way I got (with both 1.0.2k and 1.1.1) a "tlsv1 alert
unknown ca" error from 002_scram.pl. It is fixed for me by the
forth attached, but I'm not sure why we haven't have such a
complain. (It happens only for me?)

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

On Mon, Oct 01, 2018 at 09:18:01PM +0900, Kyotaro HORIGUCHI wrote:
> In Debian /etc/ssl/openssl.cnf has been changed to
> "CiperString=DEFAULT(at)SECLEVEL=2", which implies that "RSA and DHE
> keys need to be at least 2048 bit long" according to the
> following page.
>
> https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1
>
> It seems to be Debian's special feature and I suppose
> (differently from the previous mail..) it won't happen on other
> platforms.

Ah... Thanks for the information. I have missed that bit. Likely
other platforms would not bother much about that.

> The attached second patch just changes key size to 2048 bits and
> "ee key too small" are eliminated in 001_ssltests_master, but
> instead I got "ca md too weak" error. This is eliminated by using
> sha256 instead of sha1 in cas.config. (third attached)

I find your suggestion quite tempting at the end instead of having to
tweak the global system's configuration. That should normally work with
any configuration. This would require regenerating the certs in the
tree. Any thoughts from others?

> By the way I got (with both 1.0.2k and 1.1.1) a "tlsv1 alert
> unknown ca" error from 002_scram.pl. It is fixed for me by the
> forth attached, but I'm not sure why we haven't have such a
> complain. (It happens only for me?)

I am actually seeing that for 001_ssltests, but that's expected as there
are some cases with revoked certs, but not for 002_scram.
--
Michael

On Wed, Oct 3, 2018 at 1:32 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Mon, Oct 01, 2018 at 09:18:01PM +0900, Kyotaro HORIGUCHI wrote:
> > The attached second patch just changes key size to 2048 bits and
> > "ee key too small" are eliminated in 001_ssltests_master, but
> > instead I got "ca md too weak" error. This is eliminated by using
> > sha256 instead of sha1 in cas.config. (third attached)
>
> I find your suggestion quite tempting at the end instead of having to
> tweak the global system's configuration. That should normally work with
> any configuration. This would require regenerating the certs in the
> tree. Any thoughts from others?

I don't really have opinion here, but I wanted to point out that
src/test/ldap/t/001_auth.pl creates new certs on the fly, which is a
bit inconsistent with the SSL test's approach of certs-in-the-tree.
Which is better?

--
Thomas Munro
http://www.enterprisedb.com

On Mon, Nov 26, 2018 at 01:17:24PM +1300, Thomas Munro wrote:
> On Wed, Oct 3, 2018 at 1:32 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>> I find your suggestion quite tempting at the end instead of having to
>> tweak the global system's configuration. That should normally work with
>> any configuration. This would require regenerating the certs in the
>> tree. Any thoughts from others?
>
> I don't really have opinion here, but I wanted to point out that
> src/test/ldap/t/001_auth.pl creates new certs on the fly, which is a
> bit inconsistent with the SSL test's approach of certs-in-the-tree.
> Which is better?

When going up to 2k, it takes longer to generate the keys than to run
the tests, so keeping them in the tree looks like a pretty good gain to
me.
--
Michael

On 26/11/2018 01:35, Michael Paquier wrote:
> When going up to 2k, it takes longer to generate the keys than to run
> the tests, so keeping them in the tree looks like a pretty good gain to
> me.

Another concern might be that repeatedly generating certificates might
drain entropy unnecessarily.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 01/10/2018 14:18, Kyotaro HORIGUCHI wrote:
> The attached second patch just changes key size to 2048 bits and
> "ee key too small" are eliminated in 001_ssltests_master, but
> instead I got "ca md too weak" error. This is eliminated by using
> sha256 instead of sha1 in cas.config. (third attached)

I have applied these configuration changes and created a new set of test
files with them.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 01/10/2018 14:18, Kyotaro HORIGUCHI wrote:
> By the way I got (with both 1.0.2k and 1.1.1) a "tlsv1 alert
> unknown ca" error from 002_scram.pl. It is fixed for me by the
> forth attached, but I'm not sure why we haven't have such a
> complain. (It happens only for me?)

I haven't seen it. Do the tests print that out or does it appear in the
logs? Which test complains?

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 01/10/2018 14:18, Kyotaro HORIGUCHI wrote:
>> The attached second patch just changes key size to 2048 bits and
>> "ee key too small" are eliminated in 001_ssltests_master, but
>> instead I got "ca md too weak" error. This is eliminated by using
>> sha256 instead of sha1 in cas.config. (third attached)

> I have applied these configuration changes and created a new set of test
> files with them.

Buildfarm critters aren't going to be happy unless you back-patch that.

regards, tom lane

On Tue, Nov 27, 2018 at 09:37:17AM -0500, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
>> On 01/10/2018 14:18, Kyotaro HORIGUCHI wrote:
>>> The attached second patch just changes key size to 2048 bits and
>>> "ee key too small" are eliminated in 001_ssltests_master, but
>>> instead I got "ca md too weak" error. This is eliminated by using
>>> sha256 instead of sha1 in cas.config. (third attached)
>
>> I have applied these configuration changes and created a new set of test
>> files with them.
>
> Buildfarm critters aren't going to be happy unless you back-patch that.

Thanks for applying that, Peter.
--
Michael