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.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	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 5BD9225C0B
	for <ml@inbox.vuxu.org>; Thu, 25 Jan 2024 13:54:15 +0100 (CET)
Received: from mail.9lab.org ([168.119.8.41]) by 9front; Thu Jan 25 07:51:26 -0500 2024
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=9lab.org; s=20210803;
	t=1706187067;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:  in-reply-to:in-reply-to;
	bh=LxZykFpgPBPG5bh8hwYF8EXTukA7R+z9cJmC3WepT4A=;
	b=Qd/12yFhBiU8WSgYYKx7ZOCBVkvh1+TYo6D44pr3iXhIcpXwJD1wwyxwEXy44WQ1pnFHOA
	wE2qHVi5fxdNvQeBBzOKVHCw/MPVHp1d47nYqS2xf1GHeM3jr+daivoBcCRLlKIdhX4PkZ
	VrsPK1FSxfoZ/D93SvvLd83zOXNIxmk=
Received: from rob.9lab.home (<unknown> [162.213.162.246])
	by mail.9lab.org (OpenSMTPD) with ESMTPSA id b899035a (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256:NO);
	Thu, 25 Jan 2024 13:51:07 +0100 (CET)
Message-ID: <00616767145C9F32119038A94AE5BBAE@9lab.org>
To: 9front@9front.org
CC: igor@9lab.org
Date: Thu, 25 Jan 2024 13:51:05 +0100
From: igor@9lab.org
In-Reply-To: <5F1FF7E81205A7A089331E5C7C69C5F9@felloff.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: cache-aware just-in-time hosting descriptor 
Subject: Re: [9front] [PATCH] libsec, pushtls, tlssrv: add support for Server Name Indication (SNI) extension
Reply-To: 9front@9front.org
Precedence: bulk

Quoth cinap_lenrek@felloff.net:
> 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.

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.

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.

That seems reasonable.  The presence of multiple '-c' arguments would
then be an indicator to call 'tlsServerX()' with the SNI extension; a
single '-c' argument would go down the well trodden 'tlsServer2()'
path.

The only worry would be some level of code duplication but this might
just be a bullshit argument.  Let me try it and present that solution
for further discussion.

> 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).

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?

Cheers,
Igor