HTTPS Everywhere Update

Jon Douglas

September 19th, 20237 4

Mistakes were made

When we first published the plan for the effort of HTTPS everywhere, we wanted to get developer community feedback on the various HTTP and HTTPS scenarios that we don’t have much everyday visibility of. After we published that blog, we heard you loud and clear that there was a gap. This plan needed a clear way to suppress the eventual error case when a non-HTTPS source is used due to various scenarios where you are able to accept the security risk.

We’ve recently added such functionality that will allow you to do just that. In NuGet 6.8, you will be able add the allowInsecureConnections attribute to your respective packageSources in your nuget.config to enable or disable this functionality. The default is allowInsecureConnections="false".

Here’s an example:

<packageSources>
    <clear />    
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="Contoso" value="http://contoso.com/packages/" allowInsecureConnections="true" />
    <add key="Test Source" value="c:\packages" />
</packageSources>

In this example, the insecure http source called Contoso has the allowInsecureConnections attribute set to true and therefore will ignore any default non-HTTPS warnings and errors.

How we’ve made it right

For how we got here, we took all the community feedback to come up with an open source proposal on what we believe will improve this experience. Next, we created an epic of including this functionality in all the various NuGet tooling. You should see this functionality in NuGet 6.8, .NET SDK 8.0.100, and Visual Studio 17.8.

Continuing on

We will continue on the original plan’s trajectory of upgrading this warning into an error when non-HTTPS sources are used. The only difference is that you will now be able to opt-out of this behavior. Keep an eye on the NuGet official release notes for when that will be.

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.

Jon Douglas Principal Program Manager, NuGet

7 comments

Glaser, Thomas September 20, 2023 6:06 am 0

Awesome, thanks for that update! This is a very welcome change, we are too still using a HTTP only feed (on-prem).

Jon Douglas September 22, 2023 1:39 pm 1

Thank you for the comment!

Tobias Kolb September 21, 2023 11:52 pm 0

Is there something equivalent about the command line interface source parameter?

nuget.exe restore solution.sln -Source http://host:port/nuget/

Jon Douglas September 22, 2023 1:39 pm 2

There is not right now. We typically try to detach the -Source parameter behavior from nuget.config behavior. Please do feel free to file an issue so we can investigate the interest in this experience.

Stephen Donaghy September 22, 2023 4:15 am 1

I do think giving an ability to override/disable the https requirement was the right choice, but reading that github issue thread does scare me a little bit – the amount of people leaving themselves open to supply-chain-attacks because they’re sure that their server has no access to the outside world is slightly mind-boggling.

It doesn’t take a huge amount of effort to set up a certificate store, add the CA cert to all your machines and generate a tls cert for your private feed – and anything else in your internal network that you want to secure. Security should be by default, not an exception.

Oh well, different strokes for different folks I guess.

Tobias Kolb September 22, 2023 5:04 am 1

For sure you are right. Meanwhile here I am still waiting for a valid certificate. The local admin does not care or it costs money, IDK. The topic is up a year and nothing has happened.

It’s good to have a plan B.
Jon Douglas September 22, 2023 1:36 pm 1

Thanks for your perspective!

Discussion is closed. Login to edit/delete existing comments.

Glaser, Thomas September 20, 2023 6:06 am 0

Awesome, thanks for that update! This is a very welcome change, we are too still using a HTTP only feed (on-prem).
- Jon Douglas September 22, 2023 1:39 pm 1
  
  Thank you for the comment!
Tobias Kolb September 21, 2023 11:52 pm 0
Is there something equivalent about the command line interface source parameter?
```
nuget.exe restore solution.sln -Source http://host:port/nuget/
```
- Jon Douglas September 22, 2023 1:39 pm 2
  
  There is not right now. We typically try to detach the -Source parameter behavior from nuget.config behavior. Please do feel free to file an issue so we can investigate the interest in this experience.
Stephen Donaghy September 22, 2023 4:15 am 1

I do think giving an ability to override/disable the https requirement was the right choice, but reading that github issue thread does scare me a little bit – the amount of people leaving themselves open to supply-chain-attacks because they’re sure that their server has no access to the outside world is slightly mind-boggling.

It doesn’t take a huge amount of effort to set up a certificate store, add the CA cert to all your machines and generate a tls cert for your private feed – and anything else in your internal network that you want to secure. Security should be by default, not an exception.

Oh well, different strokes for different folks I guess.
- Tobias Kolb September 22, 2023 5:04 am 1
  
  For sure you are right. Meanwhile here I am still waiting for a valid certificate. The local admin does not care or it costs money, IDK. The topic is up a year and nothing has happened.
  
  It’s good to have a plan B.
- Jon Douglas September 22, 2023 1:36 pm 1
  
  Thanks for your perspective!