Defaults.Exposed › Naprawy › Współczesne szyfrowanie (wersja TLS i szyfry)

Jak naprawić Współczesne szyfrowanie (wersja TLS i szyfry)

TLS to zamek, który szyfruje dane płynące między Twoimi odwiedzającymi a Twoją stroną. Dwie rzeczy czynią ten zamek godnym zaufania: używanie współczesnej wersji TLS (nie starych, złamanych) oraz używanie silnych szyfrów (właściwego przepisu na szyfrowanie). Ta strona obejmuje oba — plus kilka powiązanych ustawień, które nie wpływają na Twoją ocenę, ale warto o nich wiedzieć.

W skrócie dla Twojej firmy: Jeśli Twoja strona działa na przestarzałym szyfrowaniu lub słabych szyfrach, prywatne dane, które wpisują Twoi klienci — logowania, numery kart, dane kontaktowe — mogą zostać po cichu przechwycone i odczytane w sieciach współdzielonych, a Ty możesz nie przejść kontroli bezpieczeństwa, których banki, operatorzy płatności i więksi klienci wymagają teraz, zanim zrobią z Tobą interes.

Ile może Cię to kosztować

• Klient płaci lub loguje się przez hotelowe czy kawiarniane WiFi, przestarzałe połączenie lub słaby szyfr pozwala obcemu w tej sieci odczytać jego kartę i hasło, a oszustwo — i wściekły telefon — prowadzi prosto do Twojej strony.
• Składasz wniosek o przyjmowanie płatności kartą (albo Twój operator płatności poddaje Cię ponownemu audytowi) i dostajesz odmowę, bo przestarzałe TLS lub zakazany szyfr łamie reguły bezpieczeństwa płatności — Twój koszyk online jest zamrożony, dopóki tego nie naprawisz.
• Dział IT większego klienta przeprowadza rutynowy skan bezpieczeństwa przed podpisaniem, widzi, że Twoja strona wciąż dopuszcza złamane szyfrowanie, i oznacza Cię jako ryzyko — kontrakt utyka przez problem, który nic nie kosztuje, by naprawić.
• Skarga lub naruszenie ochrony danych ląduje na Twoim biurku, a pierwsze pytanie regulatorów to, czy chroniłeś dane klientów «odpowiednio» — działanie na szyfrowaniu publicznie znanym jako złamane od lat to bardzo trudna odpowiedź do udzielenia.
• Twoja strona pokazuje kłódkę, więc wszyscy zakładają, że jest w pełni bezpieczna, i ta luka pozostaje niezauważona latami — aż jedno przechwycone logowanie lub numer karty zamienia się w incydent o wiele kosztowniejszy niż darmowa naprawa.

Dlaczego to ma znaczenie. Szyfrowanie, które jest bezpieczne, jest niewidoczne; szyfrowanie przestarzałe lub słabe to obciążenie, które tkwi cicho aż do dnia, gdy kosztuje Cię klienta, kontrakt lub zaliczenie zgodności. Kontrole wersji TLS i szyfrów to dwie części, które faktycznie ruszają Twoją ocenę, a obie są zwykle pojedynczym darmowym ustawieniem — nie ma żadnej korzyści z pozostawienia starych, złamanych opcji włączonych.

Prostymi słowami

Gdy ktoś odwiedza Twoją stronę, wszystko, co wpisuje — logowania, numery kart, nazwiska, telefony, wiadomości — jest szyfrowane w drodze, by obcy nie mogli tego odczytać. Technologia, która szyfruje, nazywa się TLS (możesz też usłyszeć jej starszą nazwę, SSL). By to szyfrowanie było naprawdę bezpieczne, dwie rzeczy muszą być poprawne:

1. Wersja TLS — która generacja technologii jest używana. Wczesne wersje (TLS 1.0 i 1.1) są publicznie złamane od lat; bezpieczne to TLS 1.2 i TLS 1.3.
2. Szyfr — konkretny przepis, którego TLS używa do szyfrowania. Niektóre szyfry (jak RC4, DES i 3DES) zostały złamane i są teraz zakazane; współczesne szyfry są wciąż silne.

Ta strona obejmuje oba, bo strona może mieć jedno poprawne, a drugie błędne. Możesz mieć współczesny zamek ze starym, łamliwym przepisem wciąż włączonym — albo silny przepis chroniony przez przestarzały zamek. Każda z tych luk to otwarte drzwi. Oba zwykle zamyka ta sama pojedyncza darmowa zmiana ustawień Twojego serwera lub hostingu.

