Using SslStream to make an ALPN connection - confusion over parameters to use.

[Petermarcu]

@bobuva commented on Mon Mar 19 2018

I've updated to the .NET Core 2.1 preview in order to make an SSL connection. Our server requires an ALPN negotiation to occur. As I understand it, the preview is the first version of .NET Core to support ALPN.

Here is essentially what I'm doing:

TcpClient tcpClient = new TcpClient();
tcpClient.Connect(ProxyClient.TestUbuntuHost, ProxyClient.TestUbuntuPort);
var stream = tcpClient.GetStream();
SslStream sslStream = new SslStream(stream, false, new RemoteCertificateValidationCallback(ValidateServerCertificate));

X509Certificate2 certificate = new X509Certificate2(@"<a filename provided>);
X509Certificate2Collection certColl = new X509Certificate2Collection(certificate);
sslStream.AuthenticateAsClient(
                ProxyClient.TestUbuntuHost,
                certColl,
                SslProtocols.Tls11 | SslProtocols.Tls12, false);

The ValidateServerCertificate looks like this:

public static bool ValidateServerCertificate(
              object sender,
              X509Certificate certificate,
              X509Chain chain,
              SslPolicyErrors sslPolicyErrors)
{
            if (sslPolicyErrors == SslPolicyErrors.None)
                return true;

            Console.WriteLine("Certificate error: {0}", sslPolicyErrors);

            // Do not allow this client to communicate with unauthenticated servers.
            return false;
}

I get this error: System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure. whether or not I pass that 3rd param to the SslStream constructor.

Can you shed some light on whether I need to do something else to enforce the ALPN negotiation?

Thanks,
Bob

[davidsh]

You need to use this overload of AuthenticateAsClient in order to use ALPN. And you need to set the ALPN in the SslClientAuthenticationOptions.ApplicationProtocols property.

https://github.com/dotnet/corefx/blob/master/src/System.Net.Security/ref/System.Net.Security.cs#L185

public Task AuthenticateAsClientAsync(SslClientAuthenticationOptions sslClientAuthenticationOptions, CancellationToken cancellationToken);

[bobuva]

Thanks David! I'll give it a try.

[bobuva]

@davidsh I tried that as shown below, but still get the remote certificate is invalid error.

            TcpClient tcpClient = new TcpClient();
            Task task = tcpClient.ConnectAsync(ProxyClient.TestUbuntuHost, ProxyClient.TestUbuntuPort);
            await task;

            SslStream sslStream = new SslStream(tcpClient.GetStream(), false, new RemoteCertificateValidationCallback(ValidateServerCertificate));
            
            SslClientAuthenticationOptions authOptions = new SslClientAuthenticationOptions();
            authOptions.ApplicationProtocols = new List<SslApplicationProtocol>() { SslApplicationProtocol.Http11, SslApplicationProtocol.Http2 };
            authOptions.EnabledSslProtocols = SslProtocols.Tls12;
            authOptions.TargetHost = ProxyClient.TestUbuntuHost;

            await sslStream.AuthenticateAsClientAsync(authOptions, new CancellationToken(false));

[karelz]

Did you try to set up authOptions.RemoteCertificateValidationCallback?
https://github.com/dotnet/corefx/blob/master/src/System.Net.Security/ref/System.Net.Security.cs#L113-L124

It's possible we may need to validate the constructor arguments when the new overloads are used ... I vaguely remember we discussed that a bit.

[bobuva]

@karelz yes I did. I set it up to point to a validation function -- see my original post above (copied by Peter to this issue).

[karelz]

@bobuva your original post does not set authOptions.RemoteCertificateValidationCallback. It uses constructor overload. Don't use it. Use plain constructor + AuthenticateAsClientAsync.

[bobuva]

Hi @karelz,

Oh, yes, I used to pass it through the constructor, but I had already changed it to pass it through the authOptions.RemoteCertificateValidationCallback. I still had the same problem.

[bobuva]

I also assume that X509Certificate2 is acceptable (interchangeable with X509Certificate).

[karelz]

There seems to be confusion around what was tried, how, etc. Can you please post final code sample, based on the recommendations above that still fails for you?
Can you check if the callback is invoked at all?

[bobuva]

Ok, I'll package it up for you. Thanks!

[bobuva]

@karelz I think I have the ALPN negotiation working. I'm using GRPC for data communications and it appears now that is where my bottleneck lies. Can you tell me if this sample code for SSL ALPN looks as it should? https://gist.github.com/bobuva/0026b8760a44b9c4e60f4649978f1766

[karelz]

Yep, it looks as what I would expect - if it works, then even better.
What was the problem with your previous attempts? Is there something we should change / document?

[bobuva]

Here is a image of what I'm seeing in Wireshark, starting with the Client Hello. After what appears to be a successful handshake (including ALPN negotiation), my client apparently is sending a RST (reset) and I don't know why. Maybe it's just TCP cleaning up?

[karelz]

What kind of problems is it causing? Does it drop the connection?

[bobuva]

After making the SSL connection, I create a grpc channel and send a message awaiting a response. I get a Grpc.Core.RpcException indicating that the stream was removed (it does bi-directional streams). tcpview shows the connection as having been Established, so I think it remains connected until I close the program. I bubble up the exception to the UI so I can see it immediately.