Re: [9front] [PATCH] libsec, pushtls, tlssrv: add support for Server Name Indication (SNI) extension

[igor@9lab.org]

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