SslStream client on Linux incorrectly reports that it is mutually authenticated

[smbz]

Description

When using SslStream.AuthenticateAsClient with a client certificate, IsMutuallyAuthenticated is set to true even if the server did not request a client certificate and the client didn't send one. It should be false, as the client has not authenticated itself to the server (which is the behaviour on Windows).

I've written a short demo program: smbz/IsMutuallyAuthenticatedDemo. Just so it's here, the core is:

string host = "www.microsoft.com";
TcpClient client = new TcpClient(host, 443);

SslStream stream = new SslStream(client.GetStream());
stream.AuthenticateAsClient(host, clientCertificateCollection, SslProtocols.None, true);

After the call to AuthenticateAsClient, stream.IsMutuallyAuthenticated is false on Windows but true on Linux.

Configuration

This affects Linux but not Windows (I'm not sure about Mac).

Platform details:

• .NET Core 3.1.302
• OpenSSL 1.1.1d
• Debian 10

Other information

A Wireshark dump verifies that the server doesn't request a client certificate. I can provide the dump file if needed, but I won't make it public because of MAC addresses.

This is not a security vulnerability because it does not affect the authentication of the client to the server or the server to the client. It only makes the client think that it has authenticated itself to the server.

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[wfurt]

It seems like the code looks for availability of certificate for both sides. As you mentioned, that does not proof that sever actually asked for it. I don't know if OpenSSL has API to track that.

[Serg046]

The flag is false on Windows because of the following line
https://github.com/dotnet/runtime/blob/master/src/libraries/System.Net.Security/src/System/Net/Security/SecureChannel.cs#L592
_context.LocalClientCertificate is null if that clientCertificate is null.
Seems the line is not executed on Linux.

[rzikm]

The _context.LocalClientCertificate happens to be null on Windows because SslStreamPal.StartMutualAuthAsAnonymous is true on Windows, and the client certificate gets nulled at https://github.com/dotnet/runtime/blob/main/src/libraries/System.Net.Security/src/System/Net/Security/SecureChannel.cs#L584 the first time AcquireClientCredentials is called. If server requests the client certificate, then AcquireClientCredentials is called again and full credentials are provided.

On Linux (and OSx as well), the StartMutualAuthAsAnonymous is false, so the LocalClientCertificate property gets always populated if client certificate was provided by the user. However, OpenSSL does not provide an easy way to check if the client certificate was actually requested by the server. The only way we could find out is to rewrite the code to always use cert callbacks (either using SSL_set_cert_cb or SSL_CTX_set_client_cert_cb) and note down if the callback was called during the handshake process.

#63200 already adds usage of SSL_set_cert_cb to support (.NET-side) certificate selection callback, so I suggest to revisit this issue once that PR is merged and try building on those changes.