Koniec wsparcia dla starego TLS: jak przygotować serwery i monitorować błędy klientów

Cel i kontekst: po co w ogóle ruszać stary TLS

Wyłączenie wsparcia dla starych wersji TLS to już nie kaprys działu bezpieczeństwa, tylko konieczność. Chodzi o ograniczenie ryzyka ataków na warstwę transportową, spełnienie wymogów regulacyjnych oraz uniknięcie sytuacji, w której krytyczny audyt bezpieczeństwa kończy się grubym raportem do zarządu. Równolegle trzeba zadbać, żeby zmiana nie „zabiła” biznesu, czyli nie odcięła nagle części klientów korzystających jeszcze z przestarzałych przeglądarek, systemów czy integracji.

Celem jest zbudowanie planu: zrozumieć konsekwencje wyłączenia TLS 1.0/1.1, poprawnie skonfigurować serwery oraz przygotować monitoring, który szybko pokaże, gdzie po stronie klientów coś się rozsypało.

Dlaczego stare wersje TLS znikają z internetu

Przypomnienie: czym jest TLS i co jest nie tak z 1.0/1.1

TLS (Transport Layer Security) to protokół odpowiedzialny za szyfrowanie i uwierzytelnianie połączeń w internecie. Stoi za „kłódką” przy HTTPS, zabezpiecza IMAPS, SMTPS, FTPS, VPN-y i wiele innych kanałów. Starsze wersje TLS 1.0 i 1.1 powstały w czasach, kiedy wymagania bezpieczeństwa były zupełnie inne. Dziś ich projektowe ograniczenia są już zwyczajnie nieakceptowalne.

Kluczowe problemy dawnych wersji:

• Słabe lub przestarzałe zestawy szyfrów – obsługa RC4, 3DES, słabych trybów CBC, brak wymuszenia nowoczesnych konstrukcji AEAD (np. GCM).
• Podatność na klasyczne ataki – m.in. BEAST, POODLE i ataki wykorzystujące słabości MAC-then-encrypt, słabe renegocjacje i błędy implementacyjne.
• Brak wsparcia dla nowoczesnych mechanizmów – brak 0-RTT, brak poprawionej negocjacji wersji, gorsze wsparcie Perfect Forward Secrecy w praktycznych konfiguracjach.
• Problemy kompatybilnościowe – potrzeba utrzymywania „zoo” konfiguracji, by dogodzić starym klientom, co często kończy się niechcianym włączeniem słabych algorytmów.

W efekcie utrzymywanie TLS 1.0 i 1.1 w środowisku produkcyjnym oznacza nie tylko większe ryzyko ataku technicznego, ale także poważny argument dla audytorów czy ubezpieczycieli cyber – w razie incydentu trudno będzie obronić decyzję o pozostawieniu archaicznych protokołów.

Regulacje i wymagania: gdy bezpieczeństwo jest wymogiem formalnym

Do migracji z przestarzałych wersji TLS pcha nie tylko zdrowy rozsądek, ale i przepisy oraz standardy branżowe. Szczególnie mocno widać to w sektorze finansowym i e‑commerce.

Kilka kluczowych przykładów:

• PCI DSS – standard bezpieczeństwa dla podmiotów przetwarzających płatności kartowe. Od lat wymaga porzucenia TLS 1.0 (z nielicznymi, już historycznymi wyjątkami). Organizacje podlegające PCI DSS, które nadal udostępniają usługi po TLS 1.0, narażają się na niezgodność z wymogami i konsekwencje finansowe.
• Wytyczne przeglądarek – główne przeglądarki (Chrome, Firefox, Edge, Safari) oficjalnie wycofały lub planowo wycofały wsparcie dla TLS 1.0 i 1.1, a strony korzystające z tych wersji były oznaczane jako „niebezpieczne” lub blokowane.
• Dostawcy chmur i usług SaaS – wielu dużych dostawców (AWS, Azure, Google Cloud, Cloudflare i inni) wprowadziło ograniczenia konfiguracji do TLS 1.2/1.3 lub wymaga dodatkowych kroków, aby włączyć starsze wersje (często tylko tymczasowo).

Dla wielu organizacji jest to prosty argument „z góry”: jeśli chcemy przyjmować płatności kartą, współpracować z bankiem albo utrzymać certyfikację, stare TLS-y po prostu muszą zniknąć.

Decyzje producentów przeglądarek i systemów

Producenci przeglądarek i systemów operacyjnych od lat zapowiadają wygaszanie wsparcia dla TLS 1.0 i 1.1. Najważniejsze kroki:

• Chrome, Firefox, Edge i Safari wprowadziły blokady lub bardzo agresywne ostrzeżenia dla połączeń używających TLS 1.0/1.1. W praktyce użytkownik musiał świadomie „przeklikać się” przez ostrzeżenia, co w środowisku biznesowym jest nie do zaakceptowania.
• Nowoczesne systemy operacyjne (nowsze Windows, aktualne dystrybucje Linux, macOS, iOS, Android) domyślnie preferują TLS 1.2 i 1.3, a w niektórych konfiguracjach nie próbują już walki o negocjację starszych wersji.

To oznacza, że trzymanie starych protokołów nie pomaga znacząco większości użytkowników – wspiera głównie naprawdę stare systemy, które same w sobie są krytycznym problemem bezpieczeństwa.

Ryzyko utrzymywania TLS 1.0 i 1.1 w infrastrukturze

Pozostawienie starych wersji TLS to nie tylko potencjalna podatność „na papierze”. Konsekwencje są bardzo konkretne:

• Reputacja i zaufanie – wycieki danych klientów czy incydenty z przechwyceniem sesji szyfrowanej słabymi protokołami trudno wytłumaczyć, gdy od lat wiadomo, że TLS 1.0 jest do wygaszenia.
• Audyty bezpieczeństwa – raport audytowy wskazujący obecność TLS 1.0/1.1 w kanałach produkcyjnych zazwyczaj kończy się zaleceniem natychmiastowej migracji i może blokować uzyskanie certyfikatów ISO, SOC itp.
• Odpowiedzialność prawna i ubezpieczeniowa – w razie incydentu ubezpieczyciel lub regulator może podać brak migracji jako przykład zaniedbania.

