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 E7E4D22092
	for <ml@inbox.vuxu.org>; Fri, 26 Jan 2024 08:23:58 +0100 (CET)
Received: from mail.9lab.org ([168.119.8.41]) by 9front; Fri Jan 26 02:21:43 -0500 2024
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=9lab.org; s=20210803;
	t=1706253682;
	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=2L3r8xo0XreOdE1bKWSBiamwlyPFgKo+n6TzNUBgShs=;
	b=O2nEwoKl+lBgWQeU0eKOftPZA9ng6DMYbiLmNJbFkq3vZW8DhAhUMDzG97bgE7Qgq/wlIJ
	BismUHU08pLPMNkvivvmv7goHQgviyP+j7WpE7GGuD4z9Rt6Dm6A6VsRfbCtXxqvQKNX97
	zuJ6G0pe8R5YXNH0vWIbuOZIzJNW6Fo=
Received: from rob.9lab.home (<unknown> [162.213.162.246])
	by mail.9lab.org (OpenSMTPD) with ESMTPSA id 133d1987 (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256:NO);
	Fri, 26 Jan 2024 08:21:22 +0100 (CET)
Message-ID: <5808F08EC2EEA3FAA43D228E8805BA23@9lab.org>
To: 9front@9front.org
CC: igor@9lab.org
Date: Fri, 26 Jan 2024 08:21:20 +0100
From: igor@9lab.org
In-Reply-To: <DBC3402753C09477A508BE6DFBE35B09@felloff.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: open-source lifecycle markup 
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 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).

This reiteration was indeed helpful in clearing up the proposal!

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

Thanks for elucidating this point; the penny finally dropped on my
end ☺

Cheers,
Igor