Hi all,
RFC9266, that has been released not so long ago, has added
tls-exporter as a new channel binding type:
https://www.rfc-editor.org/rfc/rfc5929.html
An advantage over tls-server-end-point, AFAIK, is that this prevents
man-in-the-middle attacks even if the attacker holds the server's
private key, which was the kind of job that tls-unique does for
TLSv1.2, though we've decided at the end to drop it during the PG11
dev cycle because it does things poorly.
This patch provides an implementation, tests and documentation for the
so-said feature. An environment variable called PGCHANNELBINDINGTYPE
is added, as well as new connection parameter called
channel_binding_type. The key point of the implementation is
SSL_export_keying_material(), that is available down to 1.0.1 (oldest
version supported on HEAD), so this should not require a ./configure
check.
Perhaps the part about the new libpq parameter could be refactored as
of its own patch, with the addition of channel_binding_type in the
SCRAM status structures. Note also that tls-exporter is aimed for
TLSv1.3 and newer protocols, but OpenSSL allows the thing to work with
older protocols (testable with ssl_max_protocol_version, for example),
and I don't see a need to prevent this scenario. An extra thing is
that attempting to use tls-exporter with a backend <= 15 and a client
>= 16 causes a failure during the SASL exchange, where the backend
complains about tls-exporter being unsupported.
Jacob Champion should be considered as the primary author of the
patch, even if I have spent some time on this patch before sending it
here. I am adding that to the next commit fest.
Thanks,
--
Michael