Krótko mówiąc: koszt utrzymywania przestarzałych wersji TLS jest coraz wyższy, a korzyści z ich dalszej obsługi – coraz mniejsze.

Przegląd aktualnych wersji TLS i algorytmów szyfrujących

TLS 1.2 vs TLS 1.3 w praktyce

Współcześnie sensowne minimum to TLS 1.2. Zalecany standard to TLS 1.3 wszędzie tam, gdzie to możliwe. Obie wersje różnią się jednak istotnie pod względem architektury i właściwości.

TLS 1.2:

• Najpopularniejsza wersja w praktyce – szeroko wspierana przez przeglądarki, systemy, biblioteki.
• Wspiera zarówno nowoczesne pakiety szyfrów (AES-GCM, ChaCha20-Poly1305, ECDHE), jak i starsze (CBC, niektóre słabe krzywe).
• Więcej opcji = więcej szans na błędną konfigurację. Dobrze skonfigurowany TLS 1.2 jest nadal bezpieczny, ale wymaga świadomych decyzji.

TLS 1.3:

• Uproszczony handshake – mniej rund podróży, co skraca czas nawiązania połączenia (niższe RTT).
• Silniejsze domyślne wymagania – usunięte przestarzałe mechanizmy (np. statyczne RSA, słabe pakiety szyfrów, renegocjacja).
• Domyślnie wymusza Perfect Forward Secrecy oraz nowoczesne algorytmy (AEAD).
• Potencjalnie mniej problemów konfiguracyjnych, ale wymaga wsparcia po stronie klientów (starsze urządzenia mogą go nie obsługiwać).

Najbezpieczniejszy i najbardziej praktyczny wariant to konfiguracja: TLS 1.2 + TLS 1.3 z ograniczeniem TLS 1.2 wyłącznie do mocnych pakietów szyfrów oraz preferowanym TLS 1.3 tam, gdzie to możliwe.

Nowoczesne pakiety szyfrów i co powinno zniknąć z konfiguracji

W kontekście migracji od starych TLS nie chodzi tylko o sam numer wersji, ale również o dobór zestawów szyfrów (cipher suites). Nawet przy TLS 1.2 można popełnić poważne błędy, włączając słabe algorytmy.

Współczesne minimum:

• AEAD – GCM, ChaCha20-Poly1305 (zapewniają ochronę integralności i poufności w jednej konstrukcji).
• ECDHE – wymuszenie kluczy efemerycznych i Perfect Forward Secrecy (PFS).
• SHA-256 lub mocniejsze – brak SHA-1 w nowych konfiguracjach.

Do wyłączenia w 202x:

• RC4, 3DES, DES, IDEA – algorytmy uznane za słabe lub zbyt krótkie.
• Anonymous DH (ADH), EXPORT – zestawy bez uwierzytelniania lub z obniżonym bezpieczeństwem (FREAK, LOGJAM).
• Static RSA key exchange – preferowane są wyłącznie pakiety z ECDHE.

Dobór szyfrów powinien być oparty na oficjalnych rekomendacjach (np. Mozilla SSL Configuration Generator, BCP 195, zalecenia dostawców chmur), a nie na „kopiuj–wklej z bloga sprzed pięciu lat”.

Co jest „must have” w konfiguracji serwera, a co można wyłączyć

Na poziomie serwera warto przyjąć rozsądny zestaw podstawowy oraz dodatkowe opcje do rozważenia. Taki core daje przewidywalne bezpieczeństwo i kompatybilność.

Absolutne minimum w 202x:

• Wymuszona minimalna wersja TLS = 1.2 (bez TLS 1.0/1.1).
• Wsparcie dla TLS 1.3, jeśli to możliwe w danym serwerze/OS.
• Pakiety szyfrów z AEAD + ECDHE, bez RC4/3DES i słabych krzywych.
• Certyfikaty z kluczem min. 2048-bit RSA lub ECDSA na współczesnych krzywych (np. P-256).

Opcje zalecane (ale nie zawsze obowiązkowe):

• OCSP stapling – sprawniejsze sprawdzanie odwołania certyfikatu.
• HSTS (HTTP Strict Transport Security) – wymuszenie HTTPS w przeglądarce, najlepiej po okresie testowym.
• ALPN (np. HTTP/2) – poprawa wydajności, choć dotyczy to głównie ruchu WWW.

Wpływ wyboru szyfrów na wydajność

Bezpieczeństwo zawsze miesza się z wydajnością. Dobór zestawów szyfrów wpływa na obciążenie CPU, czas handshake oraz zachowanie na urządzeniach mobilnych.

Kluczowe aspekty:

• Sprzętowe przyspieszenie AES – większość współczesnych CPU ma wsparcie AES-NI, więc AES-GCM jest bardzo szybki na serwerach, ale na starszych urządzeniach mobilnych lepiej sprawdza się ChaCha20-Poly1305.
• Liczba handshake’ów – TLS 1.3 skraca czas ustanawiania połączenia, co na wysokim RPS (requests per second) istotnie zmniejsza obciążenie.
• Długość kluczy i typ krzywych – ECDHE na krzywych P-256 jest zwykle wydajniejszy niż duże klucze RSA przy handshake, co ma znaczenie dla serwerów API z dużą liczbą krótkich połączeń.

Przy projektowaniu konfiguracji warto przetestować kombinacje AES-GCM i ChaCha20-Poly1305 na typowych klientach (przeglądarki, aplikacje mobilne) i porównać czasy odpowiedzi oraz obciążenie CPU.

Inwentaryzacja – jakie serwery i usługi używają jeszcze starego TLS

