Visual Studio 2015 - Can't sign in, Use NuGet, etc. behind corporate proxy

Question

I'm behind a corporate proxy server that requires authentication. Using Visual Studio 2015, I am not able to sign in, use NuGet, browse Extensions, etc. - all things that would require going through the proxy to access the Internet. This isn't a problem in previous versions of Visual Studio.

If I run Fiddler, which acts as an intermediary proxy, and will authenticate to the corporate proxy, then everything works. Or, if I get my laptop on public Internet (not behind the corporate proxy), everything works.

I've tried modifying C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe.config as suggested here. I've tried

<defaultProxy enabled="true" useDefaultCredentials="true">
   <proxy bypassonlocal="True" proxyaddress="http://<yourproxy:port#>"/>
</defaultProxy>

and

<defaultProxy enabled="true" useDefaultCredentials="true">
   <proxy usesystemdefault="true"/>
</defaultProxy>

...but to no avail. Anyone else run into this issue?

UPDATE: As Dimitri stated below, NuGet now works correctly. The only thing that still doesn't work is the sign-in screen and the "Featured Videos" feed on the Start page. I've been in contact with our Microsoft account rep, and I'm sending a memory dump to Microsoft for them to troubleshoot further.

UPDATE: NuGet stopped working again. We've determined that the reason that Fiddler makes it work is because Fiddler forces TLS 1.0 connections. The main issue is that our corporate proxy, BlueCoat, is not allowing TLS 1.2 connections, and Visual Studio must not gracefully fallback to TLS 1.1 or 1.0 like IE/Chrome does. Armed with this info, I'm going to our network/security team to attempt to get somewhere.

Answer 1

.Net 4.6 (and Visual Studio 2015) has a different default for System.Net.ServicePointManager.SecurityProtocol than prior versions of the framework. The default now includes TLS 1.2 and TLS 1.1, in addition to TLS 1.0. That's why this was never an issue in earlier versions of Visual Studio.

In our case, the issue came down to our corporate BlueCoat proxy not supporting the TLS 1.2 ECDHE-ECDSA ciphers. The long-term solution is to update BlueCoat to a version that supports this new cipher. But for the short term, we were able to specify the order that Windows attempts to use different cipher suites, so it uses a cipher that BlueCoat understands.

1. Open Local Group Policy Editor (gpedit.msc)
2. Expand Computer Configuration -> Administrative Templates -> Network -> SSL Configuration Settings.
3. Open the SSL Cipher Suite Order setting.
4. Set the setting to Enabled, and then set the SSL Cipher Suites order to:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_RC4_128_MD5,SSL_CK_RC4_128_WITH_MD5

(make sure there are no spaces in the list after you copy-and-paste it)

5. Hit OK, and then Restart your computer.

The only change from default is to move TLS_ECDHE_RSA_WITH_AES_CBC_SHA_P256 to the beginning so that higher strength ECDSA ciphers are not negotiated first for TLS 1.2. If you're having a similar problem, you may need to work with your network/security team to determine what ciphers you need to give preference to.

Answer 2

Use this address in NUGET setting

http://packages.nuget.org/v1/FeedService.svc/ 

this address is HTTP protrocol and work fine.

Answer 3

using fiddler4 and let it act as a proxy (and decrypt the https traffic) works around the issue Using Fiddler to sniff Visual Studio 2013 requests (proxy firewall)

Answer 4

Many users(including me) have same issue: https://social.msdn.microsoft.com/Forums/en-US/06e580a4-fede-43cf-b285-3d3d66fb1b9a/cant-sign-into-vs-2015?forum=vssetup

Update: With new version of nuget => nuget connection is now working.

Answer 5

On Visual 2019 I ran into a similar problem.

I saw the following error output by NuGet package manager in Visual Studio:

https://api.nuget.org/v3/index.json: Unable to load the service index for source https://api.nuget.org/v3/index.json. 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.

I saw the same error when executing dotnet restore --interactive from the command prompt.

This was oddly fixed by doing the following, which amounted to no saved changes for the SSL Cipher Suite Order (I guess it got corrupted somehow). Note, mine was disabled, and all I did was enable then re-disable without doing any changes.

1. Open the Local Group Policy Editor via Run -> gpedit.msc
2. Open SSL Cipher Suite Order from Administrative Templates -> Network -> SSL Configuration Settings
3. Select Enabled then press OK
4. Select Disabled then press OK
5. Restart computer