Szyfrowanie i ruch szyfrowany
40 pytań o temat: Szyfrowanie i ruch szyfrowany, prostym językiem: co sprawdzić, co pokazuje NetSenX i czego czujnik nie widzi.
Tak, na podstawie metadanych — zaszyfrowany ruch nigdy nie jest odszyfrowywany. NetSenX analizuje metadane przepływów i kilka pól protokołów — czas, wolumen, cele połączeń i handshake TLS — dzięki czemu beaconing i nietypowe transfery danych są widoczne bez łamania szyfrowania i bez czytania treści.
Tak, na podstawie metadanych. Czas, wolumen, cele połączeń i handshake TLS pozostają widoczne, gdy treść jest zaszyfrowana, więc beaconing do serwera C2 i nietypowe transfery danych da się wykryć bez łamania szyfrowania. Niewidoczna pozostaje treść sesji.
Metadane przepływu (kto z kim się łączy, kiedy, jak często i ile danych przepływa) oraz kilka pól protokołów: nazwę serwera i parametry z handshake'u TLS oraz odpowiedzi na zapytania DNS. NetSenX nigdy nie odszyfrowuje sesji i nie odczytuje jej zaszyfrowanej treści.
W przypadku wielu z nich nie. Kto z kim się łączy, kiedy, jak często i ile danych przesyła, razem z nieszyfrowanym handshake'iem TLS i odpowiedziami DNS, pozostaje widoczne bez deszyfrowania. To wystarcza, by zobaczyć beaconing C2, skanowanie, ruch lateralny między hostami wewnętrznymi i nietypowe wysyłki, czyli kroki, które większość włamań wykonuje, zanim wyrządzi szkody. Deszyfrowanie jest potrzebne, by zobaczyć treść, na przykład złośliwy plik w pobieranym archiwum albo tekst polecenia, i ma swoje koszty: proxy przechwytujące, które przechowuje klucze i odszyfrowane dane, firmowy certyfikat na każdym zarządzanym urządzeniu, aplikacje, które przestają działać, pytania o prywatność i rolę przedstawicieli pracowników oraz martwe pola na urządzeniach niezarządzanych. Wiele firm więcej zyskuje na ochronie punktów końcowych dla plików i procesów na każdym komputerze oraz detekcji sieciowej dla zachowania wszystkich urządzeń. NetSenX nigdy nie deszyfruje ruchu: podstawowe detekcje działają w każdym planie, a odciski TLS od planu Starter tam, gdzie agent przechwytuje pakiety.
Odszyfrowanie daje wgląd w treść, ale oznacza utrzymywanie punktu przechwytywania, który przechowuje klucze, instalację certyfikatu przechwytującego na każdym urządzeniu i przetwarzanie odszyfrowanych treści, które mogą zawierać dane osobowe. Od TLS 1.3 pasywny sensor nie odszyfruje już sesji za pomocą kopii klucza prywatnego serwera.
Więcej, niż się zwykle zakłada. Aby sprawdzać HTTPS, zapora lub proxy kończy każde połączenie, deszyfruje je, analizuje i otwiera nowe szyfrowane połączenie z prawdziwym serwerem, przedstawiając własny certyfikat podpisany firmowym certyfikatem głównym zainstalowanym na każdym zarządzanym urządzeniu. Skutki uboczne: aplikacje z przypinaniem certyfikatów, wiele mechanizmów aktualizacji, część aplikacji bankowych i medycznych oraz fragmenty usług chmurowych odrzucają podstawiony certyfikat, więc listy wyjątków stale rosną; urządzeń niezarządzanych, gości i maszyn w ogóle nie da się sprawdzić; proxy staje się jednym miejscem przechowującym odszyfrowany ruch, także dane osobowe, co rodzi pytania o RODO i rolę przedstawicieli pracowników; starsze proxy mogą nie obsługiwać nowszych funkcji TLS ani nowych hybrydowych grup postkwantowych i po cichu osłabiać połączenia; a inspekcja kosztuje wydajność. Nadal ma swoje miejsce, na przykład do skanowania pobieranych plików na zarządzanych laptopach. Wiele zagrożeń widać jednak i bez niej. Takie podejście przyjął NetSenX: nigdy nie deszyfruje i pracuje na metadanych oraz nieszyfrowanym handshake'u.
Tylko na tych częściach, które nie są zaszyfrowane, chyba że deszyfrujesz. Głęboka inspekcja pakietów (DPI) oznacza czytanie poza nagłówkami, w treści pakietu. W TLS treść jest zaszyfrowana, więc klasyczne sygnatury szukające złośliwego pliku lub polecenia w strumieniu przestają pasować. Czytelne pozostają nieszyfrowane wiadomości handshake'u, z wersją TLS, wyborem szyfru i wymiany kluczy, odciskiem klienta i zwykle nazwą serwera, oraz odpowiedzi DNS poprzedzające połączenie. W połączeniu z metadanymi przepływów, czyli kto, kiedy, jak często i ile, to wystarcza do wielu detekcji: beaconingu C2, skanowania, ruchu lateralnego i nietypowych wysyłek. Aby zobaczyć treść, potrzebujesz proxy przechwytującego, które deszyfruje i ponownie szyfruje ruch, z własnymi kosztami i ryzykiem. NetSenX odczytuje pola handshake'u tam, gdzie agent przechwytuje pakiety, na Linuksie lub jako czujnik SPAN/TAP, nie w trybie podstawowym na macOS, i nigdy nie deszyfruje ruchu.
Często tak, bo malware, żeby był użyteczny, musi zachowywać się w określony sposób, a to zachowanie widać w przepływach. Rekordy przepływów opisują każde połączenie: źródło i cel, porty, czas rozpoczęcia, czas trwania oraz bajty i pakiety w każdym kierunku. Przejęte urządzenie, które w regularnych odstępach melduje się u swojego serwera sterującego, tworzy rozpoznawalny rytm, czyli beaconing; takie, które poznaje sieć, w krótkim czasie dotyka wielu hostów i portów wewnętrznych, co jest skanowaniem i ruchem lateralnym; takie, które kradnie dane, wysyła znacznie więcej niż zwykle, często w nocy. Nic z tego nie wymaga deszyfrowania, a badania nad analizą ruchu szyfrowanego od lat pokazują, że wzorce czasu i rozmiaru niosą wiele informacji. Ograniczenia: pojedyncze połączenie ze znaną usługą chmurową może wyglądać niewinnie, a cierpliwi napastnicy starają się wtopić w tło. Dlatego analiza przepływów działa najlepiej na tle tego, co normalne dla każdego urządzenia. NetSenX wykrywa beaconing, skanowanie, ruch lateralny i nietypową ilość danych wychodzących w każdym planie, także Free.
Nie treść, ale więcej o niej, niż się zwykle sądzi. Szyfrowanie ukrywa słowa, pliki i naciśnięcia klawiszy, a jednak rozmiar, czas i kierunek pakietów zdradzają wzorce: wideorozmowa, duża wysyłka, sesja zdalnego pulpitu i aktualizacja oprogramowania mają każda swój rozpoznawalny kształt. Badacze od lat pokazują, że taka analiza ruchu pozwala z różną skutecznością rozpoznać odwiedzane strony lub używane aplikacje, nawet przez VPN. W obronie to przydatne: dzięki temu czujnik sieciowy odróżnia sesję interaktywną od automatycznego meldowania się albo zauważa serwer, który nagle wysyła gigabajty, bez deszyfrowania czegokolwiek. Dla prywatności to przypomnienie, że szyfrowanie nie oznacza niewidzialności. Analiza ruchu nie potrafi natomiast przeczytać wiadomości, zobaczyć, jaki plik wysłano, ani wiedzieć, co ktoś wpisał w czat AI. NetSenX korzysta z metadanych przepływów i nieszyfrowanego handshake'u, nigdy nie deszyfruje sesji i nie odtwarza treści.
Mogą być. Trybunał Sprawiedliwości UE orzekł w sprawie Breyer (C-582/14, 19 października 2016 r.), że dynamiczny adres IP może stanowić dane osobowe. NetSenX publikuje umowę powierzenia przetwarzania danych (art. 28 RODO) i przechowuje dane klientów w UE.
Tak. HTTPS oznacza, że połączenie jest szyfrowane, a serwer ma ważny certyfikat dla nazwy w pasku adresu; nie mówi nic o tym, czy strona lub pobierane z niej pliki są bezpieczne. Napastnicy używają HTTPS równie rutynowo jak wszyscy, bo certyfikaty są darmowe i automatyczne, a duża część phishingu i dystrybucji malware odbywa się właśnie przez HTTPS. Kłódka chroni przed kimś, kto czyta lub zmienia ruch po drodze, a nie przed treścią po drugiej stronie. Ochronę przed złośliwymi plikami dają: ochrona punktu końcowego na urządzeniu, filtrowanie w przeglądarce i poczcie, aktualne oprogramowanie i ograniczenie, kto może instalować programy. Po stronie sieci szyfrowanie ukrywa plik, ale nie zachowanie, które zwykle następuje po infekcji: urządzenie, które nagle łączy się z nowym celem w regularnych odstępach, skanuje hosty wewnętrzne albo wysyła nietypowe ilości danych. NetSenX wykrywa te wzorce w każdym planie, z metadanych przepływów i bez deszyfrowania ruchu.
Tylko jeśli klienta da się nakłonić do zaufania przechwytującemu. Atak man in the middle na HTTPS wymaga certyfikatu, który klient zaakceptuje dla docelowej nazwy, użytkownika, który zignoruje ostrzeżenie, albo aplikacji, która nie sprawdza poprawnie certyfikatów. Firmy robią to celowo za pomocą proxy do inspekcji TLS, instalując własny certyfikat główny na zarządzanych urządzeniach. Napastnicy próbują tego samego, podrzucając fałszywy certyfikat główny przez malware, namawiając użytkowników do akceptowania ostrzeżeń albo wykorzystując aplikacje z wadliwym sprawdzaniem certyfikatów. Obrona: nigdy nie ucz pracowników klikania mimo ostrzeżeń o certyfikatach, kontroluj, które certyfikaty główne są zainstalowane na firmowych urządzeniach, aktualizuj aplikacje i stosuj na własnych stronach HTTP Strict Transport Security (HSTS), by przeglądarki odrzucały połączenia nieszyfrowane. Przypinanie certyfikatów w niektórych aplikacjach odrzuca każdego pośrednika, także Twoje proxy. W TLS 1.3 certyfikat serwera jest zaszyfrowany, więc pasywny czujnik sieciowy nie sprawdzi, kto go wystawił; to sprawdzenie należy do urządzenia lub logów proxy.
Gdy program otwiera połączenie TLS, jego pierwsza wiadomość wymienia obsługiwane wersje, szyfry i rozszerzenia w charakterystycznej kolejności. Odcisk taki jak JA4 skraca tę wiadomość do krótkiego ciągu, dzięki czemu to samo oprogramowanie klienckie można rozpoznać w wielu połączeniach bez odszyfrowywania czegokolwiek. Pomaga to wychwycić nietypowych klientów, na przykład skrypt udający przeglądarkę. NetSenX wylicza odciski TLS z handshake'u od planu Starter, we własnej implementacji. Handshake jest widoczny tylko tam, gdzie agent przechwytuje pakiety: na Linuksie lub jako czujnik na porcie SPAN albo TAP, nie w trybie podstawowym używanym na macOS.
Oba tworzą odcisk strony klienta w handshake'u TLS, ale JA4 radzi sobie z zachowaniem nowoczesnych przeglądarek. JA3, opublikowany w 2017 r., haszuje pola ClientHello w kolejności, w jakiej występują. Od początku 2023 r. Chrome zaczął losowo zmieniać kolejność rozszerzeń TLS przy każdym połączeniu, co za każdym razem zmienia wartość JA3 i czyni ją znacznie mniej przydatną do rozpoznawania przeglądarek. JA4, opublikowany w 2023 r., sortuje pola przed haszowaniem, dodaje wersję TLS, transport (TCP lub QUIC) i pierwszy oferowany protokół aplikacji oraz tworzy czytelny ciąg, którego części można porównywać osobno. Żaden z nich sam w sobie nie dowodzi złych zamiarów: wiele programów ma ten sam odcisk, a malware może udawać przeglądarkę. Przydają się do wychwycenia klienta, który nie pasuje do urządzenia, na przykład skryptu udającego przeglądarkę na serwerze. NetSenX wylicza odciski TLS od planu Starter, we własnej implementacji, tam, gdzie agent przechwytuje pakiety: na Linuksie lub jako czujnik SPAN/TAP, nie w trybie podstawowym na macOS.
Server Name Indication (SNI) to pole w ClientHello TLS, w którym klient podaje nazwę strony, z którą chce się połączyć, na przykład login.example.com, bo wiele stron dzieli jeden adres IP, a serwer musi wiedzieć, który certyfikat przedstawić. Jest wysyłane, zanim zacznie się szyfrowanie, więc może je odczytać każdy na trasie. W monitorowaniu to jedno z najbardziej użytecznych pól ruchu szyfrowanego: nazywa usługę stojącą za adresem IP, co pomaga odróżnić asystenta AI, serwis wymiany plików czy znaną aplikację biznesową od nieznanego serwera, bez czytania treści. Opiera się na nim też większość filtrów WWW i wiele zapór. Jego wartość zmniejszają dwie rzeczy: połączenia nawiązywane wprost z adresem IP nie niosą sensownej nazwy, a Encrypted Client Hello (ECH) ukrywa prawdziwą nazwę za publiczną nazwą zastępczą. Wtedy większe znaczenie mają odpowiedzi DNS i historia każdego celu. NetSenX odczytuje nazwę serwera z handshake'u tam, gdzie agent przechwytuje pakiety, na Linuksie lub jako czujnik SPAN/TAP.
ECH to rozszerzenie TLS, które szyfruje wrażliwą część ClientHello, w tym prawdziwą nazwę serwera, kluczem publicznym publikowanym przez stronę w DNS. W sieci obserwator widzi tylko zewnętrzne ClientHello ze wspólną nazwą publiczną, zwykle sieci CDN hostującej stronę, zamiast właściwej strony. Zaprojektowano je dla prywatności: by nikt na trasie, od Wi-Fi w kawiarni po dostawcę internetu, nie dowiadywał się, jaką stronę odwiedzasz. Obsługują je główne przeglądarki, a oferują niektóre duże sieci CDN, więc część ruchu webowego już z niego korzysta, podczas gdy większość serwerów firmowych i wewnętrznych nie. ECH idzie zwykle w parze z szyfrowanym DNS, bo inaczej nazwa i tak wyciekłaby przez zapytanie DNS. Certyfikat i treść sesji były zaszyfrowane już w TLS 1.3; ECH zamyka jedno z ostatnich czytelnych pól. Dla zespołów bezpieczeństwa oznacza to mniej nazw i większe oparcie na zachowaniu.
Częściowo. Przy ECH czujnik nie widzi już prawdziwej nazwy serwera w handshake'u, więc reguły oparte na nazwach, filtry WWW i proste listy shadow IT tracą precyzję dla stron, które go używają. Zostaje jednak sporo: docelowy adres IP i jego operator, zewnętrzna nazwa publiczna, zwykle dużej sieci CDN, odpowiedzi DNS, jeśli DNS nie jest szyfrowany od końca do końca, czas, ilość danych i kierunek każdego przepływu oraz odcisk klienta. Detekcje behawioralne, takie jak beaconing, skanowanie, ruch lateralny i nietypowe wysyłki, nie zależą od nazwy serwera i działają dalej. Ruch wewnętrzny rzadko jest dotknięty, bo serwery wewnętrzne rzadko publikują klucze ECH. Na urządzeniach zarządzanych masz wpływ: skieruj je na własny resolwer DNS i użyj polityk korporacyjnych przeglądarki, które pozwalają kontrolować ECH i szyfrowany DNS. Widoczność usług AI czy wymiany plików po nazwie z dowolnego czujnika sieciowego, także NetSenX, staje się mniej pełna dla stron za ECH.
Ograniczają to, co widzą starsze zapory, ale nie czynią ruchu niewidzialnym. QUIC (RFC 9000, 2021) to transport, na którym działa HTTP/3. Korzysta z portu UDP 443 i szyfruje niemal wszystko, łącznie z dużą częścią tego, co w TCP było czytelne, na przykład numerami pakietów i potwierdzeniami. Jego pierwsze pakiety niosą ClientHello TLS 1.3 chronione jedynie kluczami, które każdy może wyprowadzić, więc czujnik rozumiejący QUIC nadal odczyta nazwę serwera i parametry handshake'u. Zapory i proxy zbudowane dla TCP często w ogóle nie potrafią sprawdzać QUIC. W firmach polegających na inspekcji TLS lub filtrowaniu WWW typowo blokuje się port UDP 443, przez co przeglądarki niezauważalnie wracają do HTTP/2 przez TCP. Bez takiej polityki QUIC widać po prostu jako przepływy UDP z czasem i ilością danych jak każdy inny ruch, a detekcje oparte na przepływach, takie jak beaconing i nietypowa ilość wysyłanych danych, nadal działają. Sprawdź, czy Twoja zapora raportuje QUIC, zanim uznasz, że jest objęty kontrolą.
Może ukryć zapytania DNS, ale nie połączenia, które po nich następują. DNS over HTTPS (DoH, RFC 8484) i DNS over TLS (DoT, RFC 7858) szyfrują pytania, które urządzenie zadaje swojemu resolwerowi. Jeśli przeglądarki lub aplikacje korzystają z zewnętrznego resolwera DoH, firmowy serwer DNS i jego logi nie widzą już, jakie nazwy są sprawdzane, co osłabia filtrowanie oparte na DNS i dochodzenia. Malware może używać DoH z tego samego powodu. Połączenia z rzeczywistymi celami nadal przechodzą przez sieć z adresami IP, czasem i ilością danych, a często z nazwą serwera w handshake'u TLS. Praktyczne kroki: uruchom własny resolwer albo korzystaj z resolwera dostawcy obsługującego szyfrowany DNS i skieruj na niego zarządzane urządzenia; użyj polityk przeglądarki i systemu operacyjnego, by nie korzystały z innych resolwerów; i szukaj urządzeń, które łączą się bezpośrednio z publicznymi usługami DoH. DoT łatwo zauważyć, bo używa portu 853; DoH wygląda jak zwykłe HTTPS. NetSenX alarmuje o tunelowaniu DNS; nie filtruje ani nie blokuje DNS.
Na maszynie, którą kontrolujesz, najprościej sprawić, by klient zapisywał klucze sesji do pliku, i wczytać ten plik do Wiresharka. Przeglądarki i wiele narzędzi wiersza poleceń opartych na OpenSSL lub NSS respektuje zmienną środowiskową SSLKEYLOGFILE: ustaw ją, odtwórz problem, nagrywając ruch Wiresharkiem lub tcpdumpem, a potem wskaż w ustawieniach TLS Wiresharka plik z kluczami. Działa to także w TLS 1.3, gdzie sam klucz prywatny serwera już nie wystarcza. Na własnym serwerze część serwerów WWW i proxy też potrafi logować klucze, możesz też testować na kopii testowej z włączonym logowaniem. Traktuj pliki z kluczami jak hasła: każdy, kto ma plik i nagranie, odczyta ruch, więc usuń oba po zakończeniu i nigdy nie zbieraj ich z cudzych urządzeń bez jasnej podstawy i wiedzy właściciela. W codziennym monitoringu deszyfrowanie rzadko jest potrzebne: metadane przepływów i nieszyfrowany handshake odpowiadają na większość pytań o to, kto z kim i jak się komunikuje.
W TLS 1.3 zajmuje jedną wymianę w obie strony, zanim popłyną dane. Klient wysyła ClientHello z listą obsługiwanych wersji TLS, zestawów szyfrów i grup wymiany kluczy, udziałem klucza dla preferowanej grupy i zwykle nazwą serwera, z którym chce się połączyć (SNI). Serwer odpowiada ServerHello, w którym wybiera wersję, szyfr i grupę, oraz podaje własny udział klucza. Z obu udziałów strony wyprowadzają ten sam sekret i od tej chwili wszystko jest szyfrowane, także certyfikat serwera i dowód, że ma on odpowiadający mu klucz prywatny. Klient sprawdza certyfikat względem zaufanych urzędów i zaczyna się wymiana danych aplikacji. ClientHello i ServerHello przechodzą nieszyfrowane, dlatego pasywny czujnik widzi wersję TLS, wybraną grupę wymiany kluczy, na przykład klasyczną X25519 lub hybrydową X25519MLKEM768, oraz odcisk klienta bez deszyfrowania czegokolwiek. Przy Encrypted Client Hello część ClientHello, łącznie z nazwą serwera, też jest ukryta.
TLS 1.3 (RFC 8446, 2018) jest szybszy i usuwa słabe opcje, które stały za większością dawnych ataków na TLS. Kończy handshake w jednej wymianie zamiast dwóch. Zachowuje tylko wymiany kluczy z utajnieniem przekazywania (forward secrecy), więc nagranie ruchu i późniejsza kradzież klucza prywatnego serwera nie pozwalają już odszyfrować dawnych sesji. Rezygnuje ze starych szyfrów i trybów, takich jak RC4, 3DES, zestawy w trybie CBC i statyczna wymiana kluczy RSA, zostawiając krótką listę nowoczesnych szyfrów uwierzytelnionych. Szyfruje też większą część handshake'u, w tym certyfikat serwera. Dla monitoringu wynikają z tego dwie rzeczy. Pasywne urządzenie nie odszyfruje już sesji kopią klucza prywatnego serwera, więc inspekcja wymaga dziś aktywnego proxy przechwytującego. A jawnie widać mniej: certyfikat jest ukryty, natomiast wiadomości hello, wybrana grupa i nazwa serwera, o ile nie użyto Encrypted Client Hello, pozostają widoczne. Wszędzie preferuj TLS 1.3, a TLS 1.2 zostaw tylko z silnymi zestawami szyfrów dla starszych klientów.
Tak. Obie wersje IETF formalnie wycofał w RFC 8996 (marzec 2021 r.), główne przeglądarki już ich nie akceptują, a opierają się na starych funkcjach skrótu i konstrukcjach szyfrów ze znanymi słabościami. Jeśli wciąż są włączone na serwerze, ryzykiem jest nie tyle bezpośredni atak, co ścieżka obniżenia wersji i oznaka zaniedbania, którą wychwycą audytorzy, ubezpieczyciele i skanery. Zanim je wyłączysz, sprawdź, kto jeszcze z nich korzysta: zwykle są to stare drukarki, skanery, urządzenia przemysłowe, starsze aplikacje i klienty wbudowane, a wyłączenie bez sprawdzenia może zatrzymać linię produkcyjną lub terminal płatniczy. Zajrzyj do logów serwerów, które zapisują wersję TLS, przeskanuj z zewnątrz usługi publiczne, a wewnątrz sieci sprawdź wersje TLS w handshake'ach. Potem je wyłącz albo odizoluj w osobnym segmencie to, czego nie da się zaktualizować, z planem wymiany. Ten sam inwentarz przyda się później w pracach postkwantowych.
Wszystko bez utajnienia przekazywania lub szyfrowania uwierzytelnionego i wszystko ze starych list. W praktyce: wyłącz RC4, którego w TLS zakazuje RFC 7465, 3DES i inne szyfry z 64-bitowym blokiem, szyfry eksportowe i NULL, statyczną wymianę kluczy RSA oraz zestawy w trybie CBC z SHA-1, o ile pozwalają na to Twoi klienci. Zostaw zestawy TLS 1.3, AES-GCM i ChaCha20-Poly1305, a dla TLS 1.2 używaj wymiany ECDHE z AES-GCM lub ChaCha20-Poly1305. Korzystaj z opublikowanych przewodników konfiguracji zamiast wymyślać własne: zalecenia Mozilli dla TLS po stronie serwera i wytyczne techniczne agencji takich jak niemieckie BSI podają sprawdzone profile dla klientów nowoczesnych i starszych. Zanim zmienisz serwer produkcyjny, sprawdź, którzy klienci się łączą i co oferują, z logów serwera lub widoku handshake'ów, by nie odciąć starego urządzenia. Potem przetestuj ponownie z zewnątrz skanerem TLS i włącz hybrydową grupę X25519MLKEM768 tam, gdzie oprogramowanie ją obsługuje.
Utajnienie przekazywania oznacza, że każda sesja używa świeżego, tymczasowego klucza, który potem jest wyrzucany, więc późniejsza kradzież długoterminowego klucza prywatnego serwera nie pozwala odszyfrować wcześniej nagranych sesji. Zapewniają je efemeryczne wymiany kluczy, takie jak ECDHE czy X25519: klucz długoterminowy jedynie dowodzi tożsamości serwera, a klucz sesji powstaje z jednorazowych wartości wybranych przez obie strony. Starsze konfiguracje TLS ze statyczną wymianą kluczy RSA go nie miały, więc jeden skradziony klucz mógł otworzyć lata nagranego ruchu. TLS 1.3 czyni utajnienie przekazywania obowiązkowym, a dobrze skonfigurowane serwery TLS 1.2 też je oferują. Wyjaśnia to również, dlaczego „harvest now, decrypt later” dotyczy wymiany kluczy: utajnienie przekazywania chroni przed przyszłą kradzieżą klucza, ale nie przed przyszłym komputerem kwantowym, który złamie samą efemeryczną wymianę na krzywych eliptycznych. Hybrydowa postkwantowa wymiana kluczy zachowuje utajnienie przekazywania i dodaje brakującą ochronę. Sprawdź swoje serwery skanerem TLS: każdy oferowany zestaw powinien je mieć.
Szyfrowanie zamienia czytelne dane w dane wymieszane, które z powrotem odczyta tylko ktoś z właściwym kluczem. Metoda, czyli algorytm, jest jawna; tajemnicą jest klucz. Dobre szyfrowanie oznacza, że bez klucza nawet potężny komputer nie odzyska danych w żadnym sensownym czasie. Korzystasz z niego codziennie: HTTPS na stronach, VPN do biura, komunikatory, szyfrowanie dysków w laptopach i telefonach oraz kopie zapasowe. Chroni dane w drodze przed każdym, kto może podsłuchiwać sieć, a dane przechowywane przed każdym, kto ukradnie dysk. Nie chroni danych przed kimś, kto ma już klucz albo kontroluje urządzenie, na którym dane są odszyfrowywane, na przykład przed malware na zalogowanym laptopie. Dlatego szyfrowanie działa obok kontroli dostępu, aktualizacji i monitoringu, a nie zamiast nich. Czujnik sieciowy widzi, że szyfrowane połączenia się odbywają, wraz z ich metadanymi, ale nie ich treść.
Szyfrowanie symetryczne używa jednego wspólnego klucza do zamykania i otwierania; asymetryczne, czyli kryptografia klucza publicznego, używa pary: klucza publicznego, który może znać każdy, i klucza prywatnego, który ma tylko właściciel. Algorytmy symetryczne, takie jak AES, są szybkie i szyfrują niemal wszystkie realne dane. Ich słabym punktem jest bezpieczne przekazanie klucza. Rozwiązują to metody klucza publicznego, takie jak RSA, Diffie-Hellman na krzywych eliptycznych i ich postkwantowi następcy: dwie strony, które nigdy się nie spotkały, mogą uzgodnić świeży klucz symetryczny przez otwartą sieć, a klucz prywatny pozwala podpisać dane tak, by każdy z kluczem publicznym mógł to sprawdzić. Prawdziwe protokoły łączą oba podejścia. Połączenie TLS używa kryptografii klucza publicznego w handshake'u, by uzgodnić klucz i dowieść tożsamości serwera, a potem przełącza się na AES lub ChaCha20 dla danych. Ten podział tłumaczy też historię kwantową: algorytm Shora zagraża części z kluczem publicznym, a szyfrowanie symetryczne z kluczami 256-bitowymi pozostaje mocne.
To zależy od rodzaju algorytmu, bo długości nie są porównywalne między rodzajami. W szyfrowaniu symetrycznym AES-128 nadal uchodzi za mocny, a AES-256 daje dodatkowy zapas, także wobec przyszłych komputerów kwantowych; dla danych, które mają długo pozostać tajne, używaj 256 bitów. W RSA typowym minimum jest dziś 2048 bitów, a agencje takie jak niemieckie BSI zalecają co najmniej 3000 bitów dla dłuższej ochrony. Klucze na krzywych eliptycznych są przy tej samej sile znacznie krótsze: 256-bitowa krzywa, taka jak P-256 czy X25519, odpowiada mniej więcej RSA z około 3000 bitami. Do skrótów używaj SHA-256 lub silniejszych. Dwa zastrzeżenia są ważniejsze od liczb. Długość klucza nie pomoże, jeśli klucz jest źle wygenerowany, zapisany w skrypcie albo nigdy nie zmieniany. A RSA i krzywe eliptyczne dowolnej długości padną wobec dużego komputera kwantowego, dlatego ich długoterminowym zastępstwem są algorytmy postkwantowe, a nie dłuższe klucze. Dokładne wartości bierz z aktualnych wytycznych krajowej agencji.
Funkcja skrótu (hash) zamienia dowolną ilość danych w krótki odcisk o stałej długości, na przykład 256-bitowy wynik SHA-256. Te same dane wejściowe zawsze dają ten sam skrót, drobna zmiana daje zupełnie inny, a nikt nie potrafi odtworzyć danych ze skrótu ani znaleźć dwóch wejść o tym samym skrócie. Dzięki temu skróty służą do sprawdzania, czy pobrany plik lub kopia zapasowa się nie zmieniły, do podpisów cyfrowych, które podpisują skrót dokumentu, do bezpiecznego przechowywania haseł i do kontroli integralności w TLS. Stare funkcje zawiodły: MD5 i SHA-1 są złamane do celów bezpieczeństwa, a publiczną kolizję SHA-1 zademonstrowano w 2017 r., więc traktuj je jako przestarzałe wszędzie, gdzie jeszcze występują, na przykład w starych certyfikatach czy kontrolach plików. Obecnie wybiera się SHA-256, SHA-384 i SHA-3. Skrót to nie szyfrowanie: nie ma klucza i nie ma czego odszyfrować. Komputery kwantowe osłabiają funkcje skrótu tylko umiarkowanie.
Nie, a w przypadku haseł właściwym wyborem jest haszowanie. Szyfrowanie da się odwrócić kluczem, więc ktoś, kto ukradnie zaszyfrowane hasła razem z kluczem, odzyska wszystkie hasła. Skrótu nie da się odwrócić, więc system przechowuje tylko skrót i porównuje go przy logowaniu. Zwykłe, szybkie funkcje skrótu, takie jak SHA-256, to nadal zły wybór dla haseł, bo napastnik, który ukradnie bazę, może sprawdzać ogromną liczbę prób na sekundę na kartach graficznych. Używaj funkcji stworzonej dla haseł, celowo wolnej i z losową solą dla każdego użytkownika: Argon2id, scrypt lub bcrypt, jak zaleca przewodnik OWASP dotyczący przechowywania haseł. Jeśli dostawca lub stara aplikacja przechowuje hasła zaszyfrowane albo zahaszowane samym MD5 czy SHA-1, potraktuj to jako ustalenie do naprawy. Dla własnych pracowników większe korzyści leżą gdzie indziej: uwierzytelnianie wieloskładnikowe (MFA), menedżer haseł i blokowanie haseł używanych ponownie. Czujnik sieciowy nie widzi, jak serwer przechowuje hasła; to sprawdza się w przeglądzie aplikacji.
Podpis cyfrowy to wartość obliczona z danych przy użyciu klucza prywatnego, którą każdy posiadacz odpowiadającego mu klucza publicznego może sprawdzić. Jeśli weryfikacja się powiedzie, dowiedzione są dwie rzeczy: dane pochodzą od posiadacza tego klucza prywatnego i nie zmieniły się od chwili podpisania. Podpisy chronią wiele rzeczy, na których polegasz, nawet o tym nie wiedząc: aktualizacje oprogramowania i sterowniki, certyfikaty TLS potwierdzające tożsamość strony, podpisane pliki PDF i e-faktury, pocztę podpisaną S/MIME i kod, który wydają Twoi programiści. W UE kwalifikowane podpisy elektroniczne na mocy rozporządzenia eIDAS mają też skutki prawne. Podpis jest tak wiarygodny jak jego klucz prywatny: jeśli klucz zostanie skradziony, napastnik może podpisać malware, które wygląda na autentyczne, dlatego klucze do podpisywania powinny być w sprzętowych modułach bezpieczeństwa lub podobnie chronionych magazynach, a korzystać z nich powinno niewiele osób. Dzisiejsze podpisy używają RSA lub krzywych eliptycznych, które duży komputer kwantowy by złamał; ich postkwantowymi zastępcami są ML-DSA i SLH-DSA.
Certyfikat TLS to podpisany dokument, który wiąże klucz publiczny z nazwą, na przykład www.example.com, aby przeglądarka lub klient mógł sprawdzić, że rozmawia z prawdziwym serwerem, a nie z podszywającym się. Podpis pochodzi od urzędu certyfikacji (CA), któremu klient już ufa, zwykle przez łańcuch: główny CA, pośredni CA, a potem certyfikat samego serwera. Podczas handshake'u serwer przedstawia certyfikat i dowodzi, że ma odpowiadający mu klucz prywatny. Certyfikaty mają datę ważności i mogą zostać unieważnione. Certyfikat nie dowodzi natomiast, że strona jest bezpieczna czy uczciwa: strona phishingowa może mieć całkowicie ważny certyfikat, bo urzędy sprawdzają głównie kontrolę nad domeną, a nie firmę, która za nią stoi. W firmach certyfikaty dla serwerów, VPN i urządzeń często wystawia wewnętrzny CA. Prowadź inwentarz wszystkich certyfikatów z właścicielami i datami ważności; zapomniane powodują awarie i ukrywają słabe klucze.
Klienci przestają ufać serwerowi: przeglądarki pokazują ostrzeżenie na całą stronę, a aplikacje, API, klienty VPN i urządzenia zwykle w ogóle odmawiają połączenia. Dla użytkowników wygląda to jak awaria i w praktyce nią jest: strony płatności, portale klientów, serwery poczty i połączenia między maszynami mogą przestać działać w chwili wygaśnięcia, często w nocy lub w weekend. Wygasłe certyfikaty uczą też pracowników klikania mimo ostrzeżeń, a tego właśnie chciałby napastnik przechwytujący ruch. Rozwiązaniem jest proces, nie bohaterstwo: inwentarz każdego certyfikatu z właścicielem i datą ważności, alerty z dużym wyprzedzeniem i automatyczne odnawianie przez protokół ACME (RFC 8555) wszędzie, gdzie platforma na to pozwala. Nie zapomnij o certyfikatach w urządzeniach sieciowych, drukarkach, usługach wewnętrznych i podpisywaniu kodu, których zewnętrzne skanery nigdy nie widzą. Obserwacja handshake'ów TLS w sieci wewnętrznej pomaga znaleźć serwery, których nikt nie spisał, choć w TLS 1.3 sam certyfikat jest zaszyfrowany i trzeba go sprawdzić na serwerze.
Bo krótszy okres ważności ogranicza szkody po kradzieży klucza lub błędnie wystawionym certyfikacie i zmusza wszystkich do automatyzacji odnawiania. W kwietniu 2025 r. CA/Browser Forum, organ urzędów certyfikacji i producentów przeglądarek ustalający zasady dla publicznych certyfikatów TLS, przyjął głosowanie SC-081: maksymalny okres ważności spada z 398 do 200 dni od 15 marca 2026 r., do 100 dni od 15 marca 2027 r. i do 47 dni od 15 marca 2029 r. Zasady dotyczą certyfikatów publicznie zaufanych, a nie wystawianych przez Twój wewnętrzny CA. Dla firmy, która wciąż odnawia certyfikaty ręcznie raz w roku, zmienia to nakład pracy: odnowienia stają się częste, a procesy ręczne zawiodą. Odpowiedzią jest automatyzacja przez ACME (RFC 8555) lub narzędzia dostawcy, inwentarz każdego publicznego certyfikatu i miejsca jego instalacji, łącznie z load balancerami i urządzeniami, oraz monitorowanie dat ważności. Potraktuj to jako ćwiczenie kryptozwinności: ta sama dyscyplina pomoże w przejściu na kryptografię postkwantową.
Nie dlatego, że są samopodpisane, ale z powodu tego, co zwykle im towarzyszy. Certyfikat samopodpisany szyfruje równie dobrze jak każdy inny; problemem jest zaufanie. Klienci nie mogą sprawdzić go względem znanego urzędu, więc użytkownicy i administratorzy uczą się klikać mimo ostrzeżeń lub wyłączać weryfikację w skryptach, a ten sam nawyk pozwala przeoczyć prawdziwe przechwycenie. Certyfikaty samopodpisane na urządzeniach mają często słabe lub domyślne klucze, nikt nie śledzi ich ważności i nikt za nie nie odpowiada. Lepszy wzorzec to wewnętrzny urząd certyfikacji, wystawiający certyfikaty w miarę możliwości automatycznie, którego certyfikat główny jest rozesłany na zarządzane urządzenia, z inwentarzem każdego certyfikatu i jego daty ważności. W urządzeniach, które dostarczane są tylko z certyfikatami samopodpisanymi, takich jak drukarki czy sterowniki, wymień certyfikat, jeśli urządzenie na to pozwala, i trzymaj je w segmencie z ograniczonym dostępem. Certyfikaty samopodpisane należą też do Twojego inwentarza postkwantowego: każdy ma typ i rozmiar klucza, które kiedyś trzeba będzie zmienić.
Wzajemne TLS oznacza, że obie strony połączenia przedstawiają certyfikaty: serwer dowodzi swojej tożsamości klientowi, a klient serwerowi. W zwykłym HTTPS certyfikat ma tylko serwer, a użytkownik potwierdza, kim jest, później, hasłem lub tokenem. W mTLS klient potrzebuje klucza prywatnego i certyfikatu wystawionego przez urząd, któremu ufa serwer, co trudno wyłudzić phishingiem i łatwo unieważnić. Jest powszechne między usługami w architekturze mikroserwisów, w API między firmami, do tożsamości urządzeń w IoT i OT oraz w niektórych produktach zdalnego dostępu typu zero trust. Koszty to zarządzanie certyfikatami na dużą skalę, czyli wystawianie, rotacja i unieważnianie certyfikatów klientów, oraz diagnozowanie problemów, gdy coś wygaśnie. W sieci mTLS wygląda jak zwykłe TLS. W TLS 1.3 certyfikat klienta jest zaszyfrowany, więc pasywny czujnik widzi, że połączenie istnieje, i parametry handshake'u, ale nie to, jakiego certyfikatu klienta użyto.
Szyfruje ruch między Twoim urządzeniem a bramą VPN, a nie całą drogę do celu. Za bramą ruch biegnie dalej do sieci biurowej lub internetu, chroniony tylko tym, czego używa sama aplikacja, na przykład HTTPS. Firmowy VPN chroni więc pracowników w hotelowym lub kawiarnianym Wi-Fi przed lokalnym podsłuchem i daje im dostęp do systemów wewnętrznych; nie czyni bezpieczną nieszyfrowanej aplikacji wewnętrznej i nie ukrywa niczego przed siecią firmową, która odbiera ruch. Split tunnelling kieruje przez VPN tylko część ruchu, a resztę bezpośrednio, co pomaga wydajności, ale oznacza, że firmowy monitoring widzi tylko część. Komercyjna usługa VPN przenosi Twoje zaufanie z dostawcy internetu na dostawcę VPN. Same bramy VPN są częstym celem ataków i wymagają szybkich poprawek oraz uwierzytelniania wieloskładnikowego (MFA). W sieci tunele VPN widać jako połączenia z bramą, z ich czasem i ilością danych, ale nie treścią.
Połącz aktywne skanowanie z pasywną obserwacją, bo każde znajduje to, co umyka drugiemu. Autoryzowane skanowanie Twoich zakresów adresów pod kątem portu 22 i innych typowych portów SSH, narzędziem takim jak Nmap, wypisze każdy host, który odpowiada, i wersję oprogramowania, którą ogłasza. Sprawdź konsole chmurowe i rekordy DNS pod kątem serwerów poza zakresami biura. Pasywna obserwacja dodaje to, czego skany nie widzą: SSH na nietypowych portach, serwery osiągalne tylko z niektórych segmentów i to, jak SSH jest faktycznie używane, czyli które klienty łączą się z którymi serwerami i kiedy. Potem przejdź listę z właścicielami: każdy serwer potrzebuje wskazanej osoby, powodu istnienia i harmonogramu poprawek, a wszystko, czego nikt nie przypisze, wyłącz po okresie wypowiedzenia. Ogranicz SSH do sieci administratorów lub serwera przesiadkowego (jump host) i używaj kluczy zamiast haseł. NetSenX alarmuje w każdym planie, gdy host zaczyna łączyć się z wieloma hostami wewnętrznymi na portach administracyjnych, takich jak SSH, bo tak wygląda skanowanie i ruch lateralny.
Zacznij od wersji, którą ogłasza każdy serwer, a potem potwierdź ją ze stanem poprawek dostawcy, bo samo ogłoszenie może wprowadzać w błąd. Każdy serwer SSH wysyła na początku ciąg identyfikacyjny, na przykład SSH-2.0-OpenSSH_9.6p1, a pokaże go skaner lub zwykłe połączenie. Porównaj tę wersję z zakresem z biuletynu. W przypadku regreSSHion (CVE-2024-6387) biuletyn opublikowany przez Qualys 1 lipca 2024 r. wskazywał na przykład OpenSSH od 8.5p1 do 9.8p1, bez tej ostatniej, na Linuksie opartym na glibc. Następnie sprawdź wersję pakietu na każdym serwerze: dystrybucje Linuksa często przenoszą poprawki bezpieczeństwa do starszego numeru wersji, więc serwer ogłaszający wersję podatną może być już załatany, a rozstrzyga system śledzenia bezpieczeństwa dystrybucji. Aktualizuj przez menedżer pakietów, zrestartuj usługę i sprawdź ponownie. Trzymaj listę serwerów SSH w inwentarzu, żeby kolejny biuletyn zajął minuty, a nie dni.