[PATCH] Add ssl_client_tls_bind variable

[Rob Casey]

Very interesting. Thanks for these links Maxim.

I would actually favour Steffen's patch over my own for the completeness of
exposing both tls-unique and tls-server-end-point. I would note from the
second link however that this patch was abandoned due to the limited
application of channel binding where more comprehensive web infrastructure
may be deployed.

There is however a separate use for tls-unique (in TLSv1.2 and tls-exporter
in TLSv1.3) independent of channel binding. This is in the form of
demonstrating proof-of-possession within Enrollment over Secure Transport
(EST). This protocol, described in RFC 7030
<https://datatracker.ietf.org/doc/html/rfc7030>, describes a simple, yet
functional, certificate management protocol targeting Public Key
Infrastructure (PKI) clients that need to acquire client certificates and
associated Certification Authority (CA) certificates. This protocol
supports both client-generated public/private key pairs and those generated
by the CA.

In this protocol, the EST server can mandate the inclusion of information
from the current authenticated TLS session (tls-unique) within the Certificate
Signing Request (CSR). This action may be performed to establish a link
between authentication identity and proof-of-possession of the private key
associated with the certification request - See Section 3.5 of RFC 7030 for
details.

While I have an in-progress implementation of an EST module for nginx (
nginx-http-est <https://github.com/61131/nginx-http-est>), this
functionality (proof-of-possession) has not yet been incorporated within my
code. I did however note a request for this same functionality in the Nginx
forum (linked in my original post) which prompted me to create this patch -
>From my perspective, I have no concern whether this patch is merged, but
feel that overhead cost of incorporating these additional SSL variables is
likely to be very small with respect to the benefit for, admittedly, a very
small, user segment with interest in this level of SSL operations.

Rob


On Fri, Dec 15, 2023 at 10:28 PM Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Fri, Dec 15, 2023 at 06:02:45PM +1100, Rob Casey wrote:
>
> > First time caller, long time listener.
> >
> > This patch introduces the variable $ssl_client_tls_bind which provides
> the
> > last Finished message returned by the OpenSSL SSL_get_peer_finished()
> > function. The value returned by this function may be used in TLS channel
> > binding operations as described in RFC 5929
> > <https://datatracker.ietf.org/doc/html/rfc5929> (TLSv1.2) and RFC 9266
> > <https://datatracker.ietf.org/doc/html/rfc9266> (TLSv1.3). The bytes
> > returned by this function are base64-encoded for ease-of-use as per
> > suggestion on Nginx forum thread
> > <https://forum.nginx.org/read.php?10,286777>.
>
> You might be interested in a previous attempt to introduce similar
> variables, here:
>
> https://mailman.nginx.org/pipermail/nginx-devel/2021-May/014082.html
> https://mailman.nginx.org/pipermail/nginx-devel/2021-June/014090.html
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20231216/95b6511b/attachment.htm>