Gdzie zwykle chowają się stare konfiguracje TLS

Wyłączenie TLS 1.0 i 1.1 wymaga pełnego obrazu infrastruktury. Stare konfiguracje potrafią czaić się w najmniej oczywistych miejscach. Poza oczywistymi serwerami WWW, warto przejrzeć:

• Serwery www – Nginx, Apache, IIS, serwery aplikacyjne (Tomcat, Jetty, Node, .NET Kestrel, itp.).
• API – szczególnie te wystawione dla partnerów B2B, z których korzystają stare integracje.
• Serwery pocztowe – SMTP (STARTTLS, SMTPS), IMAP/POP3 (z SSL/TLS).
• Serwery LDAP/LDAPS – katalogi używane przez aplikacje wewnętrzne.
• VPN i serwery zdalnego dostępu – OpenVPN, IPsec, SSL VPN w sprzętowych firewallach.
• Reverse proxy i load balancery – HAProxy, F5, Citrix ADC, AWS ELB/ALB/NLB, Cloudflare, nginx w roli LB.
• Urządzenia sieciowe i IoT – kontrolery Wi‑Fi, drukarki, skanery, urządzenia przemysłowe, panele zarządzania storage.

Niespodzianki zwykle wychodzą tam, gdzie od lat nikt nie dotykał konfiguracji, bo „po prostu działa”. Czyli dokładnie tam, gdzie TLS 1.0/1.1 nadal się trzyma.

Jak efektywnie przeskanować infrastrukturę

Do inwentaryzacji przydaje się połączenie skanowania automatycznego i ręcznego przeglądu konfiguracji. Dobry punkt wyjścia to prosty plan:

1. Zebranie listy hostów i usług (CMDB, DNS, inventory z narzędzi typu Ansible, Terraform, cloud inventory).
2. Skanowanie portów pod kątem TLS przy pomocy narzędzi takich jak nmap (skrypt ssl-enum-ciphers) czy testssl.sh.

Automatyczne skanowanie pod kątem starych wersji TLS

Po wstępnym przeglądzie listy hostów przydaje się powtarzalne, automatyczne skanowanie. W przeciwnym razie po miesiącu nikt już nie będzie pamiętał, czy dana usługa była zweryfikowana, czy tylko „na pewno jest OK”.

Praktyczne podejście:

• testssl.sh – dobry do szczegółowego skanowania pojedynczych hostów lub krótkich list, daje pełen raport protokołów, szyfrów, podatności.
• nmap + ssl-enum-ciphers – lepszy do szerokiego przeglądu wielu adresów/portów; wystarczy dodać zakres IP i odpowiedni skrypt.
• Skrypty własne – prosty wrapper w Bash/Pythonie, który:
  • czyta listę host:port z pliku,
  • uruchamia testssl.sh lub nmap,
  • parsuje wynik do CSV/JSON,
  • oznacza hosty, które nadal obsługują TLS 1.0/1.1.

Dobrym nawykiem jest trzymanie wyników skanów w systemie kontroli wersji lub narzędziu do raportowania (np. wiki, ticket w systemie ITSM). Pozwala to porównać stan „przed” i „po” migracji oraz łatwo wyłapać nowe usługi, które nagle „magicznie” zaczęły wspierać TLS 1.0, bo ktoś skopiował starą konfigurację.

Przegląd konfiguracji i zgodność z politykami

Skanery pokażą efekty końcowe, ale w wielu środowiskach istnieją polityki bezpieczeństwa i szablony, które powinny być spójne. Warto więc spojrzeć także na źródła konfiguracji:

• Repozytoria IaC – role Ansible, moduły Terraform, szablony Helm, manifesty Kubernetes (Ingress, Service) – jeśli tam nadal jest TLS 1.0, problem będzie wracał jak bumerang.
• Szablony serwerów www i reverse proxy – pliki include z konfiguracją SSL dla nginx/Apache/HAProxy.
• Polityki GPO / MDM – w środowiskach Windows czy zarządzanych urządzeniach mobilnych to one definiują, jakie wersje TLS są włączone po stronie klienta.

Usunięcie TLS 1.0/1.1 tylko z pojedynczych hostów bez korekty szablonów konfiguracyjnych gwarantuje, że przy następnym wdrożeniu środowisko testowe „nagle” odtworzy stare ustawienia. Dobrze jest potraktować polityki i szablony jako źródło prawdy.



Analiza klientów – kto jeszcze korzysta z TLS 1.0/1.1

Źródła danych o wersjach TLS po stronie klientów

Zanim cokolwiek wyłączysz, trzeba wiedzieć, kogo to zaboli. Informacje o wersjach TLS i szyfrach można pozyskać z kilku miejsc:

• Logi serwerów www – nginx/Apache/HAProxy potrafią logować wersję protokołu i wybrany cipher suite (np. zmienne $ssl_protocol, %{SSL_PROTOCOL}x, itp.).
• Logi load balancerów i WAF – sprzętowe i chmurowe LB oraz firewalle aplikacyjne często dają gotowe pola typu tlsVersion, ssl_cipher.
• SIEM – jeśli logi TLS są już zbierane centralnie, można po prostu odpalić zapytanie agregujące ruch według wersji protokołu i typu klienta.
• Logi serwerów pocztowych/VPN – większość daemonów (Postfix, Dovecot, OpenVPN) loguje wersję TLS i szyfr przy zestawieniu sesji.

Taki przegląd rzadko wymaga ingerencji w aplikacje. Wystarczy poprawić format logów i poczekać kilka dni, żeby zebrać reprezentatywny obraz.

Jak zbudować obraz populacji klientów

Same liczby typu „5% ruchu to TLS 1.0” są mało użyteczne, jeśli nie wiadomo, kto za nimi stoi. W analizie przydają się dodatkowe wymiary:

