Regression in AddDataProtection from RC2

[jamesgurung]

I have a working app in ASP.NET Core 6 RC2. It stores data protection keys in Azure Blob Storage, and protects them with Key Vault:

builder.Services.AddDataProtection()
  .PersistKeysToAzureBlobStorage(new Uri(config["DataProtectionBlobUri"]))
  .ProtectKeysWithAzureKeyVault(
    new Uri(config["DataProtectionKey"]),
    new ClientSecretCredential(config["MicrosoftTenantId"], config["MicrosoftClientId"], config["MicrosoftClientSecret"])
  );

In the Dockerfile, if I change these lines:

FROM mcr.microsoft.com/dotnet/aspnet:6.0.0-rc.2 AS base
...
FROM mcr.microsoft.com/dotnet/sdk:6.0.100-rc.2 AS build

to

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
...
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build

Then the app still runs, but all existing cookies and encrypted strings are rejected. Reverting to RC2 makes everything work again.

An example error message is, when trying to decrypt a string: The payload was invalid. For more information go to http://aka.ms/dataprotectionwarning

The package versions are:

• Azure.Extensions.AspNetCore.DataProtection.Blobs v1.2.1
• Azure.Extensions.AspNetCore.DataProtection.Keys v1.1.0
• Azure.Storage.Blobs v12.10.0

[Tratcher]

Can you show how config is created in this example? Or show the whole Program.cs for completness? Is the config instance returning the expected values?

[jamesgurung]

Sorry, I should have said:

var builder = WebApplication.CreateBuilder(args);
var config = builder.Configuration;

I can see that it's returning the right configuration values.

[adityamandaleeka]

This is unexpected since I don't think we did anything in this area after RC2. @HaoK can you please try to repro this?

[jamesgurung]

I have created a minimum repro:

using Microsoft.AspNetCore.DataProtection;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddDataProtection()
  .PersistKeysToAzureBlobStorage(new Uri(builder.Configuration["DataProtectionBlobUri"]));

var app = builder.Build();

app.UseDeveloperExceptionPage();

app.MapGet("/", (IDataProtectionProvider dataProtectionProvider) =>
{
  var protector = dataProtectionProvider.CreateProtector("test");
  return $"Running {System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription}\n\n" +
    $"Encrypted message: {protector.Protect("This is a test.")}";
});

app.MapGet("/{encryptedText}", (string encryptedText, IDataProtectionProvider dataProtectionProvider) =>
{
  var protector = dataProtectionProvider.CreateProtector("test");
  return $"Running {System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription}\n\n" +
    $"Decrypted message: {protector.Unprotect(encryptedText)}";
});

app.Run();

Web endpoints:

• / returns an encrypted string
• /{encryptedText} will attempt to decrypt an encrypted string

I have tested this on Azure, deploying to .NET 6 RC2 and RTM. Each deployment can decrypt its own messages. However, RTM cannot decrypt messages created by RC2 (and vice versa).

Points to note:

• The problem occurs even without ProtectKeysWithAzureKeyVault so this is not included.
• If I modify the keys.xml file, the error now says CryptographicException: The key {xxx} was not found in the key ring. This suggests that it is correctly reading the key file from Azure Blob Storage. It's just that once it has the key, it's not able to use it to decrypt payloads created with the other .NET version.
• By stepping through the source, it looks like the error is coming from the method ManagedAuthenticatedEncryptor.Decrypt, in "Step 4: Validate the MAC provided as part of the payload."

[HaoK]

Hey @jamesgurung thanks for the detailed repro and I'll start investigating to see what's going on. Have you tried .PersistKeysToFileSystem and used the same key directory in your apps as well? It'd be helpful to remove Azure from the potential causes

[HaoK]

So I can repro this without azure, there definitely are two different payloads generated rc2 vs rtm:

rc2: CfDJ8GlGR3YnSRpCpl391nz7WgU99vpdLMj5Wbfb0ZTWJV1GUIuh7mOyqy9BpgF5YXSFVe4cd8WVarOe4Kn3ZNd4GgnHDJw4rU_USMuveJ_0kdGEb32HQi6SY90W5toj2p8s6Q
rtm: CfDJ8GlGR3YnSRpCpl391nz7WgVYb4CMMop4KqNvRC-pVj-38nBAuxPRxRg1Sd4-PEkf6yXxxMrhoq07wYKzqWtTDNZ3Lxvw3MsKtJyhKl904ktOlHsBsWRTSWxmcXDSSV4dtg

[HaoK]

Okay I think the behavior is expected due to some changes in rtm on how the content root is calcluated, dataprotection uses that to compute the application name: https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview?view=aspnetcore-6.0#setapplicationname

So if you need rc2/rtm to be compatible you will need to specify the .SetApplicationName("shared app name")

This looks to be a side effect of 366a618#diff-ba481cde89becdcb3c4495e617a4071a9ee9a3fba3746ab63a452c86fd945c15

@jamesgurung can you confirm that setting fixes things for you as well?

[brockallen]

And so any old DP keys won't work unless the v6 version sets the app name to the old content root calculated name? IOW, is this a breaking change for a live update (e.g. data protected auth cookies) from pre-v6 to v6?

[HaoK]

It'd only be affecting anything using the new DefaultBuilder/minimal API, so it wouldn't affect any pre v6 apps. But yes this might be an unexpected sideeffect of switching to the minimal apis for an existing app.

[brockallen]

Ah, so it's only doing this different content root calculation with the new minimal API? Got it. ty!

[jamesgurung]

@HaoK Thank you so much for looking into this.

What string should I use with SetApplicationName to keep backwards-compatibility with .NET 6 RC2? I already have an RC2 app running in production (which doesn't manually specify an application name on AddDataProtection), and I don't want to lose the cookies and encrypted tokens that are already in use. Is it just the project name?