SslStream RemoteCertificateValidationCallback cannot access protocol/cipher info

[DaveRandom]

The RemoteCertificateValidationCallback is documented as being able to access these values and potentially choose to reject the connection based on them:

The security protocol and cryptographic algorithms are already selected when the userCertificateValidationCallback delegate's method is invoked. You can use the method to determine whether the selected cryptographic algorithms and strengths are sufficient for your application. If not, the method should return false to prevent the SslStream from being created.

Currently this doesn't work, because attempting to access them throws an InvalidOperationException. Ideally, please can this be fixed to work as documented (I only skimmed the code briefly but I don't see any need for the authSuccessCheck here?).

If it's not practical to make it work as advertised for some reason, please can the documentation be fixed - which I will happily do myself if someone points me in the direction of the right place to PR.

N.B. I am trying to implement this with AuthenticateAsServer(), I haven't checked whether it may work as documented for a client-side stream, I will try it out when I can and update the issue if no-one else has checked it first.

Related to https://github.com/dotnet/corefx/issues/24588 / https://github.com/dotnet/corefx/issues/21577 in the sense that if I was able to specify the cipher set that can be used, I wouldn't need to do this as I could simply disable the ciphers I want to disallow with high-level configuration rather than manually checking per-connection.

[davidsh]

Can you please provide a small repro that demonstrates the problem? And what platforms (Windows, Linux, UWP, etc.) does that happen on? Does this just happen on .NET Core 2.0?

[alx9r]

As far as I understand System.Net.Security.RemoteCertificateValidationCallback doesn't provide access to the key exchange, cipher, or data integrity algorithms used during SSL/TLS handshake. I have been able access to the x.509 certificate chain using RemoteCertificateValidationCallback, but that's a different beast from what it sounds like you're looking for.

[davidsh]

As far as I understand System.Net.Security.RemoteCertificateValidationCallback doesn't provide access to the key exchange, cipher, or data integrity algorithms used during SSL/TLS handshake.

So, are you saying that the documentation is wrong since the code itself doesn't match the documentation?

If so, then we have 2 things to consider here. One is to fix the current documentation. And, second, consider an enhancement or API change to address the feature request?

Or, am I missing something? If so, please post a code sample of how you are calling these APIs so we can get more clarity around the repro.

[Drawaes]

The API in theory allows it, so no change there. Its a behaviour change, and it should be possible to get these details at this point (Client Hello + Server Hello is already done and ciphers are already selected before the cert will be sent). I can take a look at a PR if you want (hopefully over the weekend).

[alx9r]

The API in theory allows it, so no change there.

By "the API" do you mean System.Net.Security.RemoteCertificateValidationCallback? The only typed parameters to that callback I see are X509Certificate, X509Chain, and SslPolicyErrors. I traversed the documentation for those object graphs but didn't find an obvious place where the ciphers would appear. That is consistent with the live objects I've examined from the .net full 4.7 WebRequestHandler.ServerCertificateValidationCallback (which is the corresponding type in .net full 4.7).

RemoteCertificateValidationCallback also has a parameter named sender of type object. Is that where the cipher information would appear?

It's not obvious to me where to look for the ciphers using RemoteCertificateValidationCallback. Am I missing something?

[Drawaes]

Sender should be the SslStream, you should be able to cast and get at the properties, and I believe the OP's complaint was that you can't use the properties because they throw at this point in the handshake, which should be avoidable (as all the info is available, but it will depend on the underlying API, I am pretty sure I can get at them for OpenSsl, less sure for SSPI and for OSX/SecureChannel I have no clue)

[DaveRandom]

Trivial example of the sort of thing I was trying to do:

static bool ValidateRemoteCertificate(object Sender, X509Certificate Certificate, X509Chain Chain, SslPolicyErrors PolicyErrors)
{
    var stream = (SslStream)Sender;

    // Explicitly forbid RC4 and MD5 by failing the connection if they are negotiated
    // The linked docs imply that these properties should be accessible at this point but
    // they throw InvalidOperationException when accessed
    return stream.CipherAlgorithm != CipherAlgorithmType.Rc4
        && stream.HashAlgorithm != HashAlgorithmType.Md5;
}

I'd rather this was fixed as it would be a poor-man's work around until dotnet/corefx#24588 is resolved, but if it's not practical then the docs should be updated to reflect the true behaviour.

[DaveRandom]

@Drawaes I just did a quick test using OpenSSL 1.0.2 on RHEL, and certainly with that recipe SSL_get_current_cipher() works as expected during the SSL_CTX_set_cert_verify_callback() (which I assume is what the underlying implementation is based on?)

I know almost nothing about SSPI or SecureChannel though :-/

[davidsh]

complaint was that you can't use the properties because they throw at this point in the handshake, which should be avoidable (as all the info is available, but it will depend on the underlying API

In terms of behavior, this matches .NET Framework as well.

So, changing this would be an enhancement to SslStream.

[Drawaes]

By enhancement... I am unsure of the process here, does that require an API review etc?

[karelz]

We think it should be accessible via casting object to SslStream and accessing the information there.

We should validate that the information is populated even before the connection is established fully. Should be simple.