Ile może Cię to kosztować

• Klient okradziony w publicznym WiFi. Ktoś loguje się na konto lub płaci z hotelu, kawiarni czy lotniska. Ponieważ Twoja strona wciąż dopuszcza starą wersję TLS lub słaby szyfr, obcy w tej samej sieci zmusza połączenie do łamliwej opcji i odczytuje jego hasło i numer karty w czasie rzeczywistym. Oszustwo ląduje na kliencie, ale wina — i telefon do wsparcia — ląduje na Tobie.
• Twoje płatności kartą zostają wyłączone. Reguły bezpieczeństwa płatności (PCI DSS) wymagają TLS 1.2 jako minimum i jawnie zakazują słabych szyfrów jak RC4. Gdy Twój operator poddaje Cię ponownemu audytowi albo gdy składasz wniosek o przyjmowanie kart, przestarzała konfiguracja nie przechodzi kontroli i Twój koszyk jest zamrożony, dopóki tego nie naprawisz — dokładnie w złym momencie dla przepływu gotówki.
• Transakcja utyka w kontroli bezpieczeństwa. Zanim większy klient podpisze, jego dział IT przeprowadza rutynowy skan. Natychmiast oznacza, że Twoja strona wciąż przyjmuje złamane szyfrowanie — rodzaj ustalenia, który wygląda niedbale i sprawia, że kupujący zastanawia się, co jeszcze jest poluzowane. Kontrakt tkwi w zawieszeniu przez problem, który nic nie kosztuje, by naprawić.
• Regulator zadaje niewygodne pytanie. Po każdej skardze lub naruszeniu pierwszą rzeczą, jaką chce wiedzieć organ ochrony danych, jest to, czy chroniłeś dane osobowe „odpowiednio”. Działanie na szyfrowaniu znanym jako złamane publicznie od lat jest bardzo trudne do obrony, a „nie zdawaliśmy sobie sprawy, że stara wersja wciąż jest włączona” to niewygodna odpowiedź.
• Kryje się za kłódką latami. Ponieważ Twoja strona wciąż pokazuje normalną kłódkę, nikt nie zauważa luki — aż pojedyncze przechwycone logowanie lub numer karty staje się publicznym incydentem o wiele kosztowniejszym niż pięciominutowa naprawa.

Czym to właściwie jest

Wersja TLS

Strona nie wspiera tylko jednej wersji TLS — może oferować kilka naraz i pozwolić, by przeglądarka każdego odwiedzającego wybrała. Współczesny odwiedzający użyje najnowszej dostępnej wersji i zobaczy normalną kłódkę. Niebezpieczeństwo polega na tym, że stare, złamane wersje mogą tkwić obok dobrych jako otwarte tylne drzwi: atakujący może zmusić połączenie odwiedzającego do „obniżenia” do TLS 1.0 lub 1.1, a potem wykorzystać znane słabości tych wersji (ataki BEAST i POODLE to słynne przykłady), by odszyfrować ruch.

Więc nasza kontrola łączy się z Twoją stroną i testuje każdą wersję osobno — TLS 1.0, 1.1, 1.2 i 1.3 — by zobaczyć, które Twój serwer wciąż przyjmuje. Oto jak wygląda „dobrze” i jak się to ocenia:

• TLS 1.3 (z 1.2 lub bez) i bez starszych: najlepszy wynik — współczesna, czysta konfiguracja. Pełna punktacja.
• Tylko TLS 1.2, bez 1.3: bezpieczne i przechodzi, ale zostawiasz najnowszą, najszybszą wersję na stole. Większość punktów; włączenie 1.3 jest warte zrobienia.
• TLS 1.0 lub 1.1 wciąż przyjmowane: automatyczne niezaliczenie, punktowane zerem i oznaczone jako krytyczne — nie ma znaczenia, że 1.2/1.3 też działają, bo złamane wersje to otwarte drzwi. To właśnie musisz naprawić.

Szyfr

