Use TLS 1.2 for WebProxyRequests

[jtrinklein]

This fixes the issue caused by Github removing support for weak cryptographic standards. https://githubengineering.com/crypto-removal-notice/

Fixes issue #3065

[BlythMeister]

I don't think you can just force 1.2 as this may be used for other web requests.
Suggest making it support other cyphers as well.

I normally just put tls12, tls11, tls, ssl3

[jtrinklein]

Which would you recommend supporting?

[ppatino]

@jtrinklein this Bootstrapper is .NET 4.5: https://github.com/fsprojects/Paket/blob/master/src/Paket.Bootstrapper/Paket.Bootstrapper.csproj

I believe the default System.Net.ServicePointManager.SecurityProtocol in both .NET 4.0/4.5 is SecurityProtocolType.Tls|SecurityProtocolType.Ssl3 per https://stackoverflow.com/a/28333370.

I would suggest turning on TLS1.2 while leaving defaults as-is by replacing your change with:
ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12;

@BlythMeister thoughts?

[ppatino]

Suggestion to enable TLS1.2 while leaving other enabled security protocols untouched via:
ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12;

[BlythMeister]

I would say do this

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12
                                         | SecurityProtocolType.Tls11
                                         | SecurityProtocolType.Tls
                                         | SecurityProtocolType.Ssl3;

[BlythMeister]

This file https://github.com/fsprojects/Paket/blob/master/src/Paket.Core/Common/Utils.fs has a service point update as I would expect this is in Paket itself, not bootstrapper.
I would suggest replicate this into the app itself.
So put all 4 of the protocol enums I put above with a pipe separator. Like this

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12
                                         | SecurityProtocolType.Tls11
                                         | SecurityProtocolType.Tls
                                         | SecurityProtocolType.Ssl3;

[BlythMeister]

Also, in console apps you typically find this statement in the program.cs above the main function since it's an application wide directive it's logical to live with the main application.

[ppatino]

@BlythMeister that compiler if is avoiding setting ServicePointManager.SecurityProtocol if on NetStandard 1.6, which corresponds to .NET Core 1.0 https://docs.microsoft.com/en-us/dotnet/standard/net-standard.

It appears that ServicePointManager.SecurityProtocol is not available in .NET Core https://stackoverflow.com/questions/39560249/servicepointmanager-in-asp-net-core, so this makes sense.

So, I think Paket.Core is enabling TLS 1.2 (actually all 4 available protocols in the enum) for the full framework version of Paket. This is my first time jumping into the code, but I see some 'Paket.Core.preview3' stuff with latest commits indicating that there is a .NET Core Paket in the works, which I assume is why the compiler flag is there in the first place. The active (non-preview) Paket.core is .net 4.5 https://github.com/fsprojects/Paket/blob/master/src/Paket.Core/Paket.Core.fsproj, so the ServicePointManager.SecurityProtocol is getting set in the regular non-netcore Paket.

All that is to say, I think Paket.Core (main project) enables TLS 1.2 and it was forgotten / not done in the Bootstrapper. I think that enabling all 4 protocols as is done in Paket.core for the full .NET framework is the way to go here.

[grantaholliday]

Adding TLS 1.2 as a supported protocol is a reasonable workaround, but not a permanent fix.
ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12;

When TLS 1.3 (or some other protocol version) becomes available in the OS, you won't be able to make use of it without making a similar change again.

The recommended fix is to target .NET 4.7. Then .NET gets out of the way and lets the OS decide what protocols should be available.

Another workaround is to set a machine-wide registry key that tells .NET to get out of the way, and lets the OS decide. The problem with this, is that it may adversely impact other .NET apps on the machine that attempt to connect to TLS 1.0 servers that fail when trying to downgrade from a client requesting TLS 1.2.

reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:64
reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:32

[dsyme]

Looking forward to this - there are lots of failing paket bootstrappers out there now :)

[BlythMeister]

Going for a .net Framework upgrade could have other effects.
Perhaps this is a short term workaround and then investigate releasing an upgraded bootstrap at 4.7?

[ptrstpp950]

As I understand above change will fix only bootstraper, so we propbably will have another bunch of problems with gist references.

[forki]

Please send pull requests.

[BlythMeister]

gist references should be ok, as https://github.com/fsprojects/Paket/blob/master/src/Paket.Core/Common/Utils.fs has the settings set.