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.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16400 invoked from network); 19 Jan 2023 04:49:41 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 19 Jan 2023 04:49:41 -0000 Received: from mimir.eigenstate.org ([206.124.132.107]) by 9front; Wed Jan 18 23:48:22 -0500 2023 Received: from abbatoir (pool-108-27-53-161.nycmny.fios.verizon.net [108.27.53.161]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 962e6dea (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO) for <9front@9front.org>; Wed, 18 Jan 2023 20:48:21 -0800 (PST) Message-ID: To: 9front@9front.org Date: Wed, 18 Jan 2023 23:48:19 -0500 From: ori@eigenstate.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: private NoSQL engine Subject: Re: [9front] [PATCH] libsec: add minimal support for the tls renegotiation extension Reply-To: 9front@9front.org Precedence: bulk Quoth ori@eigenstate.org: > Quoth Anthony Martin : > > OpenSSL 3.0 clients refuse to connect to servers that do not > > support the renegotiation extension (RFC 5746) unless the default > > configuration is changed to allow it. Since we do not support > > renegotiation, we only need to make minor changes to the initial > > handshake to comply with the specification: > > > > 1. For tlsClient, simply add the proper SCSV to the ClientHello > > cipher list (cf. RFC 5746 § 3.3); > > > > 2. For tlsServer, respond with an empty renegotiation extension > > in the ServerHello if we received either the SCSV or an empty > > renegotiation extension in the ClientHello. > > > > Since we close the hand file and never open it after the initial > > handshake, we can rely on tls(3) to send the "no renegotiation" > > alerts if subsequent handshake records are received. > > > > I'll have to find time to go over the changes this weekend in more > details, and actually read the RFC -- but from a quick read, it > looks like the 'ext' that you allocate in tlsServerExtensions gets leaked. > wait, never mind, it looks like msgClear handles that.