Gdy wersja jest wybrana, TLS wybiera szyfr — właściwy algorytm, który szyfruje dane. Większość współczesnych szyfrów jest silna. Garstka jest złamana i nigdy nie wolno ich używać: RC4 (jego szyfrowanie jest tendencyjne i wycieka tekst jawny), DES (klucz jest tak krótki, że da się go złamać siłą), 3DES (podatny na atak „Sweet32”), plus NULL (brak szyfrowania w ogóle), szyfry klasy eksportowej (celowo osłabione — ataki FREAK i Logjam) oraz anonimowe szyfry (brak kontroli tożsamości, więc oszust może usiąść w środku).

Nasza kontrola szyfrów robi dwie rzeczy. Najpierw patrzy na szyfr, który Twój serwer faktycznie z nami uzgodnił. Potem — i to ważna część — aktywnie próbuje nawiązać połączenie używając kilku znanych złamanych szyfrów (RC4, 3DES, EXPORT, NULL i warianty anonimowe). Serwer może wybrać silny szyfr rozmawiając ze współczesnym klientem, a wciąż przyjąć słaby, jeśli atakujący nalega — i to realne ryzyko obniżenia. Jeśli Twój serwer przyjmuje jakikolwiek zakazany szyfr, kontrola to oznacza; przyjęcie krytycznego (jak RC4 czy NULL) to niezaliczenie. (Na TLS 1.3 nie ma się tu czym martwić — ta wersja z założenia usunęła każdy słaby szyfr, więc sondy są pomijane.)

Trzy informacyjne dodatki

Trzy powiązane elementy są raportowane, ale nie wpływają na Twoją ocenę — oznaczone są jako informacyjne, bo nie da się ich rzetelnie zweryfikować z zewnątrz, a na każdym współczesnym serwerze lub CDN-ie są już obsługiwane poprawnie:

• Kompresja TLS (atak CRIME): stara funkcja, która, jeśli zostawiona włączona, mogłaby pozwolić atakującemu wydobyć ciasteczka sesji. Jest domyślnie wyłączona w każdym współczesnym serwerze WWW od ponad dekady, więc dziś to praktycznie nie-problem.
• OCSP stapling: udogodnienie wydajnościowo-prywatnościowe, w którym Twój serwer z wyprzedzeniem pobiera dowód, że jego certyfikat nie został unieważniony, by każdy odwiedzający nie musiał sam pytać urzędu certyfikacji (co jest wolniejsze i wycieka dane przeglądania). CDN-y jak Cloudflare robią to automatycznie.
• Bezpieczne renegocjowanie: poprawka starej luki (CVE-2009-3555), która pozwalała atakującym wstrzykiwać dane do sesji. TLS 1.3 całkowicie usunął renegocjowanie, więc tam to nie-problem, a współczesne serwery TLS 1.2 wdrażają poprawkę domyślnie.

Pokazujemy je, by Twój informatyk miał pełny obraz, ale dla zdecydowanej większości właścicieli nie ma nic do zrobienia — Twoją ocenę napędzają kontrole wersji i szyfrów powyżej.

Jak to naprawić (za darmo, ~30 minut)

Przekaż to swojemu informatykowi — naprawa jest darmowa. Ta sekcja jest dla osoby zarządzającej Twoją domeną, stroną lub hostingiem. Naprawa to zmiana konfiguracji, a nie zakup; my pobieramy opłatę jedynie za monitorowanie, że Twoje szyfrowanie pozostaje poprawnie skonfigurowane w czasie. Pojedyncza współczesna konfiguracja poniżej naprawia naraz ustalenia dotyczące wersji i szyfrów.

Najprostsze niezawodne podejście to wygenerować znaną-dobrą konfigurację, zamiast pisać ją ręcznie: wklej typ swojego serwera do Generatora konfiguracji SSL Mozilli pod https://ssl-config.mozilla.org/ i wybierz profil „Intermediate” (szeroka zgodność) lub „Modern” (tylko TLS 1.3, jeśli nie musisz wspierać niczego starego). Wypisuje za Ciebie poprawne linie ssl_protocols i ssl_ciphers.

Wedle platformy:

