Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return SNI in localid for virtual hosting support #126

Open
vanrein opened this issue May 3, 2019 · 2 comments
Open

Return SNI in localid for virtual hosting support #126

vanrein opened this issue May 3, 2019 · 2 comments

Comments

@vanrein
Copy link
Contributor

vanrein commented May 3, 2019

The Apache module requires SNI to learn who is calling. It sets tlsdata.localid="" and should be sent back the SNI value in tlsdata.localid when tlspool_starttls() returns successfully. This does not happen yet, localid=="" on return.

The callback request flag PIOF_STARTTLS_LOCALID_CHECK should always be used in this use case. Without it, a server would be serving any SNI value (inasfar as it holds a certificate) and that is certainly not a good default -- as it would assume that all certificates in localid.db are meant for that one server. It should however always be assumed that other programs may also be using the same TLS Pool, and so PIOF_STARTTLS_LOCALID_CHECK is a requirement when tlsdata.localid=="" is used.

The library can be adapted to return an error when PIOF_STARTTLS_LOCALID_CHECK is not set when localid=="" upon calling tlspool_starttls(), or it may set the flag.

@vanrein
Copy link
Contributor Author

vanrein commented May 3, 2019

There are two callback commands that present the name and that process a returned file descriptor as to-be plainfd socket:

  • PIOC_PLAINTEXT_CONNECT_V2 is called when a plainfd is needed but not yet available. This is a late callback near the end of the TLS handshake.
  • PIOC_STARTTLS_LOCALID_V2 presents the SNI as a suggested localid value. The routine may accept or reject it; rejection is done by resetting localid="" to which the TLS Pool may respond with another suggested localid value, if it has alternatives. This description should not be treated as SNI-specific but as a general callback mechanism, however it is triggered by localid=="" when an SNI arrives at a TLS server. This is a very early callback in response to a Client Hello that initiates the TLS handshake.

The two are so very similar that they are implemented with the same namedconnect function parameter to tlspool_starttls(). There is a default, used when it is NULL, for PIOC_PLAINTEXT_CONNECT_V2, which assumes that the related void *privdata is in fact a pointer to a socketfd that can be set already, or would otherwise by set with a concealed call to socketpair().

For PIOC_STARTTLS_LOCALID_V2, the use of a default makes no sense. This is due to the reasoning that no server may assume that it is the sole using program for the TLS Pool, and that all certificates in localid.db are for its use. So there should always be a checking program. Absense might even break down the program through an assert() abort, as it violates program assumptions.

Cases where a server would be willing to accept anything are rare, because a certificate is always required. When combined with PIOF_LIDENTRY_ONTHEFLY to really serve any name, this would be possible, but it does require a CA to be setup on the client, reducing this to local solutions only (perhaps for caches). It cannot be assumed as default behaviour.

Having said that, the callback behaves differently for this command. When checking the tlsdata.localid, it is fair to return no socketfd even when signaling success through unchanged localid. This should not discourage the TLS Pool, but rather ask it to call back with PIOC_PLAINTEXT_CONNECT_V2 near the end of the handshake.

@vanrein
Copy link
Contributor Author

vanrein commented May 3, 2019

Also test and assure that only an SNI that matches a tlsdata.localid != "" passes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant