Rozwiązywanie problemu z protokołem TLS 1.0, wydanie drugie

Autor: Andrew Marshall
Główny menedżer programu zabezpieczeń
Microsoft Corporation

Streszczenie

Ten dokument przedstawia najnowsze wskazówki dotyczące szybkiego identyfikowania i usuwania zależności protokołu Transport Layer Security (TLS) w wersji 1.0 w oprogramowaniu opartym na systemach operacyjnych firmy Microsoft, postępując zgodnie ze szczegółowymi informacjami na temat zmian produktów i nowych funkcji dostarczanych przez firmę Microsoft w celu ochrony własnych klientów i usług online. Ma on być używany jako punkt wyjścia do tworzenia planu migracji do środowiska sieciowego tls 1.2+. Chociaż omówione tutaj rozwiązania mogą przenosić i pomagać w usuwaniu użycia protokołu TLS 1.0 w systemach operacyjnych innych niż Microsoft lub bibliotekach kryptograficznych, nie są one przedmiotem tego dokumentu.

TLS 1.0 to protokół zabezpieczeń zdefiniowany po raz pierwszy w 1999 roku do ustanawiania kanałów szyfrowania za pośrednictwem sieci komputerowych. Firma Microsoft obsługuje ten protokół od systemu Windows XP/Server 2003. Chociaż nie jest już domyślnym protokołem zabezpieczeń używanym przez nowoczesne systemy operacyjne, protokół TLS 1.0 jest nadal obsługiwany w celu zapewnienia zgodności z poprzednimi wersjami. Zmieniające się wymagania prawne, a także nowe luki w zabezpieczeniach w protokole TLS 1.0 zapewniają korporacjom zachętę do całkowitego wyłączenia protokołu TLS 1.0.

Firma Microsoft zaleca klientom wyprzedzanie tego problemu przez usunięcie zależności protokołu TLS 1.0 w swoich środowiskach i wyłączenie protokołu TLS 1.0 na poziomie systemu operacyjnego, jeśli to możliwe. Biorąc pod uwagę czas obsługi protokołu TLS 1.0 przez branżę oprogramowania, zdecydowanie zaleca się, aby każdy plan wycofania protokołu TLS 1.0 zawierał następujące elementy:

  • Analiza kodu w celu znalezienia/naprawienia zakodowanych na stałe wystąpień protokołów zabezpieczeń TLS 1.0 lub starszych.

  • Skanowanie punktów końcowych sieci i analiza ruchu w celu zidentyfikowania systemów operacyjnych przy użyciu protokołów TLS 1.0 lub starszych.

  • Pełne testowanie regresji za pośrednictwem całego stosu aplikacji z wyłączonym protokołem TLS 1.0.

  • Migracja starszych systemów operacyjnych i bibliotek programistycznych/struktur do wersji, które mogą domyślnie negocjować protokół TLS 1.2.

  • Testowanie zgodności w systemach operacyjnych używanych przez firmę w celu zidentyfikowania problemów z obsługą protokołu TLS 1.2.

  • Koordynacja z własnymi partnerami biznesowymi i klientami w celu powiadamiania ich o przeniesieniu do przestarzałego protokołu TLS 1.0.

  • Zrozumienie, którzy klienci mogą już nie być w stanie nawiązać połączenia z serwerami po wyłączeniu protokołu TLS 1.0.

Celem tego dokumentu jest przedstawienie zaleceń, które mogą pomóc w usunięciu blokad technicznych w celu wyłączenia protokołu TLS 1.0, jednocześnie zwiększając wgląd w wpływ tej zmiany na własnych klientów. Wykonanie takich badań może pomóc zmniejszyć wpływ na firmę następnej luki w zabezpieczeniach protokołu TLS 1.0. Na potrzeby tego dokumentu odwołania do wycofania protokołu TLS 1.0 obejmują również protokół TLS 1.1.

