TLS handshake failure on Rizon

> On Jun 24, 2021, at 15:48, Kevin Maciel <kmac613@gmx.com> wrote:
> 
> To me it looks like I usually get irc.sxci.net, which fails, but
> sometimes I'll get irc.shells.org, and that one works. I only have
> busybox netcat and gnu netcat to work with right now. I was just trying
> to compile OpenBSD's, but looking at Debian's package seems like they're
> applying a lot of patches to get it to work, including one to disable
> TLS (I'm assuming because Debian doesn't use LibreSSL?). I tried
> building it without that patch but a few of the other patches failed,
> and I didn't feel like looking into at the moment.

You can get OpenBSD’s nc(1) by building LibreSSL with --enable-nc btw

On Thu, Jun 24, 2021 at 03:55:47PM -0400, june wrote:
>> On Jun 24, 2021, at 15:48, Kevin Maciel <kmac613@gmx.com> wrote:
>>
>> To me it looks like I usually get irc.sxci.net, which fails, but
>> sometimes I'll get irc.shells.org, and that one works. I only have
>> busybox netcat and gnu netcat to work with right now. I was just trying
>> to compile OpenBSD's, but looking at Debian's package seems like they're
>> applying a lot of patches to get it to work, including one to disable
>> TLS (I'm assuming because Debian doesn't use LibreSSL?). I tried
>> building it without that patch but a few of the other patches failed,
>> and I didn't feel like looking into at the moment.
>
>You can get OpenBSD’s nc(1) by building LibreSSL with --enable-nc btw

Oh great, that was easy, thanks for letting me know! Looks like it gives
me the same results

nc -vcz -Tprotocols=tlsv1.2 irc.rizon.net 6697
Connection to irc.rizon.net (199.233.228.142) 6697 port [tcp/ircs-u]
succeeded!
TLS handshake negotiated TLSv1.2/DHE-RSA-AES256-GCM-SHA384 with host
irc.rizon.net
Peer name: irc.rizon.net
Subject: /CN=irc.rizon.net
Issuer: /C=US/O=Let's Encrypt/CN=R3
Valid From: Wed Jun 23 16:01:54 2021
Valid Until: Tue Sep 21 16:01:53 2021
Cert Hash:
SHA256:16077864f788e58ad143604fe9ac55093a587da87b18f0bb996a6eff6b11d82b
OCSP URL: http://r3.o.lencr.org

nc -cz irc.rizon.net 6697
Connection to irc.rizon.net (199.233.228.142) 6697 port [tcp/ircs-u]
succeeded!
nc: tls handshake failed (handshake failed: error:1404B410:SSL
routines:ST_CONNECT:sslv3 alert handshake failure)

nc -cz -Tprotocols=tlsv1.3 irc.rizon.net 6697
Connection to irc.rizon.net (199.233.228.142) 6697 port [tcp/ircs-u]
succeeded!
nc: tls handshake failed (handshake failed: error:1404B410:SSL
routines:ST_CONNECT:sslv3 alert handshake failure)

nc -cz -Tprotocols=tlsv1.3 -Tciphers=all irc.rizon.net 6697
Connection to irc.rizon.net (199.233.228.142) 6697 port [tcp/ircs-u]
succeeded!
nc: tls handshake failed (handshake failed: error:1404B410:SSL
routines:ST_CONNECT:sslv3 alert handshake failure)

Kevin Maciel <kmac613@gmx.com> wrote:
> Maybe it would be better if someone more knowledgeable than myself
> reported it to bugs@openbsd.org, but I would be glad to do it if you
> have any suggestions of what I should include in the report. I also have
> no problems connecting to other networks using catgirl. I can ask the
> people in #services about their TLSv1.3 implementation. Let me know if I
> should ask them anything more specific.

You could ask the OpenBSD developers why libtls does not allow ECDHE
with P-521 by default and if they'd be open to changing that. It
looks like this restriction was introduced in [0] which does not
mention P-521 at all, so perhaps it is unintentional.

You could also ask the people managing Rizon why they insist on
P-521, instead of supporting those other curves as well.

Note that this is not really related to TLS 1.2 vs TLS 1.3. In both
cases the ECDHE key exchange method (which should be preferred) is
not getting selected because both sides can't agree on a curve to
use. When you force TLS 1.2 in nc, you'll see that the cipher suite
that gets negotiated is DHE-RSA-AES256-GCM-SHA384 (non-EC DH).

[0] https://github.com/openbsd/src/commit/4896de1e4badc3cc28e3046a4145c94570c197d2

> To Michael Forney,
> Any pointers on how to add this in to catgirl so I can test it? My
> programming knowledge is very rudimentary and I don't really know C, but
> it seems like irc.c is where all the similar stuff is going on, so I
> guess it should go in there somewhere.
> 
> Thanks!

Untested, but the following should work (on top of catgirl 1.8):

diff --git a/irc.c b/irc.c
index c98193a..024add1 100644
--- a/irc.c
+++ b/irc.c
@@ -57,6 +57,15 @@ void ircConfig(
 		);
 	}
 
