Nugetgallery: Still SSL/TLS issues from Visual Studio using Nuget

[abelbraaksma]

In issue https://github.com/NuGet/NuGetGallery/issues/7705#issuecomment-558822690 it was suggested that if the problem persisted, a report was welcome.

Unless you use the workaround provided in the issue, the error does persist, as shown in https://github.com/dotnet/fsharp/issues/10039, and by others in issue #7705. In particular, the following errors are still thrown:

Unable to load the service index for source https://api.nuget.org/v3/index.json.
An error occurred while sending the request.
The request was aborted: Could not create SSL/TLS secure channel.

To Reproduce

It appears to happen after updating Visual Studio, which re-enabled protocol TLS 1.3 (which is probably a good thing, but slightly annoying is recreates this issue).

Expected behavior

As mentioned in the other issue, it was assumed that this was fixed for NuGet client tools, but as far as I can tell, it isn't. The linked F# issue uses NuGet from FSI (F# Interactive) as installed with Visual Studio.

Additional context

At the moment this issue occurs, the mentioned registry settings are absent on my machine (Windows 7). It has been reported that on other machines it is present and the issue does not arise.

The problem only occurs in .NET Framework scenarios.

So: there's a workaround, but the issue isn't fixed. Considering very recent activity in the comments on this SO issue, suggests that it is certainly still happening in the wild: https://stackoverflow.com/questions/41185443/nuget-connection-attempt-failed-unable-to-load-the-service-index-for-source.

Other info

What makes this issue particularly taxing is that it appears to happen intermittently, though the larger the resource, the larger the chance there is that the above error is displayed. For instance, in FSI (which uses MSBuild Nuget), where I give the second nuget command half an hour later:

> #r "nuget:System.Memory";;
> 1;;
Microsoft (R) Build Engine version 16.7.0+b89cb5fde for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 30-8-2020 18:32:38.
Project "C:\Users\Abel\AppData\Local\Temp\nuget\13012--231c4591-2c45-4ecc-8264-1503061f34f6\Project.fsproj" on node 1 (Restore target(s)).
_GetAllRestoreProjectPathItems:
  Determining projects to restore...
Restore:
  Restoring packages for C:\Users\Abel\AppData\Local\Temp\nuget\13012--231c4591-2c45-4ecc-8264-1503061f34f6\Project.fsproj...
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets(128,5): error : Unable to load the service index for source https://api.nuget.org/v3/index.json. [C:\Users\Abel\AppData\Local\Temp\nuget\13012--231c4591-2c45-4ecc-8264-1503061f34f6\Project.fsproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets(128,5): error :   An error occurred while sending the request. [C:\Users\Abel\AppData\Local\Temp\nuget\13012--231c4591-2c45-4ecc-8264-1503061f34f6\Project.fsproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets(128,5): error :   The request was aborted: Could not create SSL/TLS secure channel. [C:\Users\Abel\AppData\Local\Temp\nuget\13012--231c4591-2c45-4ecc-8264-1503061f34f6\Project.fsproj]
Done Building Project "C:\Users\Abel\AppData\Local\Temp\nuget\13012--231c4591-2c45-4ecc-8264-1503061f34f6\Project.fsproj" (Restore target(s)) -- FAILED.

Build FAILED.

"C:\Users\Abel\AppData\Local\Temp\nuget\13012--231c4591-2c45-4ecc-8264-1503061f34f6\Project.fsproj" (Restore target) (1) ->
(Restore target) -> 
  C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets(128,5): error : Unable to load the service index for source https://api.nuget.org/v3/index.json. [C:\Users\Abel\AppData\Local\Temp\nuget\13012--231c4591-2c45-4ecc-8264-1503061f34f6\Project.fsproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets(128,5): error :   An error occurred while sending the request. [C:\Users\Abel\AppData\Local\Temp\nuget\13012--231c4591-2c45-4ecc-8264-1503061f34f6\Project.fsproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets(128,5): error :   The request was aborted: Could not create SSL/TLS secure channel. [C:\Users\Abel\AppData\Local\Temp\nuget\13012--231c4591-2c45-4ecc-8264-1503061f34f6\Project.fsproj]

    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:01.35
val it : int = 42

> #r "nuget:System.Memory";;
> 1;;
[Loading C:\Users\Abel\AppData\Local\Temp\nuget\13012--231c4591-2c45-4ecc-8264-1503061f34f6\Project.fsproj.fsx]
namespace FSI_0019.Project

~The same issue can occasionally be seen when loading NuGet packages through PM, but that seems to happen much rarer.~ EDIT: not observed anymore.

[abelbraaksma]

It appears like this is the MSBuild target using Nuget.Build.Task.dll causing trouble. The file is here: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets.

The version shipped with VS 16.7.2 is 5.7.0.7, in case that raises any alarmbells ;).

[agr]

nuget.org started enforcing the use of TLS 1.2 (and dropped support for TLS 1.1 and 1.0) earlier this year. Windows 7 has TLS 1.2 disabled by default (check the DisabledByDefault value under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client in your registry). To enable the support, please make sure you have an update installed and switch the support on:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f /reg:32
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v DisabledByDefault /t REG_DWORD /d 0 /f /reg:64
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f /reg:32
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v Enabled /t REG_DWORD /d 1 /f /reg:64

[abelbraaksma]

@agr, tx, I'm aware, but it was enabled (as can be seen by using PM). The problem seems to have been with with netfx only, as mentioned above.

I understood this was fixed in nuget, but both the scenario above and the nuget CLI don't enforce this apparently. In the referred issue it seems to have been fixed regardless of registry settings, but this doesn't appear to work.

What doesn't help is that vs update resets this.

[abelbraaksma]

In other words, the (hard to find and diagnose) workaround is not the problem, but that it doesn't work out of the box. Or, if that's not possible, to mention the workaround in the error, or to offer a switch to override the default of the system.

[agr]

TLS 1.3 support on *.nuget.org has been disabled (SSL scans for www.nuget.org and api.nuget.org) around the time #7705 was brought to our attention, so even if the client would try to negotiate it, the server should reject. So, I'm not sure TLS 1.3 has any relation here (unless TLS 1.3 is the only enabled protocol on the client).
What settings did VS update reset? TSL 1.2 or 1.3 or something else?

[abelbraaksma]

What settings did VS update reset? TSL 1.2 or 1.3 or something else?

It's not the first time I'm hitting this, but it appeared that the NetFX settings were reset. But now I'm not so sure whether it was VS or Windows Update. I did read in one report that VS indeed attempts to fix these settings.

After installation, I found the TLS 1.3 setting. Though Microsoft has confirmed that that setting is not supported. I would assume that, if the other settings were absent, that nuget would still work.

I've experimented a bit with the settings and found that:

• If SCHANNEL\Protocols\TLS 1.2\Client is present and enabled, it "just works", regardless of whether others are enabled or not
• If none are present, or only SSL 2.0, it gives this:
  Unable to load the service index for source https://www.nuget.org/api/v2. An error occurred while sending the request. The underlying connection was closed: An unexpected error occurred on a send. Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. An existing connection was forcibly closed by the remote host

Either way, if Nuget "knows" it cannot negotiate an SSL/TLS connection, it may be helpful if that is said, or something along the lines with "NuGet doesn't support TLS 1.0 or 1.1, please enable TLS 1.2 on your system". Give it a nice specific error code and people will find the workaround soon enough.

Though I've to say that I'm a little surprised that NuGet cannot force TLS 1.2 regardless of these Registry settings: any other network-tool has no problems with negotiating a connection for TLS 1.2. Why take these system settings as gospel?

[agr]

I am not developing the client, but my understanding is following: NuGet client can't force TLS 1.2 connections globally as the end user might be using servers other than nuget.org that has their own ideas about security. On the other hand, nuget.org should not have any special treatment as it is just one of the implementers of the protocol and might not necessary in package operations on some client systems.

Generally, not hardcoding TLS versions in the app is the way to be future proof: when TLS 1.3 (or 1.4, or whatever comes after it) becomes available, it would be a matter of flipping the system setting to have support for it in all clients that don't hardcode TLS version. Hardcoding would break older clients, likely to cause business interruptions and would require an update.

Some better error message by the client though might be helpful. I see you have similar issue open in Home: https://github.com/NuGet/Home/issues/9961, feel free to update it with findings and suggestions relevant to the client.

[abelbraaksma]

Hardcoding would break older clients, likely to cause business interruptions and would require an update.

That's it not what I mean to suggest. Just like browsers and other clients, you have a challenge/response session with the server, and you connect with the highest available protocol that's available on client and server.

That's future proof, and flexible, and independent of machine wide settings.