Visual Studio 2015 - невозможно войти в систему, использовать NuGet и т.д. За корпоративным прокси

Я за корпоративным прокси-сервером, который требует аутентификации. Используя Visual Studio 2015, я не могу войти в систему, использовать NuGet, просматривать расширения и т.д. - все, что требовало бы прокси-сервера для доступа в Интернет. Это не проблема в предыдущих версиях Visual Studio.

Ошибка подключения NuGet

Если я запустил Fiddler, который действует как посреднический прокси и будет аутентифицироваться корпоративному прокси, тогда все работает. Или, если я получу свой ноутбук в общедоступном Интернете (не за корпоративным прокси), все работает.

Я пробовал модифицировать C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe.config, как предлагалось здесь. Я пробовал

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

и

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

... но безрезультатно. Кто-нибудь еще сталкивается с этой проблемой?

ОБНОВЛЕНИЕ: Как сказал Димитрий ниже, NuGet теперь работает правильно. Единственное, что по-прежнему не работает, - это экран входа в систему и канал "Избранные видео" на стартовой странице. Я был в контакте с нашей репутацией учетной записи Microsoft, и я отправляю дамп памяти в Microsoft для дальнейшего устранения.

ОБНОВЛЕНИЕ: NuGet снова перестает работать. Мы определили, что причина, по которой Fiddler делает это, потому что Fiddler заставляет соединения TLS 1.0. Основная проблема заключается в том, что наш корпоративный прокси, BlueCoat, не разрешает подключения TLS 1.2, и Visual Studio не должна изящно отступать от TLS 1.1 или 1.0, как это делает IE/Chrome. Вооружившись этой информацией, я собираюсь в нашу сеть/группу безопасности попытаться добраться куда-нибудь.

Ответы

Ответ 1

.Net 4.6 (и Visual Studio 2015) имеет разное значение по умолчанию для System.Net.ServicePointManager.SecurityProtocol, чем предыдущие версии фреймворка. В настоящее время по умолчанию используются TLS 1.2 и TLS 1.1 в дополнение к TLS 1.0. Вот почему это никогда не было проблемой в более ранних версиях Visual Studio.

В нашем случае проблема сводилась к нашему корпоративному прокси BlueCoat, не поддерживающему шифры TLS 1.2 ECDHE-ECDSA. Долгосрочным решением является обновление BlueCoat до версии, поддерживающей этот новый шифр. Но на короткий срок нам удалось указать порядок, в котором Windows пытается использовать разные шифровые сюиты, поэтому использует шифр, который понимает BlueCoat.

  • Откройте редактор локальных групповых политик (gpedit.msc)
  • Развернуть Конфигурация компьютера → Административные шаблоны → Сеть → Настройки конфигурации SSL.
  • Откройте настройку заказа SSL Cipher Suite.
  • Установите для параметра "Включено", а затем установите для SSL Cipher Suites следующее:

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

(убедитесь, что в списке нет пробелов после копирования и вставки)

  1. Нажмите ОК, а затем перезагрузите компьютер.

Единственное изменение по умолчанию - переместить TLS_ECDHE_RSA_WITH_AES_CBC_SHA_P256 в начало, чтобы шифры более высокой прочности ECDSA сначала не обсуждались для TLS 1.2. Если у вас возникла аналогичная проблема, вам может потребоваться работать с вашей сетью/командой безопасности, чтобы определить, какие шифры вам нужно отдавать.

Ответ 2

Используйте этот адрес в настройке NUGET

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

этот адрес является HTTP-protrocol и работает нормально.