• User-Agent – przeglądarka, wersja systemu; pozwala wyłapać np. stare Androidy czy Internet Explorera w korporacjach.
• Adresy IP / sieci – można skorelować z listą partnerów B2B lub lokalizacjami biur.
• Endpointy / URL-e – często problem dotyczy jednej specyficznej funkcji (np. starego endpointu SOAP dla partnera), a nie całego serwisu.
• Pory dnia – ruch z systemów wsadowych czy integracji B2B bywa skoncentrowany nocą; to czas, w którym inne problemy szybciej wyjdą na jaw.

W praktyce kończy się to kilkoma prostymi raportami: „top 20 User-Agentów korzystających z TLS 1.0/1.1”, „top 20 sieci/partnerów”, „podział po endpointach”. Dzięki temu łatwo zidentyfikować: „to nie użytkownicy, to nasz stary skaner kodów w magazynie i dwa systemy partnerów”.

Segmentacja: klienci wewnętrzni, zewnętrzni i partnerzy

Inaczej podchodzi się do starego TLS używanego przez pracowników, inaczej do klientów końcowych, a jeszcze inaczej do integracji B2B. Dobrze jest więc logicznie podzielić ruch:

• Użytkownicy z internetu – przeglądarki, aplikacje mobilne; tu zwykle adopcja TLS 1.2/1.3 jest wysoka, a problem dotyczy głównie starych telefonów i systemów w stylu Windows XP.
• Użytkownicy wewnętrzni – komputery w domenie, terminale, urządzenia biurowe; nad tym środowiskiem z reguły masz większą kontrolę (GPO, MDM), więc migracja jest kwestią zarządzania zmianą, a nie walki z całym internetem.
• Partnerzy B2B – integracje system–system, często utrzymywane „historycznie”, bez jasnego właściciela po stronie biznesu; to zwykle najtrudniejsza grupa do przekonania, że czas na upgrade.

Takie rozróżnienie pomaga dobrać kanał komunikacji, priorytety i „deadline’y”. Ruch zewnętrzny można zwykle odciąć szybciej, natomiast partnerom trzeba dać więcej czasu oraz wsparcia technicznego.

Jak długo monitorować przed wyłączeniem starego TLS

Okres obserwacji nie powinien być zbyt krótki ani nieskończony. Sensowny kompromis to:

• minimum kilka dni pod zwykłym obciążeniem,
• co najmniej jeden pełen cykl biznesowy – np. tydzień lub miesiąc, jeśli istotne procesy są miesięczne,
• dodatkowa obserwacja w szczytach sezonowych (np. Black Friday, koniec miesiąca rozliczeniowego), jeśli to ma znaczenie.

Jeśli po takim okresie w logach nadal widać sensowny wolumen ruchu na TLS 1.0/1.1, temat powinien trafić do analizy ryzyka z udziałem biznesu, a nie tylko administratorów.

Strategia migracji – jednorazowe cięcie czy stopniowe wygaszanie

Scenariusz „big bang” – szybkie odcięcie starych protokołów

Najprostsze z technicznego punktu widzenia jest jednorazowe wyłączenie TLS 1.0/1.1 na wszystkich frontach. Jeden deployment, zmiana konfiguracji, koniec tematu. Taki wariant ma jednak swoje konsekwencje.

Zalety:

• szybkie zmniejszenie powierzchni ataku,
• prostsza dokumentacja i audyt – „od daty X nie obsługujemy TLS < 1.2”,
• brak konieczności utrzymywania równoległych ścieżek.

Wady:

• ryzyko nagłej awarii integracji, o których nikt już nie pamięta,
• większa szansa na incydent w stylu: „nie działa system w magazynie, bo bramka skanuje przez HTTPS na TLS 1.0”,
• trudniejsza komunikacja do partnerów, jeśli nie dostali wystarczającego czasu na upgrade.

Taki scenariusz sprawdza się głównie w prostszych środowiskach lub tam, gdzie organizacja ma wysoką dojrzałość procesową, a inwentaryzacja jest świeża i rzetelna (czyli w teorii wszędzie, a w praktyce… różnie).

Stopniowe wygaszanie – podejście mniej ryzykowne

Alternatywą jest etapowe ograniczanie wsparcia, z kontrolowanym monitoringiem. Typowy plan:

1. Etap 1 – pozostawienie TLS 1.0/1.1, ale intensywne logowanie i raportowanie klientów, którzy z nich korzystają.
2. Etap 2 – komunikaty ostrzegawcze (np. baner w aplikacji webowej, mailingi do partnerów, komunikaty wewnętrzne) i twarda data wyłączenia.
3. Etap 3 – ograniczenia na wybranych środowiskach (np. najpierw staging/UAT, potem część węzłów produkcji), aby zobaczyć, czy pojawią się zgłoszenia.
4. Etap 4 – pełne wyłączenie starych wersji, z możliwością czasowego „rollbacku” w wyjątkowych przypadkach.

Takie podejście zmniejsza stres i pozwala złapać nieznane zależności produkcyjne na etapie testów lub częściowej produkcji. Kosztuje jednak nieco więcej pracy operacyjnej.

Wydzielenie „legacy endpointów” jako kompromis

Czasem pełne wyłączenie starych protokołów jest blokowane przez jeden, dwa krytyczne systemy, których szybko nie da się zmodernizować. Wtedy rozwiązaniem bywa izolacja:

• tworzony jest osobny host/endpoint (np. legacy-api.example.com) z włączonym TLS 1.0/1.1,
• ruch z partnerów/starych urządzeń przekierowuje się wyłącznie tam,
• reszta publicznych usług działa już tylko na TLS 1.2/1.3,
• na legacy endpoint nakłada się dodatkowe środki: IP allow-list, VPN, ograniczenie do konkretnych ścieżek, monitoring anomalii.

Taki „getto serwisów legacy” nie jest idealny z punktu widzenia czystości architektury, ale pozwala przesunąć ryzyko w czasie i jednocześnie nie blokować całej organizacji na lata.

