Visual Studio 2015 – Can’t sign in, Use NuGet, etc. behind corporate proxy

nugetproxyvisual-studio-2015

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.

NuGet connection error

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.

Best Solution

.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)

  1. 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.

Related Question