Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Asynchronous SNI API for SslStream #27350

Closed
ryanerdmann opened this issue Sep 10, 2018 · 3 comments
Closed

Asynchronous SNI API for SslStream #27350

ryanerdmann opened this issue Sep 10, 2018 · 3 comments
Labels
api-suggestion Early API idea and discussion, it is NOT ready for implementation area-System.Net.Security
Milestone

Comments

@ryanerdmann
Copy link

Rationale

With the new SNI extension support in SslStream (#24553, dotnet/corefx#28278), web servers can support TLS for multiple hostnames from a single endpoint. However, in a multi-tenant environment, the certificate for a supported hostname may not always be available synchronously. For example, there may be a number of stateless front-end servers that must fetch certificates from a persistent backend, where the total set of supported hostnames and their certificates is either too large to fit in memory or not known a priori. For this reason, the existing ServerCertificateSelectionCallback API is problematic, as it requires servers to block threads while retrieving the certificate.

The server-side SNI API in SslStream should support async realization of the server certificate used for a connection.

Ideally, this would then be supported upstream in servers like Kestrel.

Proposed API Shape

Add AsyncServerCertificateSelectionCallback to SslServerAuthenticationOptions, alongside the existing ServerCertificateSelectionCallback:

namespace System.Net.Security {

public class SslServerAuthenticationOptions
{
    public ServerCertificateSelectionCallback ServerCertificateSelectionCallback { get; set; }
    public AsyncServerCertificateSelectionCallback AsyncServerCertificateSelectionCallback { get; set; }
}

public delegate System.Security.Cryptography.X509Certificates.X509Certificate ServerCertificateSelectionCallback(object sender, string hostName);
public delegate System.Threading.Tasks.ValueTask<System.Security.Cryptography.X509Certificates.X509Certificate> AsyncServerCertificateSelectionCallback(object sender, string hostName);

}

Additional API Information:

  • The async callback should be mutually exclusive with the synchronous variant. This should be enforced similarly to the mutual-exclusion with LocalCertificateSelectionCallback.
  • Since the async version is mutually-exclusive with the sync variant, the return type could just be Task as it is expected to always be truly asynchronous. However, ValueTask enables pooling for performance-sensitive applications.
  • The semantics of the return value should be identical to the synchronous API (e.g. returning null causes the handshake to fail).
@karelz
Copy link
Member

karelz commented Sep 10, 2018

Is blocking threads really a real-life scenario issue? I don't think anyone wants long-running operation as part of each request SNI.
I would expect such data to be cached and occasionally some threads would block ...

@karelz
Copy link
Member

karelz commented Sep 5, 2019

Closing -- It is limited scenario, smaller demand, adds significant complications into the code.

@karelz karelz closed this as completed Sep 5, 2019
@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 5.0 milestone Jan 31, 2020
@ryanerdmann
Copy link
Author

This appears to now be addressed by #37933.

@ghost ghost locked as resolved and limited conversation to collaborators Dec 15, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api-suggestion Early API idea and discussion, it is NOT ready for implementation area-System.Net.Security
Projects
None yet
Development

No branches or pull requests

3 participants