1. Cloudflare lub host zarządzany — zwykle jedno lub dwa kliknięcia. W Cloudflare: SSL/TLS → Edge Certificates → Minimum TLS Version → TLS 1.2, a zestawy szyfrów są tam zarządzane za Ciebie (platforma nie zaoferuje zakazanych szyfrów). Większość hostów zarządzanych i kreatorów stron (Squarespace, Wix, Shopify, współczesne hosty WordPress) już wymusza TLS 1.2+ z silnymi szyframi — po prostu potwierdź, że nie ma wciąż włączonej opcji „legacy TLS” lub „zgodność ze starymi przeglądarkami”.
2. Nginx. Ustaw tylko-współczesne wersje i jawną listę silnych szyfrów, potem przeładuj:

   ssl_protocols TLSv1.2 TLSv1.3;
   ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
   ssl_prefer_server_ciphers on;
   

   (TLS 1.3 wymaga OpenSSL 1.1.1+ na maszynie.)
3. Apache. Wyłącz stare wersje i przypnij silną listę szyfrów, potem zrestartuj:

   SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
   SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
   SSLHonorCipherOrder on
   

4. Windows / IIS. Użyj darmowego narzędzia IIS Crypto (lub równoważnych ustawień rejestru), by wyłączyć TLS 1.0 i 1.1, wyłączyć szyfry RC4/DES/3DES/NULL/EXPORT i zostawić TLS 1.2 oraz 1.3 z włączonymi silnymi szyframi. Szablon „Best Practices” narzędzia robi to wszystko jednym kliknięciem.
5. Informacyjne dodatki (opcjonalne, darmowe). Jeśli chcesz czystego kompletu: na Nginx dodaj ssl_stapling on; ssl_stapling_verify on; (z linią resolver) dla OCSP stapling; na Apache SSLUseStapling On. Kompresja TLS i bezpieczne renegocjowanie są już domyślnie bezpieczne na współczesnych serwerach — bez działania. Na Cloudflare wszystkie trzy są obsługiwane automatycznie.
6. Zweryfikuj, potem sprawdź ponownie tutaj. Potwierdź, że pozostają tylko bezpieczne wersje i szyfry — na przykład nmap --script ssl-enum-ciphers -p 443 twojadomena.pl, albo przetestuj narzędziami z https://ssl-config.mozilla.org/ — a potem uruchom tę kontrolę ponownie. Gdzie to możliwe, włącz TLS 1.3 obok 1.2: jest zarazem szybsze i bezpieczniejsze.

Częste błędy

• «Mamy kłódkę, więc jest w porządku». Kłódka dowodzi tylko, że bezpieczne połączenie istnieje. Nie mówi nic o tym, czy stara wersja lub zakazany szyfr są wciąż przyjmowane w tle — co jest dokładnie luką, którą te kontrole znajdują.
• Naprawa wersji, ale nie szyfrów (lub odwrotnie). Wyłączenie TLS 1.0/1.1 nie usuwa automatycznie RC4 ani 3DES, a przypięcie silnych szyfrów nie wyłącza automatycznie starych wersji. Ustaw oba — wygenerowana konfiguracja powyżej to robi.
• Pozostawienie przełączników «legacy» lub «zgodność ze starymi przeglądarkami». Wielu hostów i CDN-ów ma opcję, która po cichu ponownie włącza złamane wersje lub słabe szyfry „dla zgodności”. Niemal nigdy nie pomaga prawdziwemu odwiedzającemu, a wprost powoduje to ustalenie.
• Zapomnienie o faktycznym przeładowaniu/restarcie serwera. Zmiany konfiguracji nie wchodzą w życie, dopóki serwer WWW nie zostanie przeładowany — zaskakująco częsty powód, dla którego „naprawiona” strona wciąż nie przechodzi ponownej kontroli.
• Skonfigurowanie jednego serwera, ale nie wszystkich. Jeśli prowadzisz load balancer, wiele serwerów WWW lub osobne subdomeny (sklep, blog, aplikacja), każdy punkt końcowy TLS potrzebuje tej samej konfiguracji — atakujący celuje w najsłabszy.

Co zapamiętać

Wersja TLS i szyfr to dwie części Twojego szyfrowania, które faktycznie ruszają Twoją ocenę, a obie sprowadzają się do wyłączenia opcji, które są publicznie złamane od lat. Naprawa jest darmowa, to zwykle jedna współczesna linia konfiguracji na serwer, a dla zwykłego odwiedzającego nie zmienia nic poza uczynieniem jego połączenia naprawdę bezpiecznym. Powiązane elementy — kompresja, OCSP stapling, bezpieczne renegocjowanie — warto znać, ale nie wpłyną na Twoją ocenę, a w każdej współczesnej konfiguracji są już obsługiwane za Ciebie.

Najczęstsze pytania