Not able to connect to Redis in .NET 5

[vivek-anil]

The code works fine in localhost but does not work when hosted in PCF container.
Does redis still use weak cipher?

[NickCraver]

We're going to need more details here to be able to help. Keep in mind we have no idea what your scenario is, what the configuration is, or what a PCF container is.

[mgravell]

Also: a lot of redis doesn't use a cipher at all. TLS us a recent feature in redis 6 IIRC, or had been an automatic add-on for a lot of cloud providers, but you haven't told us what redis version and/or provider you're trying to connect to.

The most useful things here:

• redis version
• provider, if one
• come kind of code example of what you're trying to do
• exception message in full, in one
• captured connection log (pass a stringwriter to the optional log parameter in connect, then look at it afterwards)

I have no idea what a PCF container is, but initial thoughts:

1. DNS
2. Firewall rules

[NickCraver]

If there's more info happy to re-open, but this appears to be environmental so closing out for now.

[tiramisuflavor]

I faced the same issue as the OP. PCF stands for Pivotal Cloud Foundry. In my case, it was a .NET 5 application running in a linux buildpack inside PCF. From my understanding, since the default SslStream behavior was changed in .NET 5, the existing code from this library stopped working if Redis is using a cipher that is not setup by default.

More specifically, when this library creates the SslStream it takes the default of the current OpenSSL config. In this linux buildpack running on PCF, the default config cannot be changed system-wide. A potential solution could be to allow the user to tell which cipher suites it wants to use. See examples here.

In the following block, we could use AuthenticateAsClientAsync passing the user-provided cipher suites (CipherSuitesPolicy) instead.

StackExchange.Redis/src/StackExchange.Redis/PhysicalConnection.cs

Line 1415 in 9e7b7fc

ssl.AuthenticateAsClient(host, config.SslProtocols, config.CheckCertificateRevocation);

Hope this helps. @NickCraver is this enough to reopen?

[slorello89]

FWIW @mgravell & @NickCraver, I believe (I say believe because still haven't heard back on this from the customer that experienced it) I've seen this in the wild as well, the customer in question reported this error:

StackExchange.Redis.RedisConnectionException: 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. SocketFailure on REDACTED Initializing/NotStarted, last: NONE, origin: ConnectedAsync, outstanding: 0, last-read: 0s ago, last-write: 0s ago, keep-alive: 60s, state: Connecting, mgr: 10 of 10 available, last-heartbeat: never, global: 0s ago, v: 2.0.593.37019

When trying to migrate from .NET Core 3.1 -> .NET 5 (they interact with Redis via the DataProtection/caching libraries hence the older version), I came to a similar conclusion to @felipeogarcia, that the Breaking Change in .NET 5 caused an error in the cipher negotiation. I haven't heard back from them one way or the other, and their environment (this is an on-prem customer) is unknown to me. For our part, we know that the ECDHE ciphers that .NET 5 supports will not work on certain versions of Linux (RHEL7 and Ubuntu 16.04).

What to do about it is a different question. I believe (given the article) the SslStream takes its cue regarding cipher-suite negotiations from the OpenSSL config on the machine it's deployed to, so it's something that you can remediate with a config update. You'd expect something similar for certs as well I'd think (just use the machine's cert-store), but there is a configuration option to override cert selection, so allowing something similar with Cipher Suites could make sense.

FYI I do have a more verbose version of the log above I could sanitize and send you if you think it would be valuable.

[Coder3333]

Anybody come up with a work around for this? We have the exact same issue. Core 3.1 application runs fine on Linux PCF, but we change the target framework to .Net 6, and we start getting this exception. The same .Net 6 application runs fine from Windows.

[tiramisuflavor]

The only way I could make it work so far was to have Redis Enterprise infrastructure upgraded to support the newer ciphers. In my case, I had to provision a new Redis instance running on RHEL 8 instead of RHEL 7. But it works because the infrastructure is using the newer ciphers, not due to this library. It's still missing a feature to customize the ciphers and I haven't found any other proper alternative for RHEL 7 or any distribution that supports older ciphers.

[Coder3333]

Can anyone explain why using sslprotocols for the Redis connection string cannot overcome this issue, since StackExchange.Redis uses this value to configure the SSLStream? If I set sslprotocols=Tls12 and run the app from Windows, it connects, but when I move it to Linux, it fails with the error.

To clarify, I have two Redis instances. One on Azure and the other on-prem. The sslprotocols=Tls12 setting works against the Azure Redis, but not against the on-prem one, so I know that my application is capable of Tls12.