StackExchange.Redis (original) (raw)

@NickCraver - I've confirmed this fix works for my purposes :) - one thing I will note that may or may not be worth addressing. The way the tls authentication works now, it actually swallows the authentication failures in tls.

When I was initially testing this I was trying to run something like:

var options = new ConfigurationOptions(); options.EndPoints.Add($"{host}:12000"); options.Ssl = true; options.SslClientAuthenticationOptions = delegate(string s) { var opts = new SslClientAuthenticationOptions(); opts.TargetHost = host; opts.EnabledSslProtocols = SslProtocols.Tls12;

opts.CipherSuitesPolicy = new CipherSuitesPolicy(new TlsCipherSuite[]
{
    TlsCipherSuite.TLS_RSA_WITH_AES_128_CBC_SHA256,
    TlsCipherSuite.TLS_RSA_WITH_AES_256_CBC_SHA256
});

opts.RemoteCertificateValidationCallback += (sender, certificate, chain, errors) =>
{
    Console.WriteLine(errors);
    return true;
};
return opts;

};

options.SslProtocols = SslProtocols.Tls12; options.CertificateValidation += (sender, certificate, chain, errors) => true;

This is erroneous because options.CertificateValidation and opts.RemoteCertificateValidationCheck both assign the delegate, but the only error I was getting was:

It was not possible to connect to the redis server(s). There was an authentication failure; check that passwords (or client certificates) are configured correctly.

If you really dig though, you see that you get:

The 'RemoteCertificateValidationCallback' option was already set in the SslStream constructor.

Now if I dropped a text-writer into the constructor of the multiplexer, this of course lights up the issue, and maybe this is a broader discussion, but some of these failures - might it be worth adding them as inner-exceptions to the exceptions the muxer is already throwing?