TLSv1 awaria handshake

Question

(Zastrzeżenie: Jestem w żadnym odcinku wyobraźni ekspertem w dziedzinie bezpieczeństwa, ani okien eksperta o to chodzi)

Setup:

• serwera po naszej stronie: Java 1.6 (już dodany BouncyCastle do pliku zabezpieczeń) w systemie Windows server
• osoba trzecia klienckie 2003: Windows 2008 server z BizTalk
• wszystkich właściwości systemu renegocjacja wprowadzonych w związku z atakiem renegocjacji są „aktywne” na stronie serwera (nie jest bezpieczne wiem)

Idealnie chcemy to naprawić na końcu, ale w razie potrzeby możliwe jest zaproponowanie poprawki klientowi.

serwer

Klient musi połączyć się z naszym serwerem za pośrednictwem połączenia HTTPS, ale zawsze kończy się niepowodzeniem, Wireshark przedstawia następującą rozmowę:

> TLSv1: Client Hello 
< TLSv1: Alert (21): Unexpected Message 

Zgodnie z RFC (http://www.ietf.org/ rfc/rfc2246.txt) alert (21) odnosi się do nieudanego odszyfrowania iz tego, co widzę w Wireshark, żaden z szyfrów zaproponowanych przez klienta nie jest obsługiwany przez JRE 1.6 (jak na http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SupportedCipherSuites) W celu odtworzenia błąd, aby móc go bliżej przyjrzeć, przetestowałem z innym oprogramowaniem:

• Funkcja wfetch w systemie Windows XP z zaznaczonym "https" wykona wstępne uzgadnianie klienta w SSLv2, serwer przełączy się na TLSv1, aby odpowiedzieć, działa
• wfetch w systemie Windows XP z skonfigurowanym do używania "TLSv1" dla początkowego uzgadniania będzie nie w ten sam sposób, co serwer BizTalk
• wfetch na Windows 2008 z skonfigurowanych „https” użyje „TLSv1” do wstępnego uzgadniania i fail w ten sam sposób, co serwer BizTalk
• IE (w Windows XP) będzie najpierw spróbuj uścisku dłoni TLSv1 z tym samym wynikiem nieudanym, ale natychmiast spróbujesz ponownie używając SSLv3, który działa (w tym momencie uważam, że wszystkie oprogramowanie microsoft używa centralnej konfiguracji dostępnej w HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentCo ntrolSet \ Control \ SecurityProviders \ Schannel)
• Firefox używa SSLv3 dla całej rozmowy, więc nie ma problemu
• OpenSSL przeprowadza wstępną uzgadniania w SSLv2, a przełączniki serwera do TLSv1 kiedy to odpowiada, nie ma problemu tam
• OpenSSL może być zmuszone do wstępnego uzgadniania w TLSv1 także oferuje listę 27 szyfrów (w przeciwieństwie do 11 szyfrów zaproponowanych przez oparte na systemie Windows oprogramowanie) i można podłączyć bez problemu

aby moja niekompetentny oko to wzmacnia pogląd, że niezgodna propozycja szyfru jest podstawową przyczyną, dla której okna obsługują tylko zestawy szyfrów at nie są obsługiwane przez JVM (dla TLSv1). Zainstalowałem dmuchany zamek jako dodatkowy dostawca w pliku java.security bez skutku. Szukałem wysokiego i niskiego poziomu i znalazłem jedynie odnośnik, że być może strona internetowa obsługuje szyfry Windowsa dla TLSv1, ale nie ma możliwości pobrania niezależnego dostawcy, aby go przetestować. JRE 1.7 nie jest obsługiwane przez oprogramowanie, które uruchamiamy w naszym JVM, więc uaktualnienie nie jest opcją (być może dostawcę zabezpieczeń można bezpiecznie obniżyć?Jeszcze nie znalazłem do niego pobrania). Nie znalazłem sposobu na dodanie szyfru do Windowsa krótkiego od napisania kodu C++ (grałem z wyżej wymienionymi ustawieniami rejestru bez skutku).

Tak na zakończenie Zastanawiam się, czy jeden z następujących rzeczy byłoby to naprawić i jak powinny one być realizowane:

• dodać dostawcę do JVM, który może pracować z szyfrów dla TLSv1, które są proponowane przez okna
• jakoś zmusić klienta, aby zrobić wstępną uzgadniania w SSLv3 (najlepiej nie SSLv2) lub co najmniej powtórzyć jeśli handshake TLSv1 nie
• jakoś dodać JVM wspierany szyfr dla TLSv1 do Windows Client

Oczywiście inne rozwiązania są również mile widziane.

EDIT

wersja Java jest Java version (64 bit): 1.6.0_19-b04.

Listę proponowanych szyfrów jest:

• TLS_RSA_WITH_RC4_128_MD5
• TLS_RSA_WITH_RC4_128_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_RSA_WITH_DES_CBC_SHA
• TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
• TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
• TLS_RSA_EXPORT_WITH_RC4_40_MD5
• TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_DES_CBC_SHA
• TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA

są zainstalowane nieograniczone pliki zasad siła kryptografii. Próbowałem ustawić javax.net.debug=all i uruchomiłem serwer z konsoli, nie pojawiły się żadne dodatkowe dane wyjściowe. Ustawiłem sun.security.ssl.allowUnsafeRenegotiation=true bez rezultatu.

EDIT 2

Okazuje się oprogramowanie używamy wykorzystuje niestandardowy stos HTTPS zamiast domyślnego. Wydano poprawkę, która wydaje się rozwiązywać problem, chociaż nie wiem dokładnie, która część żądania TLS spowodowała błąd (widząc, że większość uścisków dłoni TLSv1 zakończyła się powodzeniem).

Dzięki za informację zwrotną, było to interesujące, jeśli daremne wyszukiwanie. Żyj i ucz się.

Answer 1

Okazuje się, że używane oprogramowanie używa niestandardowego stosu dla HTTPs zamiast domyślnego. Wydano poprawkę, która wydaje się rozwiązywać problem, chociaż nie wiem dokładnie, która część żądania TLS spowodowała błąd (widząc, że większość uścisków dłoni TLSv1 zakończyła się powodzeniem).

Dzięki za informację zwrotną, było to interesujące, jeśli daremne wyszukiwanie. Żyj i ucz się.

Answer 2

Możesz przeczytać mój artykuł na temat detecting cipher strength (aby upewnić się, że poprawnie zainstalowałeś szyfry jce). W swoim pytaniu mówisz, że zainstalowałeś nielimitowane szyfry, ale potem odwołujesz się do 128- i 40-bitowych kluczy. Tak więc jestem zdezorientowany tym, co masz. Czy mógłbyś sprawdzić siłę szyfrowania na certyfikacie SSL, z którym próbujesz się połączyć, i poinformować nas, co to jest i jaki jest algorytm?Upewnij się także, że plik zasad dla JDK ma odpowiednie uprawnienia, aby umożliwić nieograniczoną siłę.

Wreszcie, czy możesz połączyć się ze "znaną dobrą" stroną SSL, aby poprawnie zweryfikować uściski dłoni klienta? (Internet w Gmailu na przykład)