Kestrel RemoteCertificateValidationCallback client IP.

[mateli]

Is there an existing issue for this?

• I have searched the existing issues

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

When writing a QUIC server the RemoteCertificateValidationCallback recieves a QuicConnection as the Sender object. From this a lot of data can be extracted such as the IP of the remote host. Kestrel has a similar RemoteCertificateValidationCallback but without the "object sender" parameter which means that there is no way at this point of knowing the IP of the client which is useful when implementing strict IP based access control.

Describe the solution you'd like

Add a way to know the remote IP address and other useful information about the connection in the RemoteCertificateValidationCallback handler.

Additional context

No response

[amcasey]

I think I'm probably missing something obvious, but why would RemoteCertificateValidationCallback be the place you validate the client's IP?

[amcasey]

Is this of any use to you? https://learn.microsoft.com/aspnet/core/security/ip-safelist

[mateli]

@amcasey How else would you reject a certificate based on it's origin IP address? The point of doing that rather than at a later stage besides decreased processing is that an intruder would then spend a significant amount of time on trying to figure out why the certificate is rejected. Something that's easy for authorized staff that has access to server logs.

And as for the safelist it can't be used to validate that a certificate is used from the specific ip adress that its associated with. But more importantly the safelist presents a 403 error which tells an intruder exactly what needs to get done to access the server. Which is getting access to a machine that's on the safelist. It doesn't allow for rejecting the certificate which is the more secure way to handle this.

Of course one can implement another middleware that rejects the connection to whatever rule needed but it's as far as I know impossible to reject the certificate at this stage as it's after the completion of the tls handshake.

Although another solution for this issue is for Kestrel to accept an external QUIC handler. This would solve other issues such as the ability to use QUIC for other protocols than h3. In such a case certificate verification would not be handled by kestrel at all.

[amcasey]

@mateli I was confused - my question was based on the incorrect assumption that connection middleware ran before certificate validation.

[mateli]

@amcasey Well when I asked ChatGPT it made the same assumption which is why I know that it doesn't. :)