Komunikacja z interesariuszami i akceptacja ryzyka

Decyzja o twardym terminie wyłączenia TLS 1.0/1.1 powinna być transparentna i udokumentowana. Kilka elementów ułatwia życie:

• Notatka z analizy ryzyka – skala ruchu na starych protokołach, typy klientów, potencjalne skutki biznesowe, plan mitigacji.
• Zatwierdzenie przez właścicieli biznesowych – to oni biorą odpowiedzialność za ewentualne niezmodernizowane systemy, nie tylko dział IT.
• Jasny harmonogram – konkretna data i godzina, precyzyjne opisy: „po tej dacie klienci ze starymi systemami nie połączą się”, bez eufemizmów.

W wielu organizacjach pomaga też przywołanie wymagań regulacyjnych lub audytowych – nikt nie chce tłumaczyć się audytorowi, że „nie zdążyliśmy od 2018 roku”.

Konfiguracja serwerów WWW i API po wyłączeniu starego TLS

Ogólne zasady konfiguracji po stronie serwera

Po decyzji o minimalnej wersji TLS konfiguracja sprowadza się do kilku powtarzalnych kroków na każdym typie serwera:

• ustawienie minimalnej wersji protokołu (min. TLS 1.2),
• włączenie TLS 1.3, jeśli wspiera go wersja serwera/OS,
• ograniczenie cipher suites do mocnych kombinacji (ECC + AEAD),
• aktualizacja certyfikatów i łańcucha zaufania,
• włączenie rozsądnych opcji dodatkowych: OCSP stapling, HSTS, ALPN, session tickets itp.

W większości przypadków nie trzeba wymyślać wszystkiego od zera – dobrym punktem startu są profile „modern”/„intermediate” z narzędzi typu Mozilla SSL Configuration Generator, dostosowane do lokalnych wymagań.

Przykładowe ustawienia dla nginx

Dla nginx typowa konfiguracja po odcięciu starych protokołów może wyglądać tak (fragment, który zwykle trzymany jest w pliku include):

ssl_protocols TLSv1.2 TLSv1.3;

ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
              ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
              ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305";
ssl_prefer_server_ciphers on;

ssl_session_cache shared:SSL:50m;
ssl_session_timeout  1d;
ssl_session_tickets on;

ssl_stapling on;
ssl_stapling_verify on;

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Taką konfigurację wypada jeszcze dopasować do wersji OpenSSL/boringssl, wymagań compliance i specyfiki aplikacji (np. czy HSTS ma obejmować wszystkie subdomeny). Kluczowe jest jednak to, że TLS 1.0/1.1 nie występują tu w ogóle.

Konfiguracja Apache HTTPD

W Apache ustawienia protokołów i szyfrów znajdują się zwykle w sekcji <VirtualHost *:443> lub w pliku konfiguracyjnym modułu ssl:

Przykładowe ustawienia TLS dla Apache

Konfiguracja Apache po odcięciu starych wersji TLS sprowadza się do kilku dyrektyw w kontekście VirtualHost lub w pliku globalnym modułu mod_ssl (np. ssl.conf):

<VirtualHost *:443>
    ServerName www.example.com

    SSLEngine on
    SSLProtocol             TLSv1.2 TLSv1.3
    SSLHonorCipherOrder     on
    SSLCipherSuite          ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
                            ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
                            ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305

    SSLCertificateFile      /etc/ssl/certs/www.example.com.crt
    SSLCertificateKeyFile   /etc/ssl/private/www.example.com.key
    SSLCertificateChainFile /etc/ssl/certs/ca-chain.crt

    SSLStaplingCache        shmcb:/var/run/ocsp(128000)
    SSLUseStapling          on

    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

    # Aplikacja/VHost właściwy
    DocumentRoot /var/www/html
</VirtualHost>

Starsze wersje Apache mogą używać nieco innej składni (np. bez TLS 1.3). Po każdej zmianie dobrze jest przepuścić hosta przez SSL Labs lub podobny skaner i upewnić się, że żaden z protokołów < 1.2 nie jest już akceptowany.

Konfiguracja TLS w HAProxy i innych load balancerach

W wielu środowiskach pierwszym punktem styku z klientem nie jest sam serwer aplikacyjny, lecz load balancer. Jeśli na HAProxy / F5 / AWS ALB nadal zezwalasz na TLS 1.0/1.1, to nawet najnowocześniejszy backend niewiele pomoże.

Dla HAProxy minimalny przykład sekcji frontend może wyglądać tak:

frontend https-in
    bind *:443 ssl crt /etc/haproxy/certs/www.example.com.pem 
        alpn h2,http/1.1 
        ssl-min-ver TLSv1.2 
        ssl-max-ver TLSv1.3 
        ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
                ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
                ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305

    default_backend app-https

Warto dołożyć logowanie wersji TLS i szyfru (np. przy użyciu %sslv, %sslc w formacie logów). Dzięki temu balancer pełni rolę „centrali monitoringowej” dla całego ruchu HTTPS, a analiza klientów nie wymaga grzebania na każdym serwerze z osobna.

Serwery aplikacyjne i gRPC – Java, .NET, Node.js

Po stronie aplikacji często decyduje nie sam kod, tylko platforma uruchomieniowa i biblioteka TLS. Kilka typowych przypadków:

• Java / JVM – ograniczenie TLS po stronie serwera dokonuje się zwykle przez:
  • aktualizację JDK do wersji, w której TLS 1.3 jest wspierany (Java 11+),
  • konfigurację connectora (np. Tomcat, Jetty, Undertow) – listy protokołów i cipher suites,
  • ewentualnie parametr -Djdk.tls.client.protocols dla klientów JVM, aby wymusić TLS 1.2+ w połączeniach wychodzących.
