Fiddler (local HTTPS MITM) no longer seeks .NET SDK traffic, .NET SDK rejects certificate

[joelverhagen]

Describe the bug

Up until .NET 10 Preview 6, I was able to see HTTPS traffic made by the .NET SDK using Fiddler. This is very useful for debugging protocol level issues, such as requests to NuGet.org for installing a template package.

I believe .NET SDK (or perhaps some other part of the toolchain) is using a different certificate validation routing and not deferring to the operating system which trusts the spoofed Fiddler certificates.

This makes debugging the .NET SDK harder, and reduces the transparency of what the SDK is doing over the wire.

To Reproduce

Launch Fiddler Classic with HTTPS decryption enabled.

Add this global.json to your working directory:

{
  "sdk": {
    "version": "10.0.100-preview.6.25358.103",
    "rollForward": "disable",
    "allowPrerelease": true
  }
}

Run:
dotnet new install Microsoft.Extensions.AI.Templates2 --nuget-source https://api.nuget.org/v3/index.json

You see this: no decrypted request, the command fails NOT with a missing package error (it should fail with missing package):

If you do the same on Preview 5 or Preview 4 (or older), you see:

Further technical details

• Include the output of dotnet --info
• The IDE (VS / VS Code/ VS4Mac) you're running on, and its version

.NET SDK:
 Version:           10.0.100-preview.6.25358.103
 Commit:            75972a5ba7
 Workload version:  10.0.100-manifests.af674642
 MSBuild version:   17.15.0-preview-25358-103+75972a5ba

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.26100
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\10.0.100-preview.6.25358.103\

.NET workloads installed:
 [aspire]
   Installation Source: VS 17.14.36301.6
   Manifest Version:    8.2.2/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.2\WorkloadManifest.json
   Install Type:              Msi

Configured to use workload sets when installing new manifests.
Workloads are configured to install and update using workload versions, but none were found. Run "dotnet workload restore" to install a workload version.

Host:
  Version:      10.0.0-preview.6.25358.103
  Architecture: x64
  Commit:       75972a5ba7

.NET SDKs installed:
  6.0.428 [C:\Program Files\dotnet\sdk]
  8.0.412 [C:\Program Files\dotnet\sdk]
  9.0.108 [C:\Program Files\dotnet\sdk]
  9.0.205 [C:\Program Files\dotnet\sdk]
  9.0.302 [C:\Program Files\dotnet\sdk]
  10.0.100-preview.4.25258.110 [C:\Program Files\dotnet\sdk]
  10.0.100-preview.5.25277.114 [C:\Program Files\dotnet\sdk]
  10.0.100-preview.6.25358.103 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.18 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 10.0.0-preview.4.25258.110 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 10.0.0-preview.5.25277.114 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 10.0.0-preview.6.25358.103 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.18 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 10.0.0-preview.4.25258.110 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 10.0.0-preview.5.25277.114 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 10.0.0-preview.6.25358.103 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.18 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 10.0.0-preview.4.25258.110 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 10.0.0-preview.5.25277.114 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 10.0.0-preview.6.25358.103 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  C:\z\scratch\sdk-proxy\global.json

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

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

[baronfel]

This is an interesting theory. For template installation we use the NuGetPackageDownloader, which is the central tool for downloading all package-based assets, and that uses the NuGet APIs, no direct HtpClient usage. But since other folks have reported telemetry detection issues, maybe there is something more cross-cutting?

[caunt]

Found the same problem using ChatGPT Codex environment which also uses MITM proxy for all HTTP/S requests. Worked well with .NET Preview 5.

[baronfel]

Hypothesis: dotnet/runtime#116098, may be dupe of dotnet/runtime#117681.

[caunt]

Hypothesis: dotnet/runtime#116098, may be dupe of dotnet/runtime#117681.

Yes! Setting DOTNET_SYSTEM_NET_SECURITY_NOREVOCATIONCHECKBYDEFAULT=true environment variable did help in case of Codex environment:

screenshot

[joelverhagen]

Yes, that worked for my Fiddler setup too!

[marcpopMSFT]

Triage: Looks like this is caused by the runtime change and now requires DOTNET_SYSTEM_NET_SECURITY_NOREVOCATIONCHECKBYDEFAULT. Not much we can do in the SDK repo. Resolving as a duplicate of that issue.