Open vanrein opened 5 years ago
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.
Also test and assure that only an SNI that matches a tlsdata.localid != ""
passes.
The Apache module requires SNI to learn who is calling. It sets
tlsdata.localid=""
and should be sent back the SNI value intlsdata.localid
whentlspool_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 inlocalid.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 soPIOF_STARTTLS_LOCALID_CHECK
is a requirement whentlsdata.localid==""
is used.The library can be adapted to return an error when
PIOF_STARTTLS_LOCALID_CHECK
is not set whenlocalid==""
upon callingtlspool_starttls()
, or it may set the flag.