Bug#1011076: [Pkg-openssl-devel] Bug#1011076: libssl3, mercurial: can't connect to server created with `openssl s_server -tls1`

[Sebastian Andrzej Siewior]

On 2022-05-16 17:15:29 [+0200], Julien Cristau wrote:
> Hi,
Hi,

> The failures happen in parts of the test that spin up and attempt to
> connect to a TLS1.0 or TLS1.1 server.  It used to pass on 1.1.1n and (I
> think) 1.1.1o.

That is something I don't understand.

> Trying to replicate with openssl's cmdline tools, e.g.:
>   openssl s_server -cert tests/sslcerts/pub.pem -key tests/sslcerts/priv.pem 
> -tls1
> 
> and
>   openssl s_client -connect localhost:4433 -tls1
> 
> The server reports:
> 4084745F427F:error:0A76:SSL routines:tls_choose_sigalg:no suitable 
> signature algorithm:../ssl/t1_lib.c:3331:
> 
> Talking with Sebastian on IRC he suggested some extra -cipher /
> -provider command line options which didn't seem to make a difference.

You need to use -cipher "ALL:@SECLEVEL=0" instead of 1.

> I guess I have two questions:
> - is this a bug or an intended change?
> - if it's intended, is there a way to allow these connections again?

As per https://www.openssl.org/docs/man3.0/man7/migration_guide.html:
| The security strength of SHA1 and MD5 based signatures in TLS has been 
reduced.

that is why 0 is required instead of 1 as I suggested earlier. The
paragraph goes on:
| The security level can be changed either using the cipher string with
| @SECLEVEL, or calling SSL_CTX_set_security_level(3).

Hope that helps.

> Thanks,
> Julien

Sebastian

Bug#1011076: libssl3,mercurial: can't connect to server created with `openssl s_server -tls1`

[Julien Cristau]

Package: libssl3,mercurial
Severity: normal
X-Debbugs-Cc: jcris...@debian.org

Hi,

mercurial's test suite no longer passes in sid, with:

> --- /<>/tests/test-https.t
> +++ /<>/tests/test-https.t.err
> @@ -362,9 +362,11 @@
>  Clients talking same TLS versions work
> 
>$ P="$CERTSDIR" hg --config hostsecurity.minimumprotocol=tls1.0 --config 
> hostsecurity.ciphers=DEFAULT id https://localhost:$HGPORT/
> -  5fed3813f7f5
> +  abort: error: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error 
> (_ssl.c:997)
> +  [100]
>$ P="$CERTSDIR" hg --config hostsecurity.minimumprotocol=tls1.1 --config 
> hostsecurity.ciphers=DEFAULT id https://localhost:$HGPORT1/
> -  5fed3813f7f5
> +  abort: error: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error 
> (_ssl.c:997)
> +  [100]
>$ P="$CERTSDIR" hg --config hostsecurity.minimumprotocol=tls1.2 id 
> https://localhost:$HGPORT2/
>5fed3813f7f5
> 
> @@ -399,8 +401,8 @@
>  --insecure will allow TLS 1.0 connections and override configs
> 
>$ hg --config hostsecurity.minimumprotocol=tls1.2 id --insecure 
> https://localhost:$HGPORT1/
> -  warning: connection security to localhost is disabled per current 
> settings; communication is susceptible to eavesdropping and tampering
> -  5fed3813f7f5
> +  abort: error: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error 
> (_ssl.c:997)
> +  [100]
> 
>  The per-host config option overrides the default
> 
> @@ -408,7 +410,8 @@
>> --config hostsecurity.ciphers=DEFAULT \
>> --config hostsecurity.minimumprotocol=tls1.2 \
>> --config hostsecurity.localhost:minimumprotocol=tls1.0
> -  5fed3813f7f5
> +  abort: error: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error 
> (_ssl.c:997)
> +  [100]
> 
>  The per-host config option by itself works
> 
> 
> ERROR: test-https.t output changed

The failures happen in parts of the test that spin up and attempt to
connect to a TLS1.0 or TLS1.1 server.  It used to pass on 1.1.1n and (I
think) 1.1.1o.

Trying to replicate with openssl's cmdline tools, e.g.:
  openssl s_server -cert tests/sslcerts/pub.pem -key tests/sslcerts/priv.pem 
-tls1

and
  openssl s_client -connect localhost:4433 -tls1

The server reports:
4084745F427F:error:0A76:SSL routines:tls_choose_sigalg:no suitable 
signature algorithm:../ssl/t1_lib.c:3331:

Talking with Sebastian on IRC he suggested some extra -cipher /
-provider command line options which didn't seem to make a difference.

I guess I have two questions:
- is this a bug or an intended change?
- if it's intended, is there a way to allow these connections again?

Thanks,
Julien