Zmieniający się świat szyfrowania: wdrożenia TLS w 2020 roku

Prywatność w Internecie nie polega już tylko na trzymaniu danych z dala od wścibskich oczu. Kluczową rolę odgrywa szyfrowanie, które nieustannie się rozwija i zmienia. Na znaczeniu zyskują protokoły kryptograficzne, takie jak Transport Layer Security (TLS), dawniej wykorzystywane wyłącznie na stronach logowania i płatności, które umożliwiają uwierzytelnianie i poufną komunikację w punktach końcowych. Kwestie szyfrowania zdecydowanie powinny się znaleźć w obszarze zainteresowania biznesu, aby mógł on zapewnić bezpiecznie wdrażanie i utrzymywanie witryn internetowych  przez cały okres ich użytkowania.

W ciągu ostatnich dwóch lat standardy TLS zostały zaktualizowane. Przeglądarki będą wkrótce blokować stare i słabe implementacje tego protokołu, takie jak TLS 1.0 i 1.1. Wprowadzane są kolejne podobne rozwiązania, które będą także blokować inne niezabezpieczone protokoły będące ciągle w powszechnym użyciu. Firmom może być trudno szybko reagować na tak dynamiczne zmiany, a jeszcze na początku ubiegłego roku specjaliści ds. bezpieczeństwa odkryli pierwszą w historii próbkę złośliwego oprogramowania wykorzystującą nowy protokół szyfrowania Domain Name System, DNS-over-HTTPS (DoH).

Dotrzymywanie kroku nowym standardom

Firmy na ogół rozumieją korzyści wynikające z aktualizacji TLS i doceniają zmiany. Potwierdza to najnowszy raport F5 Labs Telemetria TLS, który wskazuje, że prawie jedna trzecia z miliona witryn sklasyfikowanych w rankingu Alexy „Top one milion sites” akceptuje właśnie połączenia TLS 1.3. Ma to swoje uzasadnienie biznesowe. Większość popularnych przeglądarek internetowych już obsługuje nowy standard, zapewniając tym samym wyższy poziom bezpieczeństwa i wydajności użytkownikom.

Jednak przyjęcie najnowszego protokołu TLS nie jest jeszcze rozwiązaniem dla wszystkich.

Takim przypadkiem są firmy, które powinny rozważyć całkowite wyłączenie wymiany kluczy RSA[1], usuwając zestawy szyfrów, które je oferują. Przywołane już badanie F5 wykazało, że ponad jedna trzecia najpopularniejszych witryn internetowych na świecie nadal utrzymuje RSA – algorytm kryptograficzny z kluczem publicznym – na liście używanych algorytmów. Dzieje się tak, mimo że specjaliści ds. bezpieczeństwa nieustannie znajdują sposoby skutecznych ataków na RSA. Co więcej, wśród niedoskonałości w tym rozwiązaniu znajduje się 19-letnia luka ROBOT, która ciągle jeszcze funkcjonuje jako podatność w ponad 2% najpopularniejszych witryn na świecie.

Badacze bezpieczeństwa często odkrywają luki w bibliotekach TLS i innych podobnych rozwiązaniach. Dlatego organizacje powinny upewnić się, że mają wiedzę (alerty), czy i kiedy ich serwer internetowy, moduł równoważenia obciążenia i kontroler dostarczania aplikacji aktualizują swoje stosy TLS. Równie istotne pozostaje szybkie łatanie luk.

Certyfikacja DNS

Ze względu na to, że dowolny ośrodek certyfikacji (Certificate Authority – CA) może utworzyć certyfikat dla każdej domeny w sieci, warto ograniczyć uprawnienia certyfikatów do najbardziej zaufanych urzędów, organizacji. Zapewnia się to poprzez utworzenie rekordów DNS Certificate Authority Authorization (CAA).

Zabezpieczony HTTPS

