Visual Studio 2015 - Nie można się zalogować, użyć NuGet itp. Za korporacyjnym serwerem proxy

Question

Jestem za firmowym serwerem proxy, który wymaga uwierzytelnienia. Korzystając z programu Visual Studio 2015, nie mogę się zalogować, korzystać z NuGet, przeglądać rozszerzeń itp. - wszystkie rzeczy wymagające przejścia przez serwer proxy w celu uzyskania dostępu do Internetu. To nie jest problem w poprzednich wersjach Visual Studio.

Jeśli biegnę Skrzypek, który działa jako serwer proxy pośredniczącym, a uwierzytelnianie pełnomocnikowi korporacyjnej, a następnie wszystko działa. Lub, jeśli dostaję mój laptop w publicznym Internecie (nie za korporacyjnym proxy), wszystko działa.

Próbowałem zmodyfikować C: \ Program Files (x86) \ Microsoft Visual Studio 14.0 \ Common7 \ IDE \ devenv.exe.config zgodnie z sugestią here. Próbowałem

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

i

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

... ale bezskutecznie. Ktoś jeszcze napotkał ten problem?

AKTUALIZACJA: Jak wskazano poniżej Dimitri, NuGet działa teraz poprawnie. Jedyne, co nadal nie działa, to ekran logowania i kanał "Polecane filmy" na stronie początkowej. Byłem w kontakcie z naszym przedstawicielem konta Microsoft i wysyłam zrzut pamięci do firmy Microsoft, aby mógł je dalej rozwiązać.

AKTUALIZACJA: NuGet przestał działać ponownie. Ustaliliśmy, że przyczyną działania Fiddlera jest because Fiddler forces TLS 1.0 connections. Głównym problemem jest to, że nasz korporacyjny serwer proxy, BlueCoat, nie zezwala na połączenia TLS 1.2, a Visual Studio nie może z wdzięcznością zastąpić TLS 1.1 lub 1.0 jak IE/Chrome. Uzbrojony w te informacje, idę do naszego zespołu ds. Sieci/bezpieczeństwa, aby spróbować gdzieś się dostać.

Answer 1

.Net 4.6 (i Visual Studio 2015) ma inną wartość domyślną dla System.Net.ServicePointManager.SecurityProtocol niż wcześniejsze wersje architektury. Ustawienie domyślne obejmuje teraz TLS 1.2 i TLS 1.1, oprócz TLS 1.0. Dlatego nigdy nie było problemu we wcześniejszych wersjach Visual Studio.

W naszym przypadku problem sprowadził się do naszego korporacyjnego proxy BlueCoat, który nie obsługuje szyfrów TLS 1.2 ECDHE-ECDSA. Długoterminowym rozwiązaniem jest aktualizacja BlueCoat do wersji obsługującej ten nowy szyfr. Ale na krótką metę byliśmy w stanie określić kolejność, w której Windows próbuje używać różnych zestawów szyfrów, więc używa szyfru, który BlueCoat rozumie.

1. Otwarte Lokalna Grupa Policy Editor (gpedit.msc)
2. Expand Konfiguracja komputera -> Szablony administracyjne -> Sieć -> Ustawienia konfiguracji SSL.
3. Otwórz ustawienie kolejności szyfrowania pakietu SSL.
4. Ustaw ustawienie Włączone, a następnie ustawić kolejność SSL szyfrów do:

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

(upewnij się, że nie ma miejsca na liście po skopiuj i wklej go)

5. Kliknij przycisk OK, a następnie uruchom ponownie komputer.

Jedyna zmiana domyślnie jest przeniesienie TLS_ECDHE_RSA_WITH_AES_CBC_SHA_P256 na początku tak, że większa wytrzymałość szyfrów ECDSA nie są negocjowane pierwszy dla TLS 1.2. Jeśli masz podobny problem, być może będziesz musiał popracować z zespołem ds. Sieci/bezpieczeństwa, aby ustalić, które szyfry potrzebujesz, aby dać pierwszeństwo.

Answer 2

użyciu fiddler4 i pozwolić mu działać jako serwer proxy (i deszyfrowania ruchu HTTPS) działa wokół kwestii Using Fiddler to sniff Visual Studio 2013 requests (proxy firewall)

Answer 3

Wielu użytkowników (w tym ja) mają ten sam problem: https://social.msdn.microsoft.com/Forums/en-US/06e580a4-fede-43cf-b285-3d3d66fb1b9a/cant-sign-into-vs-2015?forum=vssetup

Aktualizacja: Z nowa wersja połączenia nuget => nuget działa.

Answer 4

używać tego adresu w Nuget ustawienie

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

ten adres jest HTTP protrocol i działają poprawnie.