Redis Cache Supports Insecure TLS: Enforce TLS 1.2 on Azure Cache for Redis

Azure Cache for Redis sits in the hot path of a lot of applications. Session state, rate limiters, queues, cached query results, sometimes credentials and tokens. All of that travels between your application and the cache over the network, and the only thing protecting it in transit is TLS. If the cache still accepts TLS 1.0 or 1.1, you are leaving a weaker door open even when your clients prefer something stronger.

The redis_oldtls check looks at the minimumTlsVersion property on your Redis instance and fails if it is set to anything below 1.2.

---

What this check detects

Azure Cache for Redis exposes a setting called Minimum TLS version. It defines the lowest TLS protocol version the server will negotiate with a connecting client. The allowed values are 1.0, 1.1, and 1.2.

This check fails when that property is set to 1.0 or 1.1. When the minimum is below 1.2, a client that only speaks TLS 1.0 or 1.1, or an attacker who can force a downgrade, can still establish a connection that uses an outdated protocol.

---

Why it matters

TLS 1.0 dates back to 1999 and TLS 1.1 to 2006. Both were formally deprecated by the IETF in 2021 (RFC 8996), and the major browser vendors dropped support years earlier. They are kept alive in cloud services only for backward compatibility with legacy clients.

The practical problems with leaving them enabled:

• Known protocol weaknesses. TLS 1.0 is vulnerable to attacks like BEAST and POODLE-style padding oracle issues. Both versions rely on weaker constructs (MD5 and SHA-1 in the PRF, RC4 in some cipher suites) that modern attackers can exploit.
• Downgrade attacks. An attacker positioned on the network path can attempt to force a client and server to negotiate the lowest mutually supported version. If your server still permits 1.0, that becomes the floor an attacker aims for.
• Exposed cache contents. Redis often holds session tokens, API keys, cached PII, and queued jobs. If that traffic can be decrypted, an attacker reads or replays it.
• Compliance failures. PCI DSS has required disabling TLS 1.0 since 2018. HIPAA, SOC 2, and most internal security baselines expect TLS 1.2 as a minimum. An auditor running a scan will catch this quickly.

The risk is not that your own application uses old TLS. It is that the server lets anyone else use it. You do not control every client that can reach the endpoint, especially if the cache has public network access enabled.

---

How to fix it

The fix is to set minimumTlsVersion to 1.2. Pick whichever path matches how you manage your infrastructure.

Azure CLI

az redis update \
  --name my-redis-cache \
  --resource-group my-resource-group \
  --set minimumTlsVersion=1.2

Confirm the change took effect:

az redis show \
  --name my-redis-cache \
  --resource-group my-resource-group \
  --query "minimumTlsVersion" \
  --output tsv

Azure Portal

1. Open the Azure Cache for Redis resource.
2. Under Settings, select Advanced settings.
3. Find Minimum TLS version and set it to 1.2.
4. Click Save.

Terraform

resource "azurerm_redis_cache" "example" {
  name                = "my-redis-cache"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
  capacity            = 1
  family              = "C"
  sku_name            = "Standard"

  minimum_tls_version = "1.2"
}

Bicep / ARM

{
  "type": "Microsoft.Cache/redis",
  "apiVersion": "2023-08-01",
  "name": "my-redis-cache",
  "location": "eastus",
  "properties": {
    "minimumTlsVersion": "1.2",
    "sku": {
      "name": "Standard",
      "family": "C",
      "capacity": 1
    }
  }
}

For .NET clients on older frameworks, you may need to explicitly enable TLS 1.2 in your application before the fix:

System.Net.ServicePointManager.SecurityProtocol =
    System.Net.SecurityProtocolType.Tls12;

---

How to prevent it from happening again

Fixing one cache is easy. Keeping every cache compliant across teams and subscriptions is the real work. Push the requirement into your guardrails so a non-compliant instance can never reach production.

Azure Policy

There is a built-in policy for exactly this. Assign it in audit mode first, then move to Deny once your estate is clean:

az policy assignment create \
  --name "redis-min-tls-12" \
  --display-name "Azure Cache for Redis should use TLS 1.2" \
  --policy "/providers/Microsoft.Authorization/policyDefinitions/8b0323be-cc25-4b61-935d-002c3798c6ea" \
  --scope "/subscriptions/"

If you prefer a custom definition, the policy rule targets the same property:

{
  "if": {
    "allOf": [
      { "field": "type", "equals": "Microsoft.Cache/redis" },
      {
        "anyOf": [
          { "field": "Microsoft.Cache/redis/minimumTlsVersion", "notEquals": "1.2" },
          { "field": "Microsoft.Cache/redis/minimumTlsVersion", "exists": "false" }
        ]
      }
    ]
  },
  "then": { "effect": "deny" }
}

Catch it in CI/CD

Scan IaC before it merges so the misconfiguration never ships. Checkov, for example, has a rule for this (CKV_AZURE_92 covers Redis TLS settings):

checkov -d ./infra --framework terraform

Wire that into a pull request check and fail the build on a finding. Pair it with Lensix continuous scanning to catch drift on resources that were created outside your pipeline or modified by hand.

---

Best practices

• Standardize on TLS 1.2 as the floor across every Azure data service, not just Redis. The same setting exists on Storage accounts, SQL, App Service, and more.
• Disable non-TLS ports entirely. Azure Cache for Redis can expose a plaintext port 6379. Keep enableNonSslPort set to false so all traffic is encrypted, no exceptions.
• Restrict network access. Use Private Link or VNet integration and disable public network access. TLS protects data in transit, but limiting who can reach the endpoint shrinks the attack surface further.
• Track client TLS support before you tighten servers. Inventory your client runtimes and SDK versions so a hardening change does not become an outage.
• Watch for TLS 1.3. Microsoft is moving newer Redis tiers toward TLS 1.3. Keep your clients current so you can adopt it without scrambling later.

Raising the minimum TLS version to 1.2 is one of the cheapest security wins in Azure. It costs nothing, takes one command, and closes a class of network attacks that compliance frameworks have flagged for years. Set it, enforce it with policy, and gate it in CI so it stays that way.