From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 8AEE52467A for ; Thu, 25 Jan 2024 13:14:08 +0100 (CET) Received: from duke.felloff.net ([216.126.196.34]) by 9front; Thu Jan 25 07:11:53 -0500 2024 Message-ID: <5F1FF7E81205A7A089331E5C7C69C5F9@felloff.net> Date: Thu, 25 Jan 2024 13:11:37 +0100 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: <229D405D66A4143A9080A3D8FD494A0F@9lab.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: flexible cloud element optimizer Subject: Re: [9front] [PATCH] libsec, pushtls, tlssrv: add support for Server Name Indication (SNI) extension Reply-To: 9front@9front.org Precedence: bulk I think you'd really want to have a new tlsServerX() function for this with a callback to provide the certificate giving the server name. Or alternatively we pass a whole array of certificates in, and the server matches the certificate subject(s). For that programs could maybe accept multiple -c arguments. Hardcoding some path with achmed in there feels very wrong. The whole SNI stuff is a gigant layer-violation in my opinion, and if you use it, you are going to want to expose the effective server name (like putenv() in tlssrv). -- cinap