Posts: 522 from 2003/2/24
From: finland, the l...
I'm due to swap to a new ISP plus.net
in the next week or so, but I find that Wayfarer with Safari, or any other User Agent, cannot connect, as there is an SSL error (35: SSL connect error) generated with this site that it doesn't seem to get past.
While jacek already gave you the beef, here are the technical details in case someone really wants to know what happened there. The gist of it is that OpenSSL Team decided to do the following change for OpenSSL 3:Quote:
The security strength of SHA1 and MD5 based signatures in TLS has been reduced.
This results in SSL 3, TLS 1.0, TLS 1.1 and DTLS 1.0 no longer working at the default security level of 1 and instead requires security level 0. The security level can be changed either using the cipher string with @SECLEVEL, or calling SSL_CTX_set_security_level(3). This also means that where the signature algorithms extension is missing from a ClientHello then the handshake will fail in TLS 1.2 at security level 1. This is because, although this extension is optional, failing to provide one means that OpenSSL will fallback to a default set of signature algorithms. This default set requires the availability of SHA1.
This change in practical terms appears as openssl commit aba03ae571ea677fc484daef00a21ca8f7e82708
This reduction of security means that any application using openssl 3 with default security level 1 will no longer offer SHA1 algorithms when connecting to a remote server. Normally this is not a problem. However, in case of www.plus.net this is fatal as the server ONLY
supports SHA1 signature algorithm. Thus the server decides to not allow the client to connect at all.
So this is a combination of poor configuration of the www.plus.net server with the unfortunately decision from OpenSSL team to enforce such security decision.
To fix this we could have done several things:
- downgrade to openssl 1.1.1
- change Wayfarer (and Iris) application to set SECLEVEL to 0.
- force openssl 3 build to default to SECLEVEL of 0.
None of these options were very attractive. OpenSSL 3 is the way to forward and going back would have been silly. Dropping the security level to 0 would have been a bad idea as well because doing that reduces the security on other fronts as well, not only the SHA1 decision.
In the end the specific code block reducing the security was just disabled. This surgically fixes the issue without need to touch SECLEVEL itself.