2010-06-12 11 views
9

Moja aplikacja musi rozmawiać z różnymi hostami przez HTTPS, a domyślne ustawienie ServicePointManager.SecurityProtocol = TLS służy mi dobrze do dziś. Teraz mam niektóre hosty, które (jak pokazuje dziennik śledzenia System.Net) nie odpowiadają na początkowy komunikat uzgadniania TLS, ale utrzymują otwarte połączenie aż do przekroczenia limitu czasu, powodując wyjątek limitu czasu. Próbowałem ustawić limit czasu na HttpWebRequest na 5 minut, z tym samym wynikiem. Prawdopodobnie hosty te oczekują na uzgadnianie SSL3, ponieważ zarówno IE, jak i Firefox są w stanie połączyć się z tymi hostami po 30-40 sekundowym opóźnieniu. Wydaje się, że w .NET występuje mechanizm awaryjny, który pogarsza TLS do SSL3, ale z jakiegoś powodu nie działa.Jak używać SSL3 zamiast TLS w konkretnym HttpWebRequest?

FWIW, oto wiadomość handshake moja prośba jest wysyłanie (regularny TLS 1.0 KLIENT CZEŚĆ wiadomość):

00000000 : 16 03 01 00 57 01 00 00-53 03 01 4C 12 39 B4 F9 : ....W...S..L.9.. 
00000010 : A3 2C 3D EE E1 2A 7A 3E-D2 D6 0D 2E A9 A8 6C 03 : .,=..*z>......l. 
00000020 : E7 8F A3 43 0A 73 9C CE-D7 EE CF 00 00 18 00 2F : ...C.s........./ 
00000030 : 00 35 00 05 00 0A C0 09-C0 0A C0 13 C0 14 00 32 : .5.............2 
00000040 : 00 38 00 13 00 04 01 00-00 12 00 0A 00 08 00 06 : .8.............. 
00000050 : 00 17 00 18 00 19 00 0B-00 02 01 00    : ............  

Czy istnieje sposób na wykorzystanie SSL3 zamiast TLS w danym HttpWebRequest, lub wymusić fallback ? Wygląda na to, że ustawienie ServicePointManager jest globalne i naprawdę nie chciałbym obniżać ustawienia protokołu bezpieczeństwa do SSL3 dla całej aplikacji.

+0

Czy rzeczywiście przetestowałeś swoją hipotezę, zmieniając ustawienie połączenia na SSL3? – Amnon

+0

Tak, hipoteza okazała się prawidłowa. Hosty były Netware i wydaje się, że jest to zasada Netware dotycząca nierozpoznanych/nieprawidłowych żądań, aby nie odpowiadać ani nie przekazywać komunikatów o błędach, prawdopodobnie w celu zmniejszenia powierzchni ataku. –

Odpowiedz

12

Rzeczywiście, ustawienia ServicePointManager są określane dla domeny app-app. Pozwoliło mi to obejść problem, tworząc osobną konfigurację aplikacji do używania tylko SSL3, dzięki czemu mój obiekt zbierania danych MarshalByRefObject (zarówno WebClient, jak i WebRequest jest uporządkowany według kolejności, ale lepiej, aby zmniejszyć liczbę połączeń między różnymi domenami) i tworzenie tam. Doskonale działał w połączeniu ze schematem wykrywania opartym na limicie czasu.

+0

Skąd napisałeś ten fragment kodu? 'System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls' –

+0

@AnishV lub do kogo może on dotyczyć:' Obiekt ServicePointManager' pochodzi z przestrzeni nazw 'System.Net' i zachowuje stan statyczny. Tak więc, tylko "używanie" tej przestrzeni nazw i wykonywanie 'ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11; '* once * przed wykonaniem danej operacji wykonuje sztuczkę. – kmonsoor

3

. NET zawiera przepisy umożliwiające automatyczne przejście do niższych wersji protokołu. Wartość ServicePointManager.SecurityProtocol określa zachowanie. Może przyjmować 3 różne wartości: SecurityProtocol.Ssl3, SecurityProtocol.Tls, or SecurityProtocol.Ssl3 | SecurityProtocol.Tls. Chociaż globalny, może być zmieniany w razie potrzeby.

Nie mogę zidentyfikować rozwiązania bez dostępu do serwera z takim samym błędnym zachowaniem. Jedyną propozycją, jaką mogę zrobić, to próba połączenia się z ustawieniem Ssl3 | Tls, a jeśli to nie zadziała, spróbuj ponownie za pomocą ustawienia Ssl3. Spróbuj zmniejszyć limit czasu i przechwycić wyjątek limitu czasu, a następnie ponów próbę.

EDIT

Wiele z tego co napisałem w poprzedniej wersji tej odpowiedzi było źle.

+3

W aplikacji wielowątkowej zmiana globalnych ustawień nie jest dobrym pomysłem, a "ServicePointManager.SecurityProtocol" musi pozostać niezmieniony przez cały czas trwania żądania, więc zrobiłem to w inny sposób. –

Powiązane problemy