From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 28996 invoked from network); 22 Jan 2023 07:58:44 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 22 Jan 2023 07:58:44 -0000
Received: from sendmail.purelymail.com ([34.202.193.197]) by 9front; Sun Jan 22 02:57:03 -0500 2023
DKIM-Signature: a=rsa-sha256; b=BbO8Lg3OVBXDdpz37TeqioTOU4uDwcUMIfTCl5Z+8wVB7QfKxphn2OFcvRXv6VdYcQqQnST6X52EqCSVg1cswhefg/XNKvSv/rHZvej0jXVHRzJxPo8EGTn7qGihYsn7LdJz+rJK91jyaav7BFYpA6klrha03Ezu1is5E6uWw5XaP/WSAAMCC2/zawCUrUBxdSi7QIPQF/ouua++tQMPp/bGUIyjCcnx6koXDxNHoTw7egbEJfo5RwgmJKGB53RforS9GvOVSVDMS0Mxh2BfDF5df58LveeteYszCDJ0VxjAVs8lxsVtHeEiSIEQmEm9wSfCkrNvS00CEiLEvNwqAw==; s=purelymail1; d=pbrane.org; v=1; bh=Ml5MmyoYlG8edRJx+xC1rC4OJaYfGDmw35THNBErE5E=; h=Received:From:To:Subject;
DKIM-Signature: a=rsa-sha256; b=eXrtkhMvsTT2j9AHC3LQzpzOF3sc1RYAfd74P3mYV2aGQxui6sLnkEsyn7rwyg5w2OrC4VBaCjKOkpbdPaVpQ5+tJ6qmSF8YzRsvoOL8z1zofXEQuB84EG0rGabpiyCKyaLOBU4uWqEHkNarpP9l6bxgvXWUJV0MbcDgbqHumGkR7jtlUQ5k5/IbogbF9eejColk1emIl5zZRIk632SeRYF/JkYeL8peY1j4JXFhjXJw+DCUspfTNBWGnTlBNxFfu0tKkLKHysr4BOZPmVEwukYm8CJb8LgWJqb1DdTgQkaSYWsjdXzYSfPf6jwNs8plBwdhOO9kC3TFO2OfKyjr3Q==; s=purelymail1; d=purelymail.com; v=1; bh=Ml5MmyoYlG8edRJx+xC1rC4OJaYfGDmw35THNBErE5E=; h=Feedback-ID:Received:From:To:Subject;
Feedback-ID: 10987:2443:null:purelymail
X-Pm-Original-To: 9front@9front.org
Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id 1734204739
          for <9front@9front.org>
          (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
          Sun, 22 Jan 2023 07:56:51 +0000 (UTC)
Date: Sat, 21 Jan 2023 23:55:40 -0800
From: Anthony Martin <ality@pbrane.org>
To: 9front@9front.org
Message-ID: <Y8zr/AKMunBzF1YM@alice>
References: <87988F72F1C2D20B16DE8DA47FB8C262@alice>
 <CAFSF3XMJybj82PETOXxRpB7pGKdZTbNQMC_rdzJy=FMrqiaqvA@mail.gmail.com>
 <Y8sCIZbVVtT8msWF@alice>
 <CAFSF3XNY3t9j0UJk=2vtgn+ff4M9pvQ4N1C2Vq6f8_vCfYp6Mg@mail.gmail.com>
 <Y8tgc3fVyC5RRWFB@alice>
 <CAFSF3XNwVSnV6ixXVOdzQthkEZgUM48uN_X8NYAQ6v=d69FUCw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAFSF3XNwVSnV6ixXVOdzQthkEZgUM48uN_X8NYAQ6v=d69FUCw@mail.gmail.com>
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: virtual anonymous replication grid 
Subject: Re: [9front] [PATCH] libsec: add minimal support for the tls
 renegotiation extension
Reply-To: 9front@9front.org
Precedence: bulk

hiro <23hiro@gmail.com> once said:
> No, you're right, I just wonder what kept the openssl people from
> fixing this problem on their side? Since we have unsafe renegotiations
> disabled, we're doing the right and safe thing. so why can't they deal
> with it?

We never supported renegotiation, meaning after the initial
handshake we never send client or server hello messages and
the record layer (tls(3)) ends the connection if it receives
any handshake records after the data file is open.

But that doesn't mean the other side (e.g. OpenSSL) knows we
won't initiate a renegotiation. There is no indication in the
original protocol. Without implementing any of the mechanisms
in RFC 5746, there's no way to know a renegotiation will be
secure if it happens. The connection could be under attack.

RFC 5746 is called the "Renegotiation Indication" extension.

Does that make sense?

Cheers,
  Anthony