On Tue, Mar 22, 2022 at 07:37:00PM +0000, Adam D. Barratt wrote:
> On Mon, 2022-03-21 at 00:12 +0100, Sebastian Andrzej Siewior wrote:
> > The change in openssl is commit
> > cc7c6eb8135b ("Check that the default signature type is allowed")
> >
> > Before the commit in question it connects as:
> > - Description: (TLS1.0)-(ECDHE-SECP384R1)-(AES-256-CBC)-(SHA1)
> >
> > after that, the server throws:
> > 140490373015360:error:14201044:SSL
> > routines:tls_choose_sigalg:internal error:../ssl/t1_lib.c:2880:
> >
> > and it appears that the security level in openssl forbids SHA1 here.
> > The argument on the s_server side
> > -sigalgs RSA+SHA1:RSA+SHA256:DSA+SHA1:DSA+SHA256
> >
> > doesn't help here but
> > -cipher "ALL:@SECLEVEL=1"
> >
> > does.
> >
>
> If we wanted to add a note to the release announcement in case users
> face similar issue with other software, is "tls_choose:sigalg:internal
> error" a reliable signal of this situation occurring? Should the
> recommended solution be to lower the security level, or might
> specifying -sigalgs work on its own in some scenarios?
So to clarify things. The problem is that SHA1 was allowed as signature
algorithm while the security level should not have allowed it. If the
peer does not support SHA256, the security level needs to be lowered
so that SHA1 is allowed again.
Kurt
