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 80A2E237D3 for ; Thu, 25 Jan 2024 16:15:46 +0100 (CET) Received: from duke.felloff.net ([216.126.196.34]) by 9front; Thu Jan 25 10:14:10 -0500 2024 Message-ID: Date: Thu, 25 Jan 2024 16:14:00 +0100 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: <00616767145C9F32119038A94AE5BBAE@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: encrypted just-in-time-scale locator Subject: Re: [9front] [PATCH] libsec, pushtls, tlssrv: add support for Server Name Indication (SNI) extension Reply-To: 9front@9front.org Precedence: bulk > Yes. The current patch more or less just serves the function to get > the conversation started using a working implementation that aimed at > keeping the amount of differences to a bare minimum. yeah, thats totally reasonable. thank you btw :) > So the proposal is to introduce a (1) new tlsServerX() function using > a (2) lookup interface that provides a certificate given a server > name. The 'database' of lookup results (i.e. the certificates) > is indexed by certificate subjects extracted from certificates that > are passed via multiple (3) '-c arguments' to tlssrv to be matched > against whatever is provided via the SNI extension. i see the following options: 1) new tlsServerX() function with a callback that returns the certificate for a given server-name. 2) new tlsServerY() function that lets you pass multiple certificates. 3) we keep tlsServer() as it is and require the user to get a multi-domain certificate (just has multiple subjects). for cases 1 and 2 we need to think how that would be handled by the server in question (what i said about passing multiple -c arguments). > Ok. I have to admit I am not entirely sure what you mean by 'expose > the effective server name (like putenv() in tlssrv)'. Do you mean > there is an env variable we ought to set before calling say tcp80 or > rc-httpd that provides the effective server name tlssrv parsed via > SNI? yes, exactly. the service should get the effective domain negotiated from the handshake. the whole reason this SNI complication exist is that people ran out of ipv4 addresses and start sharing a single service port with dozens of different domains. pushing all that muxing into the application layer that the ip layer would normally handle. for that muxing to be effective, the service then needs to know what domain/serverName it is. -- cinap