Jak skonfigurować IIS 7.5 SSL \ TLS do pracy z iOS 9 ATS

Problem: nasza aplikacja mobilna nie może już ustanowić bezpiecznego połączenia z naszą usługą internetową, ponieważ iOS 9 używa teraz ATS.

Tło: iOS 9 wprowadza App Transport Security

Konfiguracja serwera: Windows Server 2008 R2 SP1 (VM) IIS 7.5, certyfikaty SSL od digicert. Zapora systemu Windows wyłączona.

Kluczowe bity RSA 2048 (E 65537)

Wystawca DigiCert SHA2 Secure Server CA

Algorytm podpisu SHA512 zRSA

Są to wymagania dotyczące bezpieczeństwa aplikacji do transportu:

Serwer musi obsługiwać co najmniej protokół Transport Layer Security (TLS) w wersji 1.2. Szyfry połączeń są ograniczone do tych, które zapewniają poufność przekazywania (patrz lista szyfrów poniżej). Certyfikaty muszą być podpisane przy użyciu algorytmu skrótu SHA256 lub lepszego, z kluczem RSA o długości 2048 bitów lub większym lub z 256-bitową lub większą krzywą eliptyczną Klawisz (ECC). Nieprawidłowe certyfikaty powodują ciężką awarię i brak połączenia. Oto akceptowane szyfry:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

Co zostało wypróbowane:

1. Dodanie wyjątków w aplikacji mobilnej, aby umożliwić działanie naszej domeny, ale nie chcę korzystać z tej niezabezpieczonej metody, chcę naprawić nasze SSL.
2. Używane IIS Crypto używać „dobrych praktyk”, próbował „pci” oraz niestandardowych ustawień. Próbowałem nawet zmodyfikować pakiet kryptograficzny tylko do powyższej listy i zmienić jego kolejność. Po każdej próbie serwer jest uruchamiany ponownie i uruchamiane są Laboratorium SSL (po wyczyszczeniu pamięci podręcznej). Udało mi się przejść z oceny F na A, a nawet A, ale to tylko spowodowało, że iOS 8 i 9 nie były w stanie ustanowić bezpiecznych połączeń. (Kod NSURLErrorDomain = -1200 i _kCFStreamErrorCodeKey = -9806)
3. Przywróciłem maszynę wirtualną i wypróbowałem skrypt PowerShell Skonfiguruj IIS dla SSL Perfect Forward Secrecy i TLS 1.2 Podjąłem nawet drugą próbę, w której wyedytowałem szyfry ze skryptu zasilania na minimalną listę wymaganych elementów.

Wyniki: Zawsze podobne, oceny A lub A-. iOS8 i iOS9 nie mogą negocjować bezpiecznego połączenia. Symulacja uzgadniania powoduje „niedopasowanie protokołu lub zestawu szyfrów” dla produktów Safari i iOS.

AKTUALIZACJA Po pracy ze wsparciem Apple wykonaliśmy przechwytywanie śledzenia pakietów:

$ tcpdump -n -r trace.pcap
reading from file trace.pcap, link-type EN10MB (Ethernet)
client > server [S], seq 1750839998, win 65535, length 0
server > client [S.], seq 2461151276, ack 1750839999, win 8192, length 0
client > server [.], ack 1, win 4104, length 0
client > server [P.], seq 1:175, ack 1, win 4104, length 174
server > client [R.], seq 1, ack 175, win 0, length 0

Pierwsze trzy pakiety to klasyczny trójdrożny uścisk dłoni SYN - SYN-ACK - ACK, który ustanawia połączenie TCP. Czwarty pakiet to iOS wysyłający do serwera wiadomość Hello Hello klienta TLS, pierwszy krok w konfiguracji połączenia TLS przez to połączenie TCP. Rozebrałem tę wiadomość i wygląda ona dość rozsądnie. W piątym pakiecie serwer po prostu przerywa połączenie (wysyłając RST).

Czy ktoś wie, dlaczego IIS 7.5 robi RST?

Pytanie jest stare, ale zostanie znalezione podczas wyszukiwania. Spędziłem trochę czasu, aby znaleźć rozwiązanie tego samego problemu. Dlatego postanawiam napisać odpowiedź, aby podzielić się moimi wynikami z innymi.

Krótka odpowiedź: nie powinieneś używać IIS Crypto do określania kolejności pakietów szyfrów. Zalecam kliknięcie przycisków „Domyślne”, aby usunąć poprzednio ustawione zamówienie, a następnie użyć zasad grupy („Konfiguracja komputera” \ „Szablony administracyjne” \ „Sieć” \ „Ustawienia konfiguracji SSL”), aby skonfigurować pakiety szyfrów za pomocą zasad lokalnych.

Przyczyną błędu „niezgodność protokołu lub zestawu szyfrów” może być jeden z poniższych :

• twój serwer obsługuje „zły zestaw szyfrów”
• Twój serwer nie obsługuje niektórych pakietów szyfrów, które MUSZĄ być obsługiwane zgodnie ze specyfikacją TLS.
• Twój serwer obsługuje HTTP / 2 i ma niektóre protokoły z czarnej listy nad innymi protokołami, których nie ma na liście . Zazwyczaj wystarczy zmienić kolejność zestawów szyfrów, aby rozwiązać problem.

Dokładna czarna lista może być różna w różnych systemach. W Internecie można znaleźć czarną listę. Na przykład załącznik A do RFC 7540 (Hypertext Transfer Protocol Version 2 (HTTP / 2)) zawiera jedną listę. Szyfr apartamenty są TLS_RSA_WITH_AES_128_CBC_SHAdla TLS 1.2 (patrz tutaj ) oraz TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256i TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256dla TLS 1.3 (patrz tutaj ). TLS_ECDHE_ECDSA_*Są ważne tylko użyć certyfikatu z krzywych eliptycznych. Inny bardzo dobry pakiet szyfrów TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256nie jest jeszcze zaimplementowany przez Microsoft. Dodatkowo możesz rozważyć dodanie przynajmniej TLS_ECDHE_RSA_WITH_AES_256_CBC_SHAdo obsługi połączenia ze starych systemów i TLS_RSA_WITH_AES_128_CBC_SHAdo obsługi bardzo starych systemów (Android 2.3.7, Java 6u45, OpenSSL 0.9.8y) i TLS_RSA_WITH_3DES_EDE_CBC_SHAtylko jeśli potrzebujesz obsługi IE 8 / XP. Możesz na przykład użyć dzisiaj

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

z wyłączonymi TLS 1.0, TLS 1.1, aby mieć większe bezpieczeństwo lub po prostu

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

jeśli potrzebujesz dobrego bezpieczeństwa i najlepszej wydajności.

Możesz na przykład ustawić następujący krótki zestaw pakietów szyfrów, aby rozwiązać problem:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Poniżej zamieszczam przykład konfiguracji w systemie Windows 10. Skonfigurowałem IIS 10, aby uzyskać ocenę A + od Qualys SSL Labs z kluczem RSA 2048 i darmowym certyfikatem SSL z Let's Encrypt .

Wyłączyłem DES 56/56, RC2 128/128, RC2 40/128, RC2 56/128, RC4 128/128, RC4 40/128, RC4 56/128, RC4 64/128, Triple DES 168/168, NULL, MD5, Multi-Protocol Unified Hello, PCT 1.0, SSL 2.0, SSL 3.0 i TLS 1.0 / 1.1 ręcznie w rejestrze (patrz KB245030 ). Wyłączyłem protokoły TLS 1.0 i TLS 1.1 tylko dlatego, że TLS_FALLBACK_SCSV (atak obniżenia wersji) nie można do tej pory zapobiec w IIS, co uniemożliwia uzyskanie oceny A + na www.ssllabs.com . Widzę to jako wadę, ale TLS 1.2 jest obecnie obsługiwany bardzo szeroko. Nawiasem mówiąc, możesz używać DisabledByDefault: 1, ale Enabled: 1dla TLS 1.0 i TLS 1.1. Pomocne może być uruchomienie programu SQL Server 2008/2012 na komputerze. Serwer WWW nie będzie korzystał z TLS 1.0 i TLS 1.1, ale korzysta z SQL Server.

Najważniejszym krokiem, który zajmuje mi dużo czasu i który jest twoim głównym problemem, była konfiguracja zestawów szyfrów. Zrobiłem to używając gpedit.msc. Wybrałem „Konfiguracja komputera” \ „Szablony administracyjne” \ „Sieć” \ „Ustawienia konfiguracji SSL” i skonfigurowałem wartość „Zamówienie zestawu szyfrów SSL” na następujące

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

Powyższa kolejność może nie być optymalna i nie jestem pewien, czy wszystkie powyższe protokoły są obsługiwane w IIS 7.5 (użyłem IIS 10.0 z Windows 10). Niemniej jednak jestem pewien, że twój problem jest związany z listą pakietu szyfrów, ponieważ miałem dokładnie ten sam problem, co opisałeś podczas moich eksperymentów z listą pakietu szyfrów.

W każdym razie, po skonfigurowaniu powyższych ustawień w Grupie Polity i ponownym uruchomieniu komputera (to gpupdate /force /target:computerbyło za mało w moich testach) dostaję oceny A + i następującą listę wyników testów części „Symulacja uzgadniania”:

Widać, że iOS jest z powodzeniem obsługiwany dla następujących klientów:

Safari 6 / iOS 6.0.1
Safari 7 / iOS 7.1
Safari 8 / iOS 8.4
Safari 9 / iOS 9

Klienci, którzy nie obsługują TLS 1.2, wydają mi się teraz nie tak ważni i myślę, że powyższa konfiguracja jest dobrym kompromisem między obsługą starszych klientów a użyciem bezpiecznych protokołów.

Jeśli Twój obraz IIS Crypto jest najnowszy, zachowaj ustawienia bez zmian, ale włącz SHA, Diffie-Hellman i PKCS. Otrzymasz ocenę A, ale pozwolisz na połączenie iOS 8 i niższych.

Walczyłem z tym przez kilka dni. W szczególności łączyłem się z aplikacji iOS za pomocą Xamarin Forms PCL, aby połączyć się z usługą odpoczynku ASP.NET Web Api 2 z uwierzytelnianiem tokenu okaziciela OAuth2.

W końcu zadziałało dla mnie zastosowanie najlepszych praktyk IIS Crypto. Następnie edytuj klucz rejestru ustawiony dla kolejności zestawu szyfrów:

KEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002\Function

Miałem sukces z następującą wartością:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_RC4_128_MD5, TLS_RSA_WITH_DES_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Ostatni został znaleziony przy użyciu Charles Proxy, który automatycznie negocjował TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Doprowadziło mnie to do tego, że połączenia zakończyły się powodzeniem z włączonym Charles Proxy (z zainstalowanymi certyfikatami symulatora), ale w przeciwnym razie zawiodły. Dodanie pakietu użytego podczas negocjacji załatwiło sprawę. Wygląda (?), Że proxy renegocjowało się z moją usługą odpoczynku z czymś, co było obsługiwane przez mój serwer, ale nie klienta iOS.

Należy zauważyć, że wiele zestawów szyfrów uzyskano ze specyfikacji preferowanych pakietów ssllabs dla różnych urządzeń iOS / OSX. Powyższa wartość powinna uzgadniać z wszystkim oprócz IE 6 na XP zgodnie z ssllabs, z oceną A.