+	// Enable P-521 since libtls disables it by default.
+	error = tls_config_set_ecdhecurves(config, "X25519,P-256,P-384,P-521");
+	if (error) {
+		errx(
+			EX_SOFTWARE, "tls_config_set_ecdhecurves: %s",
+			tls_config_error(config)
+		);
+	}
+
 	if (insecure) {
 		tls_config_insecure_noverifycert(config);
 		tls_config_insecure_noverifyname(config);

On Thu, Jun 24, 2021 at 07:47:05PM -0700, Michael Forney wrote:
>You could ask the OpenBSD developers why libtls does not allow ECDHE
>with P-521 by default and if they'd be open to changing that. It
>looks like this restriction was introduced in [0] which does not
>mention P-521 at all, so perhaps it is unintentional.

Fantastic, thanks for the tips, and especially for finding the commit!
Much appreciated.

>You could also ask the people managing Rizon why they insist on
>P-521, instead of supporting those other curves as well.

Well, I tried asking in #services and this is the response I got:
>it's the installed/configured tls support on each server .. that's
>about all I'll say ..

Classic Rizon #services. Eventually I got him to say that he would
"alert the admins", so we'll see what happens.

>Untested, but the following should work (on top of catgirl 1.8):

Your patch works! I tried connecting and reconnecting to Rizon. First
try successfully connected to irc.sxci.net, and second to
solenoid.rizon.net. You were right on the money.

Many thanks!

On Fri, Jun 25, 2021 at 12:55:47AM -0400, trunc88 wrote:
>On Thu, Jun 24, 2021 at 07:47:05PM -0700, Michael Forney wrote:
>>You could ask the OpenBSD developers why libtls does not allow ECDHE
>>with P-521 by default and if they'd be open to changing that. It
>>looks like this restriction was introduced in [0] which does not
>>mention P-521 at all, so perhaps it is unintentional.
>
>Fantastic, thanks for the tips, and especially for finding the commit!
>Much appreciated.

Little update here. I emailed bugs@openbsd.org about this the other day,
and they said P-521 not being among the defaults was intentional:

>This is deliberate. The main reason is that P-521 is very expensive.
>This means that an attacker needs to feed you fewer key shares to keep a
>single server core busy than with the other curves, so it increases the
>risk of a DoS.

They also mentioned that there is no such security risk for the client,
and that P-521 can be enabled within catgirl with a couple lines of code
similar to the patch Michael Forney provided (they even guessed that
catgirl was the client!). Now that we have this information, is there a
possibility that this patch could be officially incorporated into
catgirl? For the meantime, and in case they decide not to enable P-521
by default.

>There is no risk client side. We could consider matching what libssl
>does and allow P-521 for clients. This will need some plumbing as the
>config setting is currently client/server agnostic.

>In the interim, it should be easy enough for you to extend the config in
>the irc client to allow P-521 like so:

>if (tls_config_set_ecdhecurves(config, "X25519,P-256,P-384,P-512")) == -1)
>errx(1, "tls_config_set_ecdhe_curves: %s", tls_config_erorr(config));

>If your client is catgirl, that would need to be done in irc.c. More
>precisely, in ircConfig() after tls_config_new() and at the latest
>before the call to tls_configure(client, config).

Thank you

> On Jul 2, 2021, at 17:11, trunc88 <kmac613@gmx.com> wrote:
> 
> They also mentioned that there is no such security risk for the client,
> and that P-521 can be enabled within catgirl with a couple lines of code
> similar to the patch Michael Forney provided (they even guessed that
> catgirl was the client!). Now that we have this information, is there a
> possibility that this patch could be officially incorporated into
> catgirl? For the meantime, and in case they decide not to enable P-521
> by default.
> 
>> In the interim, it should be easy enough for you to extend the config in
>> the irc client to allow P-521 like so:
> 
>> if (tls_config_set_ecdhecurves(config, "X25519,P-256,P-384,P-512")) == -1)
>> errx(1, "tls_config_set_ecdhe_curves: %s", tls_config_erorr(config));

Adding this hardcoded list globally makes me nervous. If some new
curve is added (not sure if that’s something that can happen), then
catgirl won’t use it, and if another one of those curves is determined
to be undesirable in some way, catgirl will continue to use it.

Also seems odd that a server would be configured to use only one
curve, which is the one that is bad for servers to use...

On Tue, Jul 06, 2021 at 01:12:14PM -0400, june wrote:
>Adding this hardcoded list globally makes me nervous. If some new
>curve is added (not sure if that’s something that can happen), then
>catgirl won’t use it, and if another one of those curves is determined
>to be undesirable in some way, catgirl will continue to use it.

Ah that's true, I hadn't thought of that. I wonder how irssi gets
around this problem. I think I'll try to find out.

>Also seems odd that a server would be configured to use only one
>curve, which is the one that is bad for servers to use...

It is very odd, not sure what their deal is with that. I'm going to try
posting in their forums about it