Ponadto, dodatkową warstwę bezpieczeństwa uzyskuje się poprzez zastosowanie w aplikacjach internetowych nagłówka HTTP Strict Transport Security (HSTS[2]), za sprawą którego przeglądarki będą próbować załadować witrynę tylko przez zabezpieczony protokół HTTPS. To ważny element zabezpieczeń, który może pomóc w zapobieganiu atakom sieciowym wymuszającym załadowanie niezabezpieczonych stron i umożliwiającym hakerom podsłuchiwanie, przepisywanie i przekierowywanie ruchu sieciowego.

Nawet po utworzeniu rekordów DNS CAA, trzeba też monitorować powstające domeny. Oszuści rzadko próbują bowiem utworzyć certyfikat dla istniejącej domeny jak np. „mybank.com”. Tworzą certyfikaty dla domen, których są właścicielami, używając nazwy marki „mybank” jako widocznej subdomeny np. „mybank.attacker.com”.

Na szczęście monitoring domen jest możliwy. Za każdym razem, gdy jakikolwiek urząd certyfikacji tworzy certyfikat, jest on rejestrowany w globalnie rozproszonej bazie danych (dziennikach Certificate Transparency - CT). Monitorowanie CT pozwala pozyskiwać informacje o tym, pod jakie domeny lub marki podszywają się cyberprzestępcy.

Wraz z globalnym upowszechnieniem HTTPS zwiększa się też liczba szyfrów, kluczy i certyfikatów do zarządzania. Rosnącemu tempu zmian i wdrażania sprzyja też łączenie wskazanych wyżej narzędzi z powszechniejącą metodologią DevOps.

Konfigurowanie protokołu HTTPS musi przebiegać podobnie jak podczas integracji narzędzi bezpieczeństwa i testów w łańcuch automatyzacji (automation toolchain).

Trzeba przyjrzeć się możliwościom orkiestracji tworzenia certyfikatów cyfrowych i opracowania wewnętrznych zasad określających standardy jak np. minimalna długość klucza czy zestawy szyfrów. Automatyzacja aktualizacji certyfikatów pomoże również w zapewnieniu ciągłości usług, ponieważ certyfikaty, które mają wygasnąć są automatycznie odnawiane.

Usuwanie luk w zabezpieczeniach TLS

Niestety nawet przy poprawnym wdrożeniu TLS, ciągle możemy mieć do czynienia z innymi lukami bezpieczeństwa w obszarze prywatności. Jednym ze sposobów wypełnienia tych luk są protokoły takie jak DNS-over-HTTPS (DoH). Poprawiają one poziom prywatności użytkowników Internetu, jednak mogą jednocześnie utrudniać identyfikację i blokowanie złośliwego ruchu zespołom cyberochrony. Z tego powodu, czasem konieczne jest nawet wyłączenie protokołów DoH w sieciach korporacyjnych lub wdrożenie dla użytkowników wewnętrznych usług, które współpracują z internetowym serwerem proxy i pomagają odfiltrować niechciany ruch.

Trzeba jednak pamiętać, że nawet najlepsze wdrożenie TLS nie może powstrzymać iniekcji złośliwego kodu (malware) lub przejęcia kodu przez obce skrypty. Ograniczenia i luki protokołu HTTPS warto więc dobrze rozpoznać i zrozumieć.

Jedno jest pewne: szyfrowanie nieustannie ewoluuje. Rośnie długość kluczy, certyfikaty stają się zautomatyzowane, rządy tworzą regulacje i nakładają ograniczenia, a do tego pojawiają się nowe protokoły. To właśnie te ciągłe zmiany zwiększają ryzyko dla wielu organizacji i ich klientów. Słabe wdrożenie TLS nie pozostanie niezauważone przez hakerów, organy regulacyjne, czy firmy ubezpieczeniowe oceniające zagrożenia cyberbezpieczeństwa.

David Warburton, Senior Threat Research Evangelist, F5 Labs

[1] Algorytm Rivesta-Shamira-Adlemana – powstały w latach 70. XX w. i dotąd jeden z najpopularniejszych asymetrycznych algorytmów kryptograficznych z kluczem publicznym

[2] mechanizm bezpieczeństwa sieci chroniący przed atakami jak wymuszone zmniejszenie poziomu protokołu i przechwytywanie sesji.