Konfiguracja TLS¶

TLS chroni dane przesyłane przez sieć: między przeglądarką użytkownika a serwerem, między aplikacją mobilną a interfejsem API, a także między komponentami samego systemu. Odpowiada przy tym za dwie różne rzeczy.

Pierwszą jest szyfrowanie, dzięki któremu nikt po drodze nie odczyta ani nie zmieni przesyłanych danych. Jego siła zależy od konfiguracji serwera, czyli od dopuszczonych wersji protokołu i zestawów szyfrów.

Drugą jest potwierdzenie, z kim klient, czyli strona nawiązująca połączenie, naprawdę rozmawia. Służy do tego certyfikat: istotne jest, dla jakiej domeny został wystawiony, kto go podpisał, czy jest wciąż ważny i czy klient w ogóle go sprawdza. Bez tego szyfrowanie zabezpiecza połączenie z kimś, czyjej tożsamości nikt nie potwierdził. Dane mogą wtedy trafić do serwera atakującego, który odczyta je i przekaże dalej do właściwej usługi, a użytkownik nie zauważy różnicy.

Skutki udanego ataku¶

Typowe scenariusze¶

Przestarzałe wersje protokołu¶

Protokoły SSL 2.0, SSL 3.0, TLS 1.0 oraz TLS 1.1 powstały kilkanaście lat temu i nie spełniają dzisiejszych wymagań bezpieczeństwa. Mimo to bywają nadal włączone w konfiguracji serwera, z obawy, że starsze urządzenia nie będą mogły się połączyć. Naraża to wszystkich użytkowników, także tych z aktualną przeglądarką, ponieważ atakujący ingerujący w połączenie może wymusić użycie najsłabszej wersji obsługiwanej przez obie strony.

Słabe zestawy szyfrów¶

Zestaw szyfrów określa, w jaki sposób połączenie jest szyfrowane i jak uzgadniany jest klucz. Serwer ma zwykle włączonych kilkanaście zestawów naraz i zostają wśród nich takie, które dawno przestały być bezpieczne: RC4, z którego da się odtworzyć fragmenty przesyłanych danych, czy 3DES, operujący na zbyt krótkich blokach danych. Zdarzają się też zestawy w ogóle nieszyfrujące (NULL) oraz anonimowe (aNULL), które nie potwierdzają tożsamości serwera i tym samym nie chronią przed podszyciem się pod usługę.

Wygasły certyfikat¶

W praktyce najczęstsza przyczyna awarii związanych z TLS. Przeglądarki wyświetlają wtedy ostrzeżenie, a aplikacje przerywają połączenie, co oznacza przerwę w działaniu usługi, zwykle zauważoną dopiero po zgłoszeniach użytkowników. Wygaśnięcie certyfikatu jest w pełni przewidywalne, więc jego dopuszczenie świadczy o braku automatyzacji i monitoringu, a nie o błędzie technicznym. Najbardziej narażone są certyfikaty odnawiane ręcznie, certyfikaty na urządzeniach sieciowych i w systemach wewnętrznych oraz te w komponentach, o których nikt już nie pamięta.

Niekompletny łańcuch certyfikatów¶

Serwer powinien wysyłać certyfikat usługi razem ze wszystkimi certyfikatami pośrednimi. Ich brak łatwo przeoczyć, ponieważ przeglądarki zwykle potrafią uzupełnić łańcuch samodzielnie. Inne programy w tej samej sytuacji odrzucają połączenie. Strona działa więc u administratora, który ją sprawdza, a części użytkowników nie.

Certyfikat wystawiony na inną nazwę¶

Certyfikat jest wystawiany na konkretne domeny i klient akceptuje go tylko wtedy, gdy domena, z którą się łączy, jest wśród nich wymieniona. Typowe błędy to brak wariantu z przedrostkiem www lub bez niego, dostęp do usługi po adresie IP albo po wewnętrznej nazwie hosta oraz nieporozumienia wokół certyfikatów wieloznacznych: *.example.com nie obejmuje ani example.com, ani a.b.example.com. Użytkownik widzi wtedy ostrzeżenie o tej samej treści co przy prawdziwym ataku.

Certyfikat niezaufany lub samopodpisany¶

Urządzenia sieciowe, panele administracyjne i środowiska testowe korzystają zwykle z domyślnego certyfikatu, wygenerowanego przez sam system. Klient nie ma jak potwierdzić, kto go wystawił, więc wyświetla ostrzeżenie. Taki certyfikat może wygenerować każdy, również atakujący, więc nie chroni przed podszyciem się pod usługę.

Wyłączona weryfikacja certyfikatu po stronie klienta¶

Weryfikację wyłącza się zwykle tymczasowo, żeby obejść błąd certyfikatu i uruchomić usługę, po czym ustawienie zostaje na lata. Dotyczy to zarówno skryptów i aplikacji, jak i opcji ignorowania błędów certyfikatu w narzędziach monitoringu.

Klient <--- szyfrowane TLS ---> Atakujący <--- szyfrowane TLS ---> Serwer

Słabe algorytmy podpisu certyfikatu¶

Certyfikaty podpisane algorytmem SHA-1 lub MD5 oraz klucze RSA krótsze niż 2048 bitów nie zapewniają dziś wystarczającej ochrony i są odrzucane przez współczesne przeglądarki.

Niewłaściwa ochrona klucza prywatnego¶

Kopie klucza prywatnego trafiają czasem do repozytoriów kodu, kopii zapasowych czy obrazów maszyn wirtualnych, a jeden klucz bywa współdzielony przez wiele systemów. Jego ujawnienie pozwala podszyć się pod usługę, a potencjalnie także odszyfrować wcześniej zarejestrowany ruch.

Rekomendacje¶