OpaqueRedirection doesn't respect HTTP/HTTPS scheme behind a load balancer.

[brad-technologik]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I run my blazor hybrid app behind a load balancer. However, this causes NavigationManager.NavigateTo to break, since it tries to redirect to an HTTP scheme when my app is accessed through HTTPS. Even after following instructions at Configure ASP.NET Core to work with proxy servers and load balancers, the http scheme is still not respected.

During redirection, the browser emits an error and does not redirect:

Mixed Content: The page at 'https://example.com/kanban' was loaded over HTTPS, but requested an insecure resource 'https://example.com/kanban/media'. This request has been blocked; the content must be served over HTTPS.

Refreshing the page redirect correctly since it doesn't use OpaqueRedirection.

Expected Behavior

The opaque redirector should honor the HTTPS/HTTPS scheme based on forwarded headers from a load balancer.

Steps To Reproduce

Clone my repo here: https://github.com/TrieBr/redirect-bug

1. Generate and trust certificates for reverse proxy:

cd nginx

dotnet dev-certs https -ep ./OpaqueRedirectionBug.pfx -p password --trust

openssl pkcs12 -in OpaqueRedirectionBug.pfx -nocerts -out OpaqueRedirectionBug.key

Enter 'password' for all 3 prompts.

openssl pkcs12 -in OpaqueRedirectionBug.pfx -clcerts -nokeys -out OpaqueRedirectionBug.crt

Enter 'password'.

openssl rsa -in OpaqueRedirectionBug.key -out OpaqueRedirectionBug.key

Enter 'password'.

2. CD back into the root folder (cd ../), and run docker-compose up.

3. visit https://localhost on your browser.

4. Open developer tools.

5. Then click "Weather" on the left navigation.

6. Observe in the "network" tab, the fetch of something like https://localhost/_framework/opaque-redirect?url=...

7. Observe that the returned header Location uses http and not https.

On localhost, this isn't an issue, but on a real domain, the browser will throw an error: This request has been blocked; the content must be served over HTTPS

The returned Location header should use the same http scheme in the request, honoring load balancer forwarded schemes.

Exceptions (if any)

No response

.NET Version

8.0.100

Anything else?

.NET SDK:
Version: 8.0.100
Commit: 57efcf1350
Workload version: 8.0.100-manifests.a7f084b6

Runtime Environment:
OS Name: Mac OS X
OS Version: 14.5
OS Platform: Darwin
RID: osx-arm64
Base Path: /usr/local/share/dotnet/sdk/8.0.100/

.NET workloads installed:
Workload version: 8.0.100-manifests.a7f084b6
[wasm-tools]
Installation Source: SDK 8.0.100
Manifest Version: 8.0.3/8.0.100
Manifest Path: /usr/local/share/dotnet/sdk-manifests/8.0.100/microsoft.net.workload.mono.toolchain.current/8.0.3/WorkloadManifest.json
Install Type: FileBased

Host:
Version: 8.0.4
Architecture: arm64
Commit: 2d7eea2529

.NET SDKs installed:
6.0.201 [/usr/local/share/dotnet/sdk]
6.0.402 [/usr/local/share/dotnet/sdk]
6.0.404 [/usr/local/share/dotnet/sdk]
7.0.100 [/usr/local/share/dotnet/sdk]
7.0.101 [/usr/local/share/dotnet/sdk]
7.0.302 [/usr/local/share/dotnet/sdk]
8.0.100-rc.1.23463.5 [/usr/local/share/dotnet/sdk]
8.0.100-rc.2.23502.2 [/usr/local/share/dotnet/sdk]
8.0.100 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.3 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.10 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.12 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.1 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.5 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.0-rc.1.23421.29 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.0-rc.2.23480.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.3 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.10 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.12 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.1 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.0-rc.1.23419.4 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.0-rc.2.23479.6 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.4 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
x64 [/usr/local/share/dotnet/x64]

Environment variables:
Not set

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download

[brad-technologik]

Upon further investigation, it seems like this is not specific OpaqueRedirection, as this occurs even with streaming disabled. In the reproduction steps, change Weather.razor to disable streaming (@attribute [StreamRendering(false)] and try again. When inspecting dev tools, you'll still see the Location header of the page use http instead of https.

[brad-technologik]

I've created a simple middleware workaround that changes the redirect (Location header) to https if the original request was https scheme:

// Workaround for https://github.com/dotnet/aspnetcore/issues/57650.
app.Use(async (context, next) =>
{
    await next(context);
    if (context.Response.StatusCode == (int)HttpStatusCode.Redirect &&
        context.Request.IsHttps && context.Response.Headers.Location.Count > 0)
    {
        var locations = context.Response.Headers.Location.ToArray();
        for(int i=0; i<locations.Length; i++)
        {
            if (locations[i]!.StartsWith("http://"))
            {
                locations[i] = locations[i]!.Replace("http://", "https://");
            }
        }
        context.Response.Headers["Location"] = new StringValues(locations);
        
    }
});

[javiercn]

@brad-technologik thanks for contacting us.

This seems to be an issue on your specific setup. Is the scheme on the incoming request that triggers the redirect HTTPS?

It is very unlikely that this is caused by opaque redirect as opposed to a misconfiguration on your app side. Opaque Redirect is a very thin wrapper over response.Redirect and that simply uses whatever is available on HttpContext.

aspnetcore/src/Components/Endpoints/src/Builder/OpaqueRedirection.cs

Line 92 in 6f71b2e

httpContext.Response.Redirect(url);

I would suggest you log the scheme that you add custom middleware on your environment to detect and log the scheme of the incoming request that triggers the opaque redirection. It's very likely that it is not set as HTTPS and that's the source of the issue.

[brad-technologik]

@javiercn I think the bug lies in UseForwardedHeaders middleware.

In my repro, when I add logging, X-Forwarded-Proto is set to https, but context.Request.IsHttps is still false in downstream middleware:

api-1           | Referer:https://localhost/weather?
api-1           | Upgrade-Insecure-Requests:1
api-1           | X-Real-IP:192.168.65.1
api-1           | X-Forwarded-For:192.168.65.1
api-1           | X-Forwarded-Proto:https
api-1           | X-Forwarded-Host:my-site
api-1           | sec-ch-ua:"Chromium";v="128", "Not;A=Brand";v="24", "Google Chrome";v="128"
api-1           | sec-ch-ua-mobile:?0
api-1           | sec-ch-ua-platform:"macOS"
api-1           | Sec-Fetch-Site:same-origin
api-1           | Sec-Fetch-Mode:navigate
api-1           | Sec-Fetch-User:?1
api-1           | Sec-Fetch-Dest:document
api-1           | context.Request.IsHttps: False

When I add the following middleware, the redirects work as expected:

app.Use((context, next) =>
    {
        if (context.Request.Headers["X-Forwarded-Proto"]=="https")
            context.Request.Scheme = "https";
        return next(context);
    });

However, I assumed that UseForwardedHeaders was supposed to do what the above does. Did I use UseForwardedHeaders incorrectly?

[brad-technologik]

Changing

builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders =
        ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
});

To

builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders = ForwardedHeaders.XForwardedProto;
});

fixed the issue, but I'm unclear why that worked, especially since that former is the example given in the documentation.

[javiercn]

@brad-technologik thanks for the additional details.

I'm not sure what can be going on. The logic for it is

aspnetcore/src/Middleware/HttpOverrides/src/ForwardedHeadersMiddleware.cs

Line 120 in 2152f3b

public void ApplyForwarders(HttpContext context)

I'm not sure if it's a bug on the code or a bug in the docs.