• .NET (Core / 5+) – w nowszych wersjach domyślnie używany jest TLS 1.2+, ale w starszych aplikacjach mogą pojawiać się „przyspawane” ustawienia:
  • sprawdzenie i poprawienie ServicePointManager.SecurityProtocol,
  • w nowszych API – użycie SslProtocols.Tls12 | SslProtocols.Tls13 w konfiguracji Kestrel lub HttpClient.
• Node.js – wersja runtime’u decyduje o wspieranych protokołach; przy tworzeniu serwera HTTPS można podać:

  const server = https.createServer({
    key: fs.readFileSync('key.pem'),
    cert: fs.readFileSync('cert.pem'),
    minVersion: 'TLSv1.2',
    ciphers: 'ECDHE-ECDSA-AES256-GCM-SHA384:...'
  }, app);

W przypadku gRPC, który mocno opiera się na HTTP/2, starczy często zablokowanie TLS < 1.2 po stronie serwera – stare biblioteki gRPC-klient i tak zwykle nie wspierają HTTP/2 na przestarzałych stosach TLS, więc problem klientów „z epoki IE6” rzadko tu występuje. Wyjątkiem są wewnętrzne integracje z legacy JVM-ami.

Bezpieczne profile TLS dla API B2B

Interfejsy API dla partnerów bywają bardziej konserwatywne – tu i ówdzie ktoś jeszcze potrzebuje RSA 2048 i ma problem z ECC, bo HSM dawno wyszedł z gwarancji. Profil po wyłączeniu TLS 1.0/1.1 da się jednak zbalansować tak, by nie narobić sobie wrogów wśród partnerów i jednocześnie nie otworzyć bramy do królestwa.

Praktyczny kompromis dla endpointów B2B:

• minimalnie TLS 1.2, z planem migracji do obowiązkowego TLS 1.3 w rozsądnym horyzoncie czasowym,
• zestaw szyfrów oparty przede wszystkim na ECDHE + AES-GCM / CHACHA20-POLY1305, ale z możliwością okresowego utrzymania jednego, dwóch mocnych zestawów opartych o RSA, jeśli któryś partner nie ma jeszcze ECDSA,
• silna autoryzacja aplikacyjna (mTLS, podpisy wiadomości, OAuth2, JWT), tak aby usunięcie starych cipher suites nie było jedynym „bezpiecznikiem” integracji.

Przy większej liczbie partnerów można pokusić się o dwa profile: „modern-api.example.com” dla nowych integracji i bardziej konserwatywny „b2b.example.com” dla migracji stopniowych. Dzięki temu migracje po stronie klienckiej nie blokują strategii długofalowej.

Polityki bezpieczeństwa w nagłówkach HTTP i HTTP/2/3

Aktualizacja TLS to dobra okazja, żeby odświeżyć całą „otoczkę” bezpieczeństwa HTTP. Dla serwerów WWW i API wdrażanych tylko po HTTPS można spiąć kilka elementów:

• HSTS – wymuszenie HTTPS na poziomie przeglądarki:

  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

  Ustawienie preload tylko wtedy, gdy wszystkie subdomeny są gotowe na permanentny HTTPS.

• ALPN + HTTP/2 – konfiguracja alpn h2,http/1.1 w balancerze, aby nowoczesne przeglądarki korzystały z HTTP/2 nad TLS 1.2/1.3. Przy okazji łatwiej mierzyć, ilu klientów utknęło na starszych stosach, skoro nie są w stanie dogadać się w sprawie HTTP/2.
• HTTP/3 (QUIC) – wdrożenie na wybranych hostach pozwala dodatkowo poprawić wydajność, ale nie rozwiązuje kwestii starych TLS, bo klienci, którzy potrafią HTTP/3, i tak obsługują nowoczesne szyfrowanie.

Zmiany w nagłówkach warto wdrażać przy okazji wyłączenia starego TLS, bo i tak prosisz użytkowników o „retest” aplikacji. Jedna zmiana produkcyjna mniej w przyszłości.

Diagnostyka problemów po wyłączeniu TLS 1.0/1.1

Po odcięciu starych wersji protokołu typowe zgłoszenia brzmią: „strona się nie otwiera”, „nie działa integracja X”, „aplikacja mobilna pokazuje błąd sieci”. Tu przydaje się kilka szybkich technik diagnostycznych:

• Sprawdzenie logów serwera/balancera – wyszukanie wpisów z odrzuconym połączeniem, wersją TLS poniżej 1.2 lub brakiem wspólnego cipher suite.
• Test z poziomu klienta – na problematycznym hoście:

  openssl s_client -connect api.example.com:443 -tls1
  openssl s_client -connect api.example.com:443 -tls1_1
  openssl s_client -connect api.example.com:443 -tls1_2

  Jeśli dwa pierwsze polecenia nie działają, a trzecie działa, to konfiguracja serwera jest zgodna z planem, a problem leży po stronie klienta.

• Debug w przeglądarce – w nowoczesnych przeglądarkach można podejrzeć wersję TLS w devtools (zakładka „Security”). Jeżeli ktoś używa przeglądarki, w której takiej zakładki nie ma… to już sam w sobie jest komentarz do wieku środowiska.

Przy integracjach B2B dobrze jest przygotować krótki „playbook dla partnera” z gotowymi komendami openssl i przykładowym kodem w Javie/.NET pokazującym wymuszenie TLS 1.2. To oszczędza nerwów po obu stronach.

Monitorowanie po migracji – co obserwować w dłuższym horyzoncie

Wyłączenie TLS 1.0/1.1 to nie akcja „ustaw i zapomnij”. Przez pierwsze tygodnie i miesiące przydaje się weryfikacja kilku wskaźników:

• Rozkład wersji TLS – procentowy udział TLS 1.2 vs. 1.3 w ruchu; rosnący udział 1.3 świadczy o naturalnym odświeżaniu urządzeń po stronie klientów.
• Rozkład cipher suites – wykrycie niespodziewanego udziału starszych szyfrów (np. z SHA1), które być może zostały omyłkowo pozostawione w profilu „zgodnościowym”.
• Liczba błędów połączeń z kodami specyficznymi dla TLS – np. na poziomie proxy aplikacyjnych, gatewayów API lub WAF-ów (błędy handshake, brak wspólnych parametrów).
• Zgłoszenia z helpdesku – korelacja wzrostów liczby ticketów z datami kolejnych etapów wygaszania.

