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 protokołu TLS (Transport Layer Security) 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ługi 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ądarkach 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 ustalenia, jaka wersja protokołu TLS będzie żądana przez różnych klientów podczas nawiązywania połączenia z Usługi online, jest odwołanie się do symulacji uzgadniania w laboratoriach SSL 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 służące do korelowania ciągu agenta klienta/użytkownika, identyfikatora URI usługi, wersji protokołu TLS i pakietu szyfrowania.
- Dzięki temu rejestrowaniu administratorzy mogą wreszcie ocenić narażenie swoich klientów na słabe protokoły TLS.
SecureScore — aby ułatwić Office 365 administratorom dzierżawy identyfikowanie własnego słabego użycia protokołu TLS, portal SecureScore został skompilowany w celu udostępnienia tych informacji jako obsługa protokołu TLS 1.0 w Office 365 w październiku 2018 r.
Ten portal udostępnia administratorom dzierżawy 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.
Odwiedź stronę https://securescore.microsoft.com/ , aby uzyskać więcej informacji.
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.
Wydano wskazówki dla deweloperów i aktualizacje oprogramowania, aby ułatwić klientom identyfikowanie i eliminowanie zależności platformy .Net ze słabym protokołem TLS: Najlepsze rozwiązania dotyczące protokołu TRANSPORT Layer Security (TLS) z .NET Framework
- FYI: wszystkie aplikacje przeznaczone dla platformy .NET 4.5 lub starszej 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 zostanie 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 i protokołów zabezpieczeń systemu operacyjnego Windows następujące kroki powinny pomóc w zidentyfikowaniu dowolnego zakodowanego na stałe użycia protokołu TLS 1.0 w aplikacjach:
Zidentyfikuj wszystkie wystąpienia elementu AcquireCredentialsHandle(). Pomaga to recenzentom zbliżyć się do bloków kodu, w których protokół TLS może być zakodowany na stałe.
Przejrzyj wszystkie wystąpienia struktur SecPkgContext_SupportedProtocols i SecPkgContext_ConnectionInfo dla zakodowanego na stałe protokołu TLS.
W kodzie natywnym ustaw wszystkie przypisania niezerowe grbitEnabledProtocols na zero. Dzięki temu system operacyjny może używać domyślnej wersji protokołu TLS.
Wyłącz tryb FIPS , jeśli jest włączony z powodu potencjalnego konfliktu z ustawieniami wymaganymi do jawnego wyłączania protokołu TLS 1.0/1.1 w tym dokumencie. Aby uzyskać więcej informacji, zobacz Dodatek B .
Zaktualizuj i ponownie skompiluj wszystkie aplikacje przy użyciu winHTTP hostowanego na serwerze 2012 lub starszym.
Aplikacje zarządzane — ponowne kompilowanie i retarget względem najnowszej wersji .NET Framework
Aplikacje muszą dodać kod do obsługi protokołu TLS 1.2 za pośrednictwem protokołu WinHttpSetOption
Aby obsłużyć wszystkie podstawy, przeskanuj kod źródłowy i pliki konfiguracji usługi online dla poniższych wzorców odpowiadających wyliczanym wartościom typów, które są często używane w przypadku kodowania TLS:
SecurityProtocolType
SSLv2, SSLv23, SSLv3, TLS1, TLS 10, TLS11
WINHTTP_FLAG_SECURE_PROTOCOL_
SP_PROT_
NSStreamSocketSecurityLevel
PROTOCOL_SSL lub PROTOCOL_TLS
Zalecanym rozwiązaniem we wszystkich powyższych przypadkach jest usunięcie opcji wersji protokołu zakodowanego na stałe i odroczenie do domyślnego ustawienia systemu operacyjnego. Jeśli używasz pakietu DevSkim, kliknij tutaj , aby wyświetlić reguły obejmujące powyższe testy, których można użyć z własnym kodem.
Aktualizowanie skryptów Windows PowerShell lub powiązanych ustawień rejestru
Windows PowerShell używa protokołu .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:
Zmodyfikuj omawiany skrypt, aby uwzględnić następujące elementy:
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;
Dodaj klucz rejestru dla całego systemu (np. za pośrednictwem zasad grupy) do dowolnej maszyny, która musi wykonywać 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ół i umożliwi skryptom używanie 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/ponowne tworzenie aplikacji zarządzanych przy użyciu najnowszej wersji programu .Net Framework
Aplikacje korzystające z wersji programu .NET Framework wcześniejszych niż 4.7 mogą mieć ograniczenia, co skutecznie ogranicza obsługę protokołu TLS 1.0 niezależnie od domyślnych ustawień systemu operacyjnego. Aby uzyskać więcej informacji, zapoznaj się z poniższym diagramem i najlepszymi rozwiązaniami dotyczącymi protokołu TRANSPORT Layer Security (TLS) z .NET Framework.
SystemDefaultTLSVersion ma pierwszeństwo przed określaniem wartości docelowej na poziomie aplikacji 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 .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 .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 lub nowszego
Po poprawkach zalecanych 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 podczas tego testowania 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 to 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 ekspresyjny niż w przypadku protokołu TLS 1.2.
- Jeśli produkt negocjuje usługę MTLS z certyfikatem z lokalizacji niestandardowej (poza standardowymi nazwanymi magazynami certyfikatów w systemie Windows), ten kod może wymagać aktualizacji, aby upewnić się, że certyfikat został uzyskany poprawnie.
Należy przejrzeć współzależności usług pod kątem 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 systemu spoza systemu 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 obejmuje następujące elementy:
Przeprowadź skanowanie systemów środowiska produkcyjnego w celu zidentyfikowania systemów operacyjnych, które nie obsługują protokołu TLS 1.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"
Zaktualizuj/ponownie skompiluj aplikacje zgodnie z wymaganiami:
Aplikacje zarządzane
Ponownie skompiluj najnowszą wersję .NET Framework.
Sprawdź, czy dla dowolnego użycia wyliczenia SSLProtocols ustawiono wartość SSLProtocols.None, aby użyć ustawień domyślnych systemu operacyjnego.
Aplikacje WinHTTP — ponowne kompilowanie za pomocą funkcji WinHttpSetOption w celu obsługi protokołu TLS 1.2
Rozpocznij testowanie w środowisku przedprodukcyjnym lub przejściowym ze wszystkimi protokołami zabezpieczeń starszymi niż TLS 1.2 wyłączonym za pośrednictwem rejestru.
Napraw wszystkie pozostałe wystąpienia kodowania TLS, ponieważ występują one 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 tls i zakończeniu aktualizacji systemu operacyjnego/platformy programistycznej należy zdecydować się na wycofanie protokołu TLS 1.0, konieczne będzie koordynowanie z klientami i partnerami:
Wczesne wdrożenie programu TLS 1.0 jest niezbędne 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 polegającym na końcu dysku. Firma Microsoft i partnerzy branżowi podejmują obecnie działania w celu zapewnienia, że cały nasz stos produktów jest domyślnie bezpieczniejszy, od naszych składników systemu operacyjnego i struktur programistycznych aż do aplikacji/usług utworzonych na ich podstawie. Wykonanie zaleceń w tym dokumencie pomoże Przedsiębiorstwu w odpowiednim kursie i dowie się, jakich wyzwań można oczekiwać. Pomoże to również własnym klientom w przygotowaniu 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
Dodatek B: Wycofanie protokołu TLS 1.0/1.1 przy zachowaniu trybu FIPS
Wykonaj poniższe kroki, jeśli sieć wymaga trybu FIPS, ale chcesz również wycofać protokół TLS 1.0/1.1:
Skonfiguruj wersje protokołu TLS za pośrednictwem rejestru, ustawiając wartość "Włączone" na zero dla niechcianych wersji protokołu TLS.
Wyłącz krzywą 25519 (tylko serwer 2016) za pośrednictwem zasady grupy.
Wyłącz wszystkie zestawy szyfrowania przy użyciu algorytmów, które nie są dozwolone przez odpowiednią publikację ze standardu FIPS. W przypadku serwera 2016 (przy założeniu, że ustawienia domyślne obowiązują) oznacza to wyłączenie szyfrów RC4, PSK i NULL.
Współautorzy/Dziękujemy
Mark Cartwright
Bryan Sullivan
Patrick Jungles
Michael Scovetta
Tony Rice
David LeBlanc
Mortimer Cook
Daniel Sommerfeld
Andrei Popov
Michiko Krótki
Justin Burke
Gov Maharaj
Brad Turner
Sean Stevenson