<div dir="ltr">Very interesting. Thanks for these links Maxim.<div><br></div><div>I would actually favour Steffen's patch over my own for the completeness of exposing both tls-unique and <span style="color:rgb(0,0,0)">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.</span></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">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 <a href="https://datatracker.ietf.org/doc/html/rfc7030">RFC 7030</a>, </span>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.</div><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">In this protocol, the EST server can mandate the inclusion of information from the current authenticated TLS session (tls-unique) within the </span><span style="color:rgb(0,0,0)">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.</span></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">While I have an in-progress implementation of an EST module for nginx (<a href="https://github.com/61131/nginx-http-est">nginx-http-est</a>), 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.</span></div><div><span style="color:rgb(0,0,0)"><br></span></div><div>Rob</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 15, 2023 at 10:28 PM Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
On Fri, Dec 15, 2023 at 06:02:45PM +1100, Rob Casey wrote:<br>
<br>
> First time caller, long time listener.<br>
> <br>
> This patch introduces the variable $ssl_client_tls_bind which provides the<br>
> last Finished message returned by the OpenSSL SSL_get_peer_finished()<br>
> function. The value returned by this function may be used in TLS channel<br>
> binding operations as described in RFC 5929<br>
> <<a href="https://datatracker.ietf.org/doc/html/rfc5929" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/html/rfc5929</a>> (TLSv1.2) and RFC 9266<br>
> <<a href="https://datatracker.ietf.org/doc/html/rfc9266" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/html/rfc9266</a>> (TLSv1.3). The bytes<br>
> returned by this function are base64-encoded for ease-of-use as per<br>
> suggestion on Nginx forum thread<br>
> <<a href="https://forum.nginx.org/read.php?10,286777" rel="noreferrer" target="_blank">https://forum.nginx.org/read.php?10,286777</a>>.<br>
<br>
You might be interested in a previous attempt to introduce similar <br>
variables, here:<br>
<br>
<a href="https://mailman.nginx.org/pipermail/nginx-devel/2021-May/014082.html" rel="noreferrer" target="_blank">https://mailman.nginx.org/pipermail/nginx-devel/2021-May/014082.html</a><br>
<a href="https://mailman.nginx.org/pipermail/nginx-devel/2021-June/014090.html" rel="noreferrer" target="_blank">https://mailman.nginx.org/pipermail/nginx-devel/2021-June/014090.html</a><br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org" target="_blank">nginx-devel@nginx.org</a><br>
<a href="https://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" target="_blank">https://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</blockquote></div>