Jeśli w logach od czasu do czasu pojawi się klient próbujący TLS 1.0, a jednocześnie nie ma żadnych zgłoszeń, nie ma sensu cudownie „przywracać zgodności”. Ktoś po prostu próbuje połączyć się z przeglądarki sprzed dekady – to raczej sygnał, że najwyższy czas na upgrade po tamtej stronie.

Automatyzacja konfiguracji TLS – Ansible, Terraform, CI/CD

Ręczne poprawianie plików nginx.conf i ssl.conf na kilkunastu maszynach kończy się zwykle festiwalem niespójności. Migrację TLS dobrze jest „ubrać” w infrastrukturę jako kod:

• Wspólne role Ansible – jedna rola typu tls_hardening, która:
  • kopiuje pliki include z listą wspieranych protokołów i szyfrów,
  • restartuje odpowiednie usługi po zmianie,
  • ewentualnie uruchamia openssl s_client jako test kontrolny.
• Terraform / IaC chmurowe – profile SSL w AWS ALB / Cloudflare / GCP LB opisane w kodzie zamiast „klikania w konsoli”. Zmiana minimalnej wersji TLS staje się wtedy zwykłym terraform apply, a nie ekspedycją po panelach administracyjnych.
• Kontrola w pipeline CI – prosty krok w pipeline, który przy zmianie konfiguracji odpala skaner (np. testssl.sh lub dedykowany kontener) i blokuje wdrożenie, jeśli TLS 1.0/1.1 jest gdziekolwiek dopuszczony.

Odrobina wysiłku włożona w automatyzację często zwraca się przy następnym dużym przeglądzie bezpieczeństwa – kiedy trzeba będzie np. masowo wyłączyć SHA-1, starych krzywych EC lub dodać nowy wymóg regulacyjny.

Integracje mobilne i aplikacje desktopowe – szczególne przypadki

Najwięcej zaskoczeń po odcięciu starego TLS pojawia się zwykle przy aplikacjach „zamkniętych” – mobilnych i desktopowych, szczególnie tych rozwijanych lata temu:

• Stare SDK mobilne – aplikacje zbudowane na bardzo starych wersjach Androida/iOS potrafią używać bibliotek TLS ograniczonych do 1.0/1.1, nawet jeśli samo urządzenie jest nowsze. Dobrą praktyką jest:
  • sprawdzenie minimalnej wersji OS wspieranej przez aplikację,
  • pomiar ruchu z poszczególnych wersji (np. przez User-Agent lub telemetrykę w aplikacji),
  • zaplanowanie „end of support” dla naprawdę starych wersji systemu.
• Aplikacje desktopowe z wbudowanymi bibliotekami HTTP – jeśli w kodzie „na sztywno” osadzono np. starą wersję libcurl czy WinHTTP, aktualizacja po stronie serwera odsłoni błąd dopiero w momencie próby połączenia. Tu pomaga:
  • wypuszczenie aktualizacji aplikacji z nowym runtime’em,
  • tymczasowe skierowanie ruchu ze starych wersji (rozpoznawanych po nagłówkach/ścieżce) na legacy endpoint,
  • komunikaty w samej aplikacji, że „Ta wersja przestanie działać z końcem miesiąca”.

Jeśli liczba takich użytkowników jest marginalna, czasem bardziej racjonalne jest świadome rozstanie niż utrzymywanie starego TLS tylko po to, by kilku zapomnianych klientów mogło się raz na kwartał zalogować.

Najczęściej zadawane pytania (FAQ)

Dlaczego muszę wyłączyć TLS 1.0 i 1.1, skoro „jeszcze działają”?

Stare wersje TLS mają znane słabości kryptograficzne (m.in. podatność na BEAST, POODLE, problemy z CBC i renegocjacją) i wymagają utrzymywania słabych zestawów szyfrów. Dziś nie da się już ich sensownie obronić ani technicznie, ani przed audytorem czy ubezpieczycielem.

Dodatkowo standardy branżowe (PCI DSS i podobne) wprost wymagają porzucenia TLS 1.0/1.1, a przeglądarki oraz systemy operacyjne wypychają je z rynku. Zostawienie ich „bo działa” to trochę jak montowanie zamka na kluczyk w drzwiach do skarbca – może i się otwiera, ale nikt rozsądny nie uzna tego za właściwe zabezpieczenie.

Jakie wersje TLS powinny być włączone na serwerze w 202x roku?

Bezpieczne minimum to TLS 1.2. Docelowo konfiguracja powinna obejmować TLS 1.2 oraz TLS 1.3, z wyraźną preferencją TLS 1.3 tam, gdzie klienci go obsługują. TLS 1.0 i 1.1 należy całkowicie wyłączyć w środowiskach produkcyjnych, a jeśli już muszą istnieć, to wyłącznie w ściśle odizolowanych, tymczasowych strefach migracyjnych.

W praktyce dobre ustawienie to: TLS 1.3 jako domyślna wersja + TLS 1.2 z ograniczonym, silnym zestawem szyfrów (AEAD, ECDHE, SHA-256+). Takie podejście zapewnia bezpieczeństwo, a jednocześnie nie odcina większości realnych użytkowników.

Jakie zestawy szyfrów (cipher suites) są dziś zalecane, a co trzeba wyłączyć?

Podstawą konfiguracji powinny być nowoczesne pakiety szyfrów AEAD z Perfect Forward Secrecy, np. z AES-GCM lub ChaCha20-Poly1305 oraz ECDHE. Funkcje skrótu co najmniej SHA-256 – bez SHA-1 w nowych wdrożeniach.

