NUGET_CERT_REVOCATION_MODE not using HTTPS

[skirk-mpr]

NuGet Product(s) Affected

dotnet.exe

Current Behavior

In an AWS CodeBuild environment where I only allow outbound HTTPS traffic (443) the dotnet restore command on my application which includes public nuget packages, would take an extremely long amount of time (20+ minutes) -- but by setting NUGET_CERT_REVOCATION_MODE to offline it would be as fast as if HTTP/80 was allowed (~15 seconds). It seems like the status check of the certificate used to sign a package is done over HTTP and not HTTPS. This blog post suggests everything should be done over HTTPS related to nuget: https://devblogs.microsoft.com/nuget/https-everywhere/

Desired Behavior

Client should be able to enforce that the status check of the certificates used to sign a packages is done only over HTTPS/443.

Additional Context

I have an open StackOverflow Question here that I slowly came to the hypothesis that this is the underlying culprit.: https://stackoverflow.com/questions/78755772/nuget-enforce-https-only-traffic-from-aws-codebuild

[zivkan]

@skirk-mpr the URL is determined by a certificate authority, not by NuGet, or even directly by a package owner signing their package.

I can find NuGet's global packages folder by running dotnet nuget locals global-packages -l. I can go into a package's directory, for example system.text.json, select a version directory, and on Windows I can double click the .signature.p7s file. This will open the Certificate Manager where I can inspect all the certificates in the bundle. I'm not experienced with either Linux or Mac, so I don't know how to inspect the certificate bundle on those operating systems.

The two root certificates don't have it, but the other 4 certificates I see listed all have a property named "CRL Distribution Points" (can be seen in the details tab). The value of the certificate CRL is HTTP, as can be seen in this screenshot:

I don't know enough about X509 certificate chains to understand why they use HTTP, rather than HTTPS, but they're defined by the certificate issuer. If you use your web browser to inspect the HTTPS certificate for github.com, or other websites like google.com, you'll see all their CRL distribution points use HTTP URLs as well.

So, unfortunately I don't see anything actionable by NuGet here. To do X509 code signing verification "properly", we need to check that the certificate wasn't signed after it was revoked, and the certificate issuers are telling us to use http URLs.

You could find the CRL distribution points of all the packages you currently use, and change your firewall rules to allow them. There's a risk that new packages will need a different CRL URL, but I'd expect all Microsoft packages to use the same ones, so I hope the overall number will be low.

[dotnet-policy-service[bot]]

This issue has been automatically marked as stale because we have not received a response in 14 days. It will be closed if no further activity occurs within another 14 days of this comment.