On Tue, 2022-03-22 at 21:01 +0100, Kurt Roeckx wrote:
> 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.

Thanks.

Is the note below accurate? I'm not entirely happy with the title, but
it's the best I could come up with currently.

"
OpenSSL signature algorithm check tightening
=============================================

The OpenSSL update included in this point release includes a change to
ensure that the requested signature algorithm is supported by the
active security level.

Although this will not affect most use-cases, it could lead to error
messages being generated if a non-supported algorithm is requested -
for example, use of SHA1 with the default security level of 2. In such
cases, the security level will need to be explicitly lowered when
invoking OpenSSL, using an option such as

    -cipher "ALL:@SECLEVEL=1"
"

Regards,

Adam

Reply via email to