Z konfiguracji warto wyrzucić bez dyskusji: RC4, 3DES/DES, IDEA, tryby CBC, pakiety „EXPORT”, Anonymous DH (ADH) oraz wymianę kluczy opartą na statycznym RSA. Dobór konkretnej listy najlepiej oprzeć na aktualnych rekomendacjach (np. Mozilla SSL Configuration Generator), zamiast kopiować przykłady z nieaktualnych blogów sprzed kilku lat.

Jak sprawdzić, którzy klienci jeszcze korzystają z TLS 1.0/1.1?

Najprościej wykorzystać logi serwera i narzędzia monitoringu. W wielu serwerach WWW i reverse proxy można włączyć logowanie wersji TLS i pakietu szyfrów, a następnie przeanalizować te dane w systemie typu ELK, Splunk czy Prometheus + Grafana. Po kilku tygodniach zbierania logów widać, ilu realnych klientów faktycznie łączy się po starych protokołach.

Dodatkowo pomagają skanery i testery TLS (np. testy SSL z zewnątrz), które pokażą, jakie wersje i zestawy szyfrów serwer aktualnie akceptuje. Nie zastąpi to jednak analizy własnych logów – tam widać np. starą aplikację mobilną klienta ważnego biznesowo, która nagle przestanie działać po „twardym odcięciu” TLS 1.0.

Jak bezpiecznie wyłączyć TLS 1.0/1.1, żeby nie „zabić” biznesu?

Najlepszy scenariusz to kilkustopniowy plan: najpierw włączenie pełnego logowania wersji TLS, potem analiza, ilu klientów korzysta z 1.0/1.1 i z jakich systemów, a następnie komunikacja do kluczowych partnerów (np. integratorów, dużych klientów B2B) z jasną datą wyłączenia. Dobrą praktyką jest też tymczasowe wyłączenie starych wersji na środowisku testowym lub ograniczonej puli serwerów i obserwacja, co się zgłasza na helpdesk.

Niektóre firmy stosują etap „soft cut”: najpierw blokują TLS 1.0/1.1 w godzinach nocnych lub na małej części ruchu i monitorują błędy po stronie klientów. Pozwala to namierzyć krytyczne integracje, zanim całość trafi na produkcję, a telefon w dziale obsługi zacznie świecić się na czerwono.

Co monitorować po wyłączeniu starego TLS, żeby szybko wychwycić problemy klientów?

Warto mieć przygotowane minimum: metryki nieudanych handshake’ów TLS (z podziałem na wersje), wzrost liczby błędów połączeń na poziomie aplikacyjnym oraz alerty na nagły spadek ruchu z określonych segmentów (np. z konkretnych adresów IP partnerów B2B). Dobrze też logować szczegóły błędów TLS, aby odróżnić problem wersji protokołu od np. złych certyfikatów.

Przydatna jest też prosta, praktyczna rzecz: gotowe krótkie komunikaty dla helpdesku i klientów, tłumaczące, dlaczego połączenie nie działa i jakie przeglądarki/systemy są wspierane. Zamiast godzinnego debugowania, konsultant może od razu powiedzieć: „Ten Windows XP z IE 8 jednak nie jest już wspierany”.

Czy pozostawienie TLS 1.0 tylko dla „kilku starych integracji” jest bezpiecznym kompromisem?

Technicznie to wciąż ryzykowne – sam fakt udostępniania usługi po TLS 1.0 oznacza podatny kanał, niezależnie od tego, jak „mało używany” on jest. Z perspektywy audytu i ubezpieczyciela taki wyjątek często wygląda jak świadome zignorowanie dobrych praktyk.

Jeżeli nie da się inaczej, jedynym sensownym podejściem jest ekstremalna segmentacja: osobna, odizolowana infrastruktura tylko dla tych integracji, dodatkowe filtry (np. ograniczenia IP, VPN), krótki, formalnie zatwierdzony plan wygaszenia i bardzo dokładny monitoring. Nawet wtedy trzeba liczyć się z tym, że przy poważniejszym incydencie taki wyjątek będzie pierwszym podejrzanym.

Najważniejsze punkty

• Utrzymywanie TLS 1.0/1.1 to dziś realne ryzyko techniczne i formalne: podatności (BEAST, POODLE, słabe CBC, RC4, 3DES) plus mocny argument dla audytorów i ubezpieczycieli, że organizacja zaniedbuje podstawy bezpieczeństwa.
• Presja regulacyjna jest twarda: PCI DSS, wymagania banków i standardów branżowych wprost wymuszają porzucenie TLS 1.0/1.1, a dalsze ich używanie grozi niezgodnością, karami i problemami przy certyfikacjach.
• Producenci przeglądarek i systemów „odjechali” dalej: nowoczesne Chrome/Firefox/Edge/Safari oraz aktualne systemy operacyjne domyślnie wspierają i preferują tylko TLS 1.2/1.3, więc trzymanie starych wersji pomaga wyłącznie garstce mocno przestarzałych, i tak niebezpiecznych klientów.
• Koszt trzymania starych TLS-ów stale rośnie: ryzyko reputacyjne, dodatkowe uwagi w raportach z audytów, potencjalne zarzuty regulatora po incydencie – a w zamian zyskujemy głównie „święty spokój” kilku zapomnianych integracji z epoki Windows XP.
• Praktyczne minimum to dziś TLS 1.2, a standard docelowy – TLS 1.3; oba są szeroko wspierane, ale TLS 1.2 wymaga świadomej konfiguracji zestawów szyfrów, żeby nie zostawić przypadkiem „trucizny” w postaci słabych algorytmów.
• Wyłączenie TLS 1.0/1.1 trzeba zaplanować jak normalny projekt: analiza wpływu na klientów, aktualizacja konfiguracji serwerów (HTTP(S), poczta, VPN itd.) oraz przygotowanie monitoringu, który szybko pokaże, kto i skąd nagle przestał się łączyć.