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

[cinap_lenrek@felloff.net]

> 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