HTTPS everywhere
Safety guaranteed
As an ongoing effort to make HTTPS everywhere a reality for NuGet, we have taken a number of steps to help protect your everyday package management experiences.
Earlier this year, a security fact sheet from The White House reinforced companies to take action to secure our software supply chains.
HTTPS and SSL not only encrypt our data so it cannot be used if it is stolen, but it helps us to avoid MITM attacks. In short, it prevents someone from getting between you and NuGet. Every time you interact with NuGet, it should be over HTTPS so you can be sure the response you’re getting back is in fact being delivered by NuGet.
NuGet is HTTPS everywhere
Historically NuGet was only available over HTTP or unvalidated HTTPS connections. Over time and as HTTPS became more prevalent, we’ve been pushing more and more traffic onto HTTPS as a best practice.
On NuGet.org, we even made the decision to redirect API URLs from HTTP to HTTPS. These redirects over the HTTPS connections issue a HSTS header that instructs any supporting client to default to HTTPS from now on. If you were to access a HTTP URL however, it would silently redirect to HTTPS and appear to work, but you wouldn’t get any of the security properties of TLS because an attacker could intercept the request prior to the redirect happening.
For NuGet client experiences, we will be pushing towards the use of HTTPS sources as an on-going effort to bring HTTPS everywhere.
What You Can Expect
- In NuGet 6.3, we have introduced a new NU1803 warning that will let you know that you’re using a non-HTTPS source.
- In November 2023, we will upgrade that warning into a new error when a non-HTTPS source is used. You will be able to opt-out of this behavior for the time being to help migrate to HTTPS sources.
- In November 2024, we will throw an error when a non-HTTPS source is used. You will not be able to opt-out of this behavior.
If you are unable to upgrade to a HTTPS source for reasons outside of your control, do work with your package source provider and provide us your feedback on your workflow so we are aware of it.
Closing
While older versions of NuGet will not include these changes for now, it is always recommended that you upgrade your tooling to the latest versions to ensure it supports verified TLS connections and default to proper HTTPS URLs.
For more details on NuGet 6.3, see our official release notes.
Feedback
Your feedback is important to us. If there are any problems with this experience, check our GitHub Issues and Visual Studio Developer Community for existing issues. For new issues within NuGet, please report a GitHub Issue. For general NuGet experience issues, let us know via the Report a Problem option found in your favorite IDE under Help > Report a Problem.
Light
Dark
15 comments
Now I know why my build which worked yesterday perfectly, failed todays morning. Thanks)
Did the new NU1803 warning fail your build? Or something else?
this comment has been deleted.
Hi,
it is the same issue as described here.
https://developercommunity.visualstudio.com/t/Visual-Studio-2022-173-I-cannot-use-the/10115731?space=8&q=nuget&sort=newest
Will it be changed to a warning like described in the article above under “What you can Expect”?
Hey all,
NU1803 is a warning.
It is likely that your project is elevating it to an error.
You can consider NoWarn NU1803 temporarily.
YES, this is failing ALL OF MY BUILDS….literally yesterday they worked, today the don’t.
Will try Nikolche Kolev’s idea in the meantime. But please realize that many people have internally hosted NuGet servers with no access to the internet for caching NuGet packages or hosting their own and do not need the complexity or the overhead of managing TLS certificates for these servers.
Same. I get the secure thing…but really? This is a nightmare for those locally hosting packages on their own private NuGet server. Now it’s another security certificate to manage and for little value. This is one of the worst decisions yet. Ugh. Thanks for making my life even more difficult and causing all of my development team’s builds to begin to fail literally overnight.
Using https is a good thing when calling nuget.org. In our case it is not required. We have an own on-premise dev ops server in our private intranet. There a nuget store is running. Our company do not plan upgrade to https in our intranet.
For the moment it is working well because it is only a warning. But you descriped that this warning will be converted to an error in future. Then we have a problem of course.
Is it possible that only nuget.org requires https?
Below you can find the warning produced from visual studio:
Warnung NU1803 You are running the 'restore' operation with an 'HTTP' source, 'http://intranet-tfs/_packaging/My-Feed@Local/nuget/v3/index.json'. Non-HTTPS access will be removed in a future version. Consider migrating to an 'HTTPS' source.I second this. I do not understand why companies should waste development resources to mitigate imaginary security concerns. MITM in the intranet? Sure.
By removing the opt-out option Microsoft basically tells us “just shut up, we know what is better for you”. So arrogant.
We have the same Problem and i even can’t find a solution on how to migrate the Azure Devops Artifacts Feed to https. We would do it if necessary, but please tell me how?
Agree, 1000%.
Another supporter here… this is a VERY BAD idea for most of the internal intranets that I work with.
My own company’s internal systems are NEVER accessed over a public facing IP address, in fact they are 100% firewalled off, and cannot be accessed outside the companies internal network ranges.
I have juniors/trainees and learners that already get panicked when a server or build fails to show up, I’m not spending countless hours running around trying to fix internal self signed certificate error’s too.
I agree, that HTTPS should be an option, and maybe even the default setting for teams working over an open public internet connection, but my internal NuGet servers (Most of which I run using BaGet) are not HTTPS, do not need to be HTTPS, and because they are not public accessible, cannot have a let’s encrypt or other similar certification added to them.
I would rather actively seek to BREAK the encryption, than be forced to use it against my will…. how I run my internal network, inside my company is NONE of your business and you should not be dictating this, you should continue to offer the option to turn off HTTPS if so needed.
I understand fully, WHY decisions like this are made against regular things that regular members of the public make use of, and how it helps you to “offer support”, when people don’t do things the correct way, and invariably shoot themselves in the foot…
But your NOT dealing with regular members of the public here, your dealing with skilled software developers, that should know better and should be trusted to make the right decision for what they need.
We use Baget as our private on-premised Nuget Server. So no need to use HTTPS. I hope there will be some settings for Nuget to Not treat HTTP address as ERROR. Like introduce some envs, NUGET_ERROR_IF_HTTP=false/true.
Please, please, please don’t do this – https is NOT required everywhere, especially within a development environment and not all sources are external. People use VPN’s also for security. Please roll this back. It’s a horrible idea.