Kestrel support for "path based" TLS renegotiation.

[avparuch]

Is your feature request related to a problem? Please describe.

We have a reverse proxy running on ASP.NET Core, hosted in IIS in-process. During the initial TLS handshake with the client, the server is configured to not ask for a client certificate. However, if the path of the request contains, say "pksecure", IIS triggers a TLS renegotiation and sends a client certificate request.

The following configuration in IIS is how it works:

<location path="pksecure">
    <system.webServer>
      <security>
        <access sslFlags="Ssl, SslNegotiateCert, SslRequireCert"/>
      </security>
    </system.webServer>
</location>

Describe the solution you'd like

We would like Kestrel to have the same capability. This is supported on IIS, both in ASP.NET Core and ASP.NET

Additional context

Add any other context or screenshots about the feature request here.

[Tratcher]

That feature is outdated and will not be added to kestrel.

See the following doc for an alternative.
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/certauth?view=aspnetcore-3.1#optional-client-certificates

[avparuch]

The linked document does not capture the same scenario. The recommendation there is using a separate hostname to mimic optional client certificates. However, the required scenario is the ability to keep the hostname the same and however renegotiate TLS based on path. The renegotiation of TLS is necessary because path is a http construct and the initial TLS handshake is already done by then and we are choosing to change the parameters of TLS based on http constructs.

[Tratcher]

That model isn't going to work anymore, renegotiation is obsolete in modern protocols. It's prohibited by the HTTP/2 spec and has been complete removed from TLS 1.3 (HTTP/3 & QUIC).

Even in HTTP/1.1 it was problematic. It could cause a POST request to deadlock if the request body filled up the TCP window and blocked the renegotiate packets.

The proposal outlined in the linked doc should work with all existing implementations and protocols. I understand that it will require some application redesign, but you'll need to address that in the long term anyways.

[avparuch]

Makes sense. I didn't know it was prohibited by Http/2. This is a good thing, this gives us leverage when talking to partners to put this pattern on the deprecation path.

[Tratcher]

Interestingly TLS 1.3 does define a new way to request the client certificate after the connection has been established, it's called post-handshake authentication. https://tools.ietf.org/html/rfc8446#section-4.6.2

However, this feature is also explicitly prohibited for use with HTTP/2 https://tools.ietf.org/html/rfc8740#section-3. I wonder if HTTP/3 will support it.

Either way, it's still better to use a strategy that works across all versions.