On 2022-03-22 21:47:52 [+0100], Kurt Roeckx wrote:
> On Tue, Mar 22, 2022 at 08:19:01PM +0000, Adam D. Barratt wrote:
> > 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"
> > "
> 
> So reading it again, I think the "when invoking OpenSSL" is confusing.
> Not only the openssl binary is affected, but also all clients and
> server applications making use of the library are. Some applications
> might have a way to set the cipher in their own configuration file,
> others might need to change the defaults in /etc/ssl/openssl.cfg

s/openssl.cfg/openssl.cnf

Kurt correct me if I'm wrong:
This only affects clients which were using TLS1.2 while connecting to
the server and did not send a sig-alg string which let the server
fallback to the default (sha1) which was not checked vs security level.
Would the client have sent sha1 as the sig-cipher then it would fail in
the version d, too.
Would the client need a lower protocol (TLSv1.0) then it would fail, too.
In these two cases the server administrator must have lowered the
security level to 1 (for the announced low sig-alg) and/or allow TLSv1
in order for the client to connect. (The same for the other way around).

I don't know which clients/server don't send sig-alg version. The test
in gnutls explicitly used TLSv1.0. The server check from ssllabs does
not expose server's sig-alg that was used during the handshake. Someone
complained about it:
        https://github.com/ssllabs/ssllabs-scan/issues/465

> 
> Kurt

Sebastian

Reply via email to