Deweloperzy oprogramowania dla przedsiębiorstw mają strategiczną potrzebę przyjęcia bardziej bezpiecznych i elastycznych rozwiązań (inaczej znanych jako Crypto Agiley), aby poradzić sobie z przyszłymi zabezpieczeniami protokołu zabezpieczeń. Chociaż ten dokument proponuje elastyczne rozwiązania do eliminacji kodowania TLS, szersze rozwiązania zwinności kryptograficznej wykraczają poza zakres tego dokumentu.

Bieżąca wersja implementacji protokołu TLS 1.0 firmy Microsoft

Implementacja protokołu TLS 1.0 firmy Microsoft jest wolna od znanych luk w zabezpieczeniach. Ze względu na potencjał przyszłych ataków na obniżenie poziomu protokołu i innych luk w zabezpieczeniach protokołu TLS 1.0, które nie są specyficzne dla implementacji firmy Microsoft, zaleca się, aby zależności od wszystkich protokołów zabezpieczeń starszych niż TLS 1.2 zostały usunięte, jeśli to możliwe (TLS 1.1/1.0/ SSLv3/SSLv2).

Podczas planowania tej migracji do protokołu TLS 1.2 lub nowszego deweloperzy i administratorzy systemu powinni mieć świadomość możliwości kodowania wersji protokołu w aplikacjach opracowanych przez pracowników i partnerów. Hardcoding oznacza, że wersja protokołu TLS jest stała dla wersji nieaktualnej i mniej bezpiecznej niż nowsze wersje. Wersje protokołu TLS nowsze niż wersja zakodowana na stałe nie mogą być używane bez modyfikowania danego programu. Nie można rozwiązać tej klasy problemu bez zmian kodu źródłowego i wdrożenia aktualizacji oprogramowania. Hardcoding wersji protokołu był powszechny w przeszłości na potrzeby testowania i obsługi, ponieważ wiele różnych przeglądarek i systemów operacyjnych miało różne poziomy obsługi protokołu TLS.

Zapewnianie obsługi protokołu TLS 1.2 w wdrożonych systemach operacyjnych

Wiele systemów operacyjnych ma nieaktualne wartości domyślne wersji protokołu TLS lub limity obsługi, które należy uwzględnić. Użycie systemu Windows 8/Server 2012 lub nowszego oznacza, że protokół TLS 1.2 będzie domyślnym protokołem zabezpieczeń:

Rysunek 1. Obsługa protokołu zabezpieczeń według wersji systemu operacyjnego

System operacyjny Windows SSLv2 SSLv3 TLS 1.0 TLS 1.1 TLS 1.2
Windows Vista Enabled (Włączony) Enabled (Włączony) Domyślny Nieobsługiwane Nieobsługiwane
Windows Server 2008 Enabled (Włączony) Enabled (Włączony) Domyślny Wyłączone* Wyłączone*
Windows 7 (WS2008 R2) Enabled (Włączony) Enabled (Włączony) Domyślny Wyłączone* Wyłączone*
Windows 8 (WS2012) Disabled Enabled (Włączony) Enabled (Włączony) Enabled (Włączony) Domyślny
Windows 8.1 (WS2012 R2) Disabled Enabled (Włączony) Enabled (Włączony) Enabled (Włączony) Domyślny
Windows 10 Disabled Enabled (Włączony) Enabled (Włączony) Enabled (Włączony) Domyślny
Windows Server 2016 Nieobsługiwane Disabled Enabled (Włączony) Enabled (Włączony) Domyślny

*Protokół TLS 1.1/1.2 można włączyć w systemie Windows Server 2008 za pośrednictwem tego opcjonalnego pakietu Windows Update.

Aby uzyskać więcej informacji na temat wycofywania protokołu TLS 1.0/1.1 w programie IE/Edge, zobacz Modernizowanie połączeń TLS w przeglądarce Microsoft Edge i Internet Explorer 11, zmiany wpływające na zgodność witryny przychodzące do przeglądarki Microsoft Edge i wyłączanie protokołu TLS/1.0 i TLS/1.1 w nowej przeglądarce Edge

