On Tue, Mar 22, 2022 at 10:13:25PM +0100, Sebastian Andrzej Siewior wrote: > 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.
The client can send a list of supported sigalgs. Before the change there were 3 options: - the client didn't send anything, the server selected SHA1 - the client only send SHA1, the server selected SHA1 - the client send both SHA1 and SHA256, the server selected SHA256 With this change, it changes to: - the client didn't send anything, the server selects SHA1 for security level <= 1, for security level >= 2 it returns an error. - the client only send SHA1, the server selects SHA1 for security level <= 1, for security level >= 2 it returns an error. - the client send both SHA1 and SHA256, the server selects SHA256. The default client will send both SHA1 and SHA256 for a very long time, but you can change the settings. If the server selects SHA1, before the change the client will accept it, after the change it requires security level <= 1. When talking about SHA1 here, it's really about something RSA+SHA1, as in an RSA signature over a SHA1 hash. > 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). SHA1 can be used for various things in the protocol. Other uses of SHA1 where already properly rejected, it just allowed SHA1 as signature algorithm. Kurt
