Better client certificate support for TLS 1.3

[tniessen]

What is the problem this feature will solve?

tls.createServer() accepts a requestCert option that can be used to request client certificates. However, this option does not appear to be configurable through a SecureContext, so it cannot be changed dynamically (e.g., based on the hostname in SNICallback).

In TLS 1.2, tlsSocket.renegotiate() can be used to dynamically request a client certificate after the initial handshake.

TLS 1.3, on the other hand, does not allow this renegotiation. With the current API, I don't see a way of dynamically requesting client certificates in TLS 1.3.

What is the feature you are proposing to solve the problem?

I believe there are two viable approaches to dynamic client certificate requests, both of which should ideally be supported.

• The server should be able to dynamically decide whether to request a client certificate based on the ClientHello message, similar to how the SNICallback allows dynamic selection of the SecureContext.
• Post-handshake authentication can be enabled by the client and allows the server to request a client certificate after the handshake has been completed. This might need APIs on both sides.

I certainly don't want to add much complexity to the TLS module, nor do I want to bloat it with additional functions that are specific to this TLS version. I also don't know how this would tie in with QUIC.

What alternatives have you considered?

It is possible to manually parse the ClientHello message to dynamically decide which TLS server instance to pass the connection to. This is somewhat difficult to implement though.

[bnoordhuis]

Post-handshake authentication: https://www.rfc-editor.org/rfc/rfc8446#section-4.6.2

But note that it is explicitly forbidden for HTTP/2: https://www.rfc-editor.org/rfc/rfc8740#section-3

Also in TLSv1.2, by the way; renegotiation is only allowed up to the connection preface: https://www.rfc-editor.org/rfc/rfc7540#section-9.2.1

I don't know about QUIC but after some quick googling I'm inclined to believe it follows HTTP/2. Maybe @jasnell knows.

[tniessen]

@bnoordhuis Thank you :) Is my understanding correct that dynamic decisions after the ClientHello (based on SNI and/or ALPN) would still be possible in HTTP/2 and QUIC?

[bnoordhuis]

ALPN and SNI still work the same, yes, but I expect SNI to be subsumed by ECH in a couple of years.

[tniessen]

@bnoordhuis Do you have an idea for a minimal API extension that would allow dynamically deciding whether to request a client certificate based on SNI/ALPN/future ECH?

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[github-actions]

There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.

For more information on how the project manages feature requests, please consult the feature request management document.