Szybkim sposobem określenia, jaka wersja protokołu TLS będzie żądana przez różnych klientów podczas nawiązywania połączenia z usługami online, jest odwołanie się do symulacji uzgadniania w laboratoriach SSL Firmy Qualys. Ta symulacja obejmuje kombinacje systemu operacyjnego/przeglądarki klienta w różnych producentach. Zobacz dodatek A na końcu tego dokumentu, aby uzyskać szczegółowy przykład przedstawiający wersje protokołu TLS wynegocjowane przez różne symulowane kombinacje systemu operacyjnego/przeglądarki klienta podczas nawiązywania połączenia z www.microsoft.com.

Jeśli jeszcze nie zostało to ukończone, zdecydowanie zaleca się przeprowadzenie spisu systemów operacyjnych używanych przez przedsiębiorstwo, klientów i partnerów (te ostatnie za pośrednictwem komunikacji/komunikacji lub co najmniej kolekcji ciągów HTTP User-Agent). Ten spis można dodatkowo uzupełnić analizą ruchu na brzegu sieci przedsiębiorstwa. W takiej sytuacji analiza ruchu przyniesie pomyślne wynegocjowanie wersji protokołu TLS przez klientów/partnerów łączących się z usługami, ale sam ruch pozostanie zaszyfrowany.

Ulepszenia inżynieryjne firmy Microsoft w celu wyeliminowania zależności protokołu TLS 1.0

Od wersji 1 tego dokumentu firma Microsoft wysłała szereg aktualizacji oprogramowania i nowych funkcji w obsłudze wycofania protokołu TLS 1.0. Są one następujące:

  • Niestandardowe rejestrowanie usług IIS w celu skorelowania ciągu agenta klienta/agenta użytkownika, identyfikatora URI usługi, wersji protokołu TLS i pakietu szyfrowania.

    • Dzięki temu rejestrowaniu administratorzy mogą wreszcie kwantyfikować narażenie swoich klientów na słaby protokół TLS.
  • SecureScore — aby ułatwić administratorom dzierżawy usługi Office 365 zidentyfikowanie własnego słabego użycia protokołu TLS, portal SecureScore został utworzony w celu udostępnienia tych informacji jako obsługa protokołu TLS 1.0 w usłudze Office 365 w październiku 2018 r.

    • Ten portal udostępnia administratorom dzierżawy usługi Office 365 cenne informacje potrzebne do skontaktowania się z własnymi klientami, którzy mogą nie wiedzieć o własnych zależnościach protokołu TLS 1.0.

    • Aby uzyskać więcej informacji, odwiedź stronę https://securescore.microsoft.com/ .

  • Aktualizacje programu .Net Framework w celu wyeliminowania trwałego kodowania na poziomie aplikacji i zapobiegania dziedziczeniu struktury zależności protokołu TLS 1.0.

  • Wskazówki dla deweloperów i aktualizacje oprogramowania zostały wydane, aby ułatwić klientom identyfikowanie i eliminowanie zależności platformy .Net w przypadku słabego protokołu TLS: Najlepsze rozwiązania dotyczące protokołu TRANSPORT Layer Security (TLS) za pomocą programu .NET Framework

    • FYI: wszystkie aplikacje przeznaczone dla platformy .NET 4.5 lub nowszej prawdopodobnie będą musiały zostać zmodyfikowane w celu obsługi protokołu TLS 1.2.
  • Protokół TLS 1.2 został przywrócony do systemu Windows Server 2008 z dodatkiem SP2 i XP POSReady 2009 , aby ułatwić klientom korzystanie ze starszych zobowiązań.

  • Więcej ogłoszeń zostanie ogłoszonych na początku 2019 r. i przekazanych w kolejnych aktualizacjach tego dokumentu.

Znajdowanie i naprawianie zależności protokołu TLS 1.0 w kodzie

W przypadku produktów korzystających z bibliotek kryptograficznych systemu operacyjnego Windows i protokołów zabezpieczeń następujące kroki powinny pomóc zidentyfikować zakodowane na stałe użycie protokołu TLS 1.0 w aplikacjach:

  1. Zidentyfikuj wszystkie wystąpienia klasy AcquireCredentialsHandle(). Pomaga to recenzentom zbliżyć się do bloków kodu, w których protokół TLS może być zakodowany na stałe.

  2. Przejrzyj wszystkie wystąpienia struktur SecPkgContext_SupportedProtocols i SecPkgContext_ConnectionInfo pod kątem zakodowanego na stałe protokołu TLS.

  3. W kodzie natywnym ustaw wszystkie niezerowe przypisania grbitEnabledProtocols na zero. Dzięki temu system operacyjny może używać domyślnej wersji protokołu TLS.

  4. Wyłącz tryb FIPS , jeśli jest włączony z powodu potencjalnego konfliktu z ustawieniami wymaganymi do jawnego wyłączenia protokołu TLS 1.0/1.1 w tym dokumencie. Aby uzyskać więcej informacji, zobacz dodatek B .

  5. Zaktualizuj i ponownie skompiluj wszystkie aplikacje przy użyciu winHTTP hostowanego na serwerze 2012 lub starszym.

    1. Aplikacje zarządzane — ponowne kompilowanie i retarget względem najnowszej wersji programu .NET Framework

    2. Aplikacje muszą dodać kod do obsługi protokołu TLS 1.2 za pośrednictwem protokołu WinHttpSetOption

  6. Aby pokryć wszystkie podstawy, przeskanuj pliki konfiguracji kodu źródłowego i usługi online dla wzorców poniżej odpowiadających wyliczonych wartości typów powszechnie używanych w hardkodowaniu TLS:

    1. SecurityProtocolType

    2. SSLv2, SSLv23, SSLv3, TLS1, TLS 10, TLS11

    3. WINHTTP_FLAG_SECURE_PROTOCOL_

    4. SP_PROT_

    5. NSStreamSocketSecurityLevel

    6. PROTOCOL_SSL lub PROTOCOL_TLS

Zalecane rozwiązanie we wszystkich powyższych przypadkach polega na usunięciu wyboru wersji protokołu zakodowanego na stałe i odroczenia do domyślnego ustawienia systemu operacyjnego. Jeśli używasz metodyki DevSkim, kliknij tutaj , aby wyświetlić reguły obejmujące powyższe testy, których możesz użyć z własnym kodem.

Program Windows PowerShell używa programu .NET Framework 4.5, który nie zawiera protokołu TLS 1.2 jako dostępnego protokołu. Aby obejść ten problem, dostępne są dwa rozwiązania:

  1. Zmodyfikuj podany skrypt, aby uwzględnić następujące elementy:

    [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;
    
  2. Dodaj klucz rejestru dla całego systemu (np. za pośrednictwem zasad grupy) do dowolnej maszyny, która musi nawiązać połączenia TLS 1.2 z aplikacji .NET. Spowoduje to, że platforma .NET będzie używać wersji protokołu TLS "System Default", która dodaje protokół TLS 1.2 jako dostępny protokół, a skrypty będą mogły korzystać z przyszłych wersji protokołu TLS, gdy system operacyjny je obsługuje. (np. TLS 1.3)

    reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:64

    reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:32

Rozwiązania (1) i (2) wykluczają się wzajemnie, co oznacza, że nie muszą być wdrażane razem.

Ponowne kompilowanie/retarget zarządzanych aplikacji przy użyciu najnowszej wersji programu .Net Framework

Aplikacje korzystające z programu .NET Framework w wersji wcześniejszej niż 4.7 mogą mieć ograniczenia, które skutecznie ograniczają obsługę protokołu TLS 1.0 niezależnie od podstawowych ustawień domyślnych systemu operacyjnego. Aby uzyskać więcej informacji, zapoznaj się z poniższym diagramem i najlepszymi rozwiązaniami dotyczącymi zabezpieczeń warstwy transportu (TLS) w programie .NET Framework .

Rebuild managed applications

SystemDefaultTLSVersion ma pierwszeństwo przed określaniem wartości docelowej na poziomie aplikacji dla wersji protokołu TLS. Zalecanym najlepszym rozwiązaniem jest zawsze odroczenie domyślnej wersji protokołu TLS systemu operacyjnego. Jest to również jedyne rozwiązanie kryptograficzne, które umożliwia aplikacjom korzystanie z przyszłej obsługi protokołu TLS 1.3.

Jeśli używasz starszych wersji programu .NET Framework, takich jak 4.5.2 lub 3.5, domyślnie aplikacja będzie używać starszych i niezalecanych protokołów, takich jak SSL 3.0 lub TLS 1.0. Zdecydowanie zaleca się uaktualnienie do nowszych wersji programu .NET Framework, takich jak .NET Framework 4.6 lub ustawienie odpowiednich kluczy rejestru dla polecenia "UseStrongCrypto".

Testowanie przy użyciu protokołu TLS 1.2+

Zgodnie z poprawkami zalecanymi w powyższej sekcji produkty powinny być testowane regresją pod kątem błędów negocjacji protokołu i zgodności z innymi systemami operacyjnymi w przedsiębiorstwie.

  • Najczęstszym problemem w tym testowaniu regresji jest niepowodzenie negocjacji PROTOKOŁU TLS z powodu próby połączenia klienta z systemu operacyjnego lub przeglądarki, która nie obsługuje protokołu TLS 1.2.

    • Na przykład klient Vista nie będzie negocjować protokołu TLS z serwerem skonfigurowanym dla protokołu TLS 1.2 lub nowszego, ponieważ maksymalna obsługiwana wersja protokołu TLS systemu Vista wynosi 1.0. Ten klient powinien zostać uaktualniony lub zlikwidowany w środowisku TLS 1.2 lub nowszym.
  • Produkty korzystające z wzajemnego uwierzytelniania TLS opartego na certyfikatach mogą wymagać dodatkowego testowania regresji, ponieważ kod wyboru certyfikatu skojarzony z protokołem TLS 1.0 był mniej wyraźny niż w przypadku protokołu TLS 1.2.

    • Jeśli produkt negocjuje usługę MTLS z certyfikatem z lokalizacji innej niż standardowa (poza standardowymi nazwanymi magazynami certyfikatów w systemie Windows), ten kod może wymagać aktualizacji, aby upewnić się, że certyfikat jest uzyskiwany poprawnie.
  • Należy przejrzeć współzależności usług w przypadku problemów.

    • Wszelkie usługi, które współdziałająz 3 usługami rd-party, powinny przeprowadzać dodatkowe testy międzyoperacyjne z tymi 3 stronamird .

    • Wszystkie aplikacje inne niż Windows lub systemy operacyjne serwera w użyciu wymagają badania / potwierdzenia, że mogą obsługiwać protokół TLS 1.2. Skanowanie jest najprostszym sposobem ustalenia tego.

Prosta strategia testowania tych zmian w usłudze online składa się z następujących elementów:

  1. Przeprowadź skanowanie systemów środowiska produkcyjnego w celu zidentyfikowania systemów operacyjnych, które nie obsługują protokołu TLS 1.2.

  2. Skanuj kod źródłowy i pliki konfiguracji usługi online dla zakodowanego na stałe protokołu TLS zgodnie z opisem w temacie "Znajdowanie i naprawianie zależności protokołu TLS 1.0 w kodzie"

  3. Zaktualizuj/ponownie skompiluj aplikacje zgodnie z wymaganiami:

    1. Aplikacje zarządzane

      1. Ponownie skompiluj najnowszą wersję programu .NET Framework.

      2. Sprawdź, czy dla wyliczenia SSLProtocols ustawiono wartość SSLProtocols.None , aby używać ustawień domyślnych systemu operacyjnego.

    2. Aplikacje WinHTTP — ponowne kompilowanie za pomocą platformy WinHttpSetOption w celu obsługi protokołu TLS 1.2

  4. Rozpocznij testowanie w środowisku przedprodukcyjnym lub przejściowym ze wszystkimi protokołami zabezpieczeń starszymi niż TLS 1.2 wyłączonym za pośrednictwem rejestru.

  5. Napraw wszystkie pozostałe wystąpienia hardcoding protokołu TLS podczas testowania. Ponownie wdróż oprogramowanie i wykonaj nowy przebieg testu regresji.

Powiadamianie partnerów o planach wycofania protokołu TLS 1.0

Po zakończeniu kodowania za pomocą protokołu TLS i zakończeniu aktualizacji systemu operacyjnego/platformy programistycznej należy zdecydować się na wycofanie protokołu TLS 1.0, konieczne będzie koordynowanie się z klientami i partnerami:

  • Wczesny dostęp partnera/klienta jest niezbędny do pomyślnego wdrożenia wycofywania protokołu TLS 1.0. Co najmniej powinno to obejmować wpisy w blogu, oficjalne dokumenty lub inną zawartość internetową.

  • Partnerzy muszą ocenić własną gotowość protokołu TLS 1.2 za pośrednictwem inicjatyw związanych z systemem operacyjnym/skanowaniem kodu/testowaniem regresji opisanym w powyższych sekcjach.

Podsumowanie

Usuwanie zależności protokołu TLS 1.0 jest skomplikowanym problemem, który polega na końcu dysku. Firma Microsoft i partnerzy branżowi podejmują obecnie działania w celu zapewnienia, że cały stos produktów jest domyślnie bardziej bezpieczny, od naszych składników systemu operacyjnego i struktur programistycznych do aplikacji/usług opartych na nich. Zgodnie z zaleceniami podanymi w tym dokumencie pomoże Twojemu przedsiębiorstwu w odpowiednim kursie i dowiesz się, jakie wyzwania należy oczekiwać. Pomoże to również własnym klientom przygotować się do przejścia.

Dodatek A: Symulacja uzgadniania dla różnych klientów łączących się z www.microsoft.com, dzięki uprzejmości SSLLabs.com

Results of Handshake Simulation

Dodatek B: Wycofanie protokołu TLS 1.0/1.1 podczas zachowywania trybu FIPS

Wykonaj poniższe kroki, jeśli sieć wymaga trybu FIPS, ale chcesz również wycofać protokół TLS 1.0/1.1:

  1. Skonfiguruj wersje protokołu TLS za pośrednictwem rejestru, ustawiając wartość "Włączone" na zero dla niechcianych wersji protokołu TLS.

  2. Wyłącz krzywą 25519 (tylko serwer 2016) za pośrednictwem zasad grupy.

  3. Wyłącz wszystkie zestawy szyfrowania przy użyciu algorytmów, które nie są dozwolone przez odpowiednią publikację FIPS. W przypadku serwera 2016 (przy założeniu, że ustawienia domyślne są obowiązujące) oznacza to wyłączenie szyfrów RC4, PSK i NULL.

Współautorzy/Dzięki

Mark Cartwright
Bryan Sullivan
Patrick Jungles
Michael Scovetta
Tony Rice
David LeBlanc
Mortimer Cook
Daniel Sommerfeld
Andrei Popov
Michiko Short
Justin Burke
Gov Maharaj
Brad Turner
Sean Stevenson