Poprawna konfiguracja HTTPS/TLS w 2026 roku

Poprawne wdrożenie TLS to już nie kwestia "posiadania kłódki". W 2026 roku bezpieczne HTTPS oznacza usunięcie przestarzałych wersji protokołu, ograniczenie się do nowoczesnych zestawów szyfrów z forward secrecy oraz połączenie warstwy transportowej z nagłówkami HTTP, które blokują ataki downgrade i mixed-content. Ten przewodnik opiera się na rekomendacjach Mozilla Server Side TLS oraz NIST SP 800-52 Rev. 2 i jest napisany tak, by trafić wprost do zgłoszenia hardeningowego.

Wyłącz TLS 1.0 i 1.1 — i większość balastu TLS 1.2

TLS 1.0 i 1.1 zostały formalnie wycofane przez RFC 8996 w 2021 roku. Opierają się na konstrukcjach MD5/SHA-1 w PRF i dopuszczają zestawy szyfrów (RC4, CBC z niejawnymi IV) podatne na BEAST, POODLE (CVE-2014-3566) i Lucky 13. PCI DSS zakazuje ich od lat, a wszystkie główne przeglądarki usunęły ich obsługę w 2020 roku. Nie ma już argumentu o kompatybilności wartego tego ryzyka: klient, który nie obsługuje TLS 1.2, nie obsługuje też nowoczesnej kryptografii webowej.

Twoją bazą powinno być TLS 1.2 jako minimum i TLS 1.3 jako preferowane. NIST SP 800-52r2 wymaga wsparcia TLS 1.2 i rekomenduje TLS 1.3. Profil "Intermediate" Mozilli celuje dokładnie w tę parę; profil "Modern" to wyłącznie TLS 1.3 i sprawdza się, gdy kontrolujesz bazę klientów (API wewnętrzne, aplikacje mobilne).

Preferuj TLS 1.3

TLS 1.3 (RFC 8446) to nie drobna aktualizacja — usuwa całą klasę niebezpiecznych opcji. Statyczna wymiana kluczy RSA znika, więc forward secrecy jest obowiązkowe. Usunięto renegocjację, kompresję (co eliminuje CRIME) oraz przestarzałe zestawy CBC. Uścisk dłoni trwa jedną rundę (1-RTT), z opcjonalnym 0-RTT dla wznowień, i jest w większości szyfrowany. Dopuszczone zestawy AEAD to praktycznie TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 i TLS_CHACHA20_POLY1305_SHA256. Jeśli miałbyś zrobić tylko jedno, włączenie TLS 1.3 daje największy pojedynczy wzrost bezpieczeństwa.

Forward secrecy i dobór szyfrów

W TLS 1.2 musisz jawnie wybrać efemeryczną wymianę kluczy: preferuj ECDHE (krzywa X25519 lub secp256r1) z AES-GCM lub ChaCha20-Poly1305. Wyłącz statyczne RSA, w miarę możliwości wszystkie zestawy CBC oraz cokolwiek z RC4, 3DES lub parametrami eksportowymi. Forward secrecy gwarantuje, że przyszłe przejęcie klucza prywatnego serwera nie pozwoli odszyfrować wczorajszego przechwyconego ruchu — to bezpośrednia obrona przed przeciwnikami typu "harvest now, decrypt later".

• Certyfikaty: klucze ECDSA P-256 są mniejsze i szybsze niż RSA-2048; udostępniaj oba, jeśli potrzebujesz szerokiej kompatybilności.
• Rozmiar klucza: minimum RSA 2048 bitów, ECDSA 256 bitów, zgodnie z NIST 800-52r2.
• Krzywe: oferuj najpierw X25519, potem secp256r1.

HSTS i preloading

HTTP Strict Transport Security (RFC 6797) każe przeglądarkom łączyć się wyłącznie przez HTTPS, udaremniając ataki SSL-stripping typu man-in-the-middle, jak te z użyciem sslstrip. Produkcyjny nagłówek wygląda tak:

• Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Użyj dwuletniej wartości max-age. Dodaj includeSubDomains dopiero, gdy masz pewność, że każda subdomena serwuje HTTPS — jest to absolutne. Token preload wraz ze zgłoszeniem na hstspreload.org wpisuje domenę na wbudowaną w przeglądarki listę HSTS, chroniąc nawet pierwsze odwiedziny. Preload jest praktycznie trwały i wolny do cofnięcia, więc traktuj go jak drzwi jednokierunkowe i najpierw wszystko przetestuj.

OCSP stapling

Tradycyjne sprawdzanie unieważnień certyfikatów ujawnia CA odwiedzane strony i dodaje opóźnienie. OCSP stapling (rozszerzenie TLS Certificate Status Request) sprawia, że serwer pobiera i buforuje podpisaną przez CA, oznaczoną czasem odpowiedź OCSP i dołącza ją do uścisku dłoni. Klient otrzymuje świeży dowód unieważnienia bez dodatkowego połączenia. Włącz to (ssl_stapling on w nginx) i połącz z OCSP Must-Staple na certyfikacie, jeśli CA to obsługuje — brak staple staje się wtedy twardym błędem, domykając lukę soft-fail, przez którą klasyczne OCSP było niemal bezużyteczne.

Wyeliminuj mixed content

Strona HTTPS ładująca skrypt, arkusz stylów lub iframe przez HTTP to aktywny mixed content — przeglądarki go blokują i słusznie, bo przywraca dokładnie to ryzyko wstrzyknięcia, które HTTPS usuwało. Pasywny mixed content (obrazy, media) jest blokowany lub automatycznie podnoszony. Napraw to u źródła, a potem wymuś:

• Content-Security-Policy: upgrade-insecure-requests automatycznie przepisuje adresy podzasobów http:// na https://.
• Dodaj block-all-mixed-content jako twarde zabezpieczenie dla tego, czego nie da się podnieść.

Nagłówki, które domykają całość

TLS zabezpiecza rurę; te nagłówki zabezpieczają to, co przez nią płynie. Minimalny utwardzony zestaw:

• Content-Security-Policy — główna obrona przed XSS (OWASP A03:2021 – Injection). Zacznij od polityki report-only, potem wymuś politykę skryptów opartą na nonce/hash.
• X-Content-Type-Options: nosniff — blokuje zgadywanie typu MIME.
• Referrer-Policy: strict-origin-when-cross-origin — zapobiega wyciekowi pełnych URL-i między witrynami.
• Cross-Origin-Opener-Policy i Cross-Origin-Resource-Policy — izolują kontekst przeglądania i łagodzą kanały boczne klasy Spectre.
• Ustaw flagi Secure i HttpOnly oraz SameSite na każdym ciasteczku sesyjnym.

Pamiętaj, że X-Frame-Options jest dziś zastąpiony przez dyrektywę frame-ancestors z CSP w obronie przed clickjackingiem; w trakcie migracji wysyłaj oba.

Weryfikuj, nie zakładaj

Konfiguracja się rozjeżdża. Sprawdzaj każdą zmianę w SSL Labs Server Test (celuj w A+), Mozilla Observatory oraz testssl.sh w CI. Potwierdź próg protokołu przez nmap --script ssl-enum-ciphers. Odnieś wyniki do OWASP ASVS V9 (Komunikacja), by dowody trafiły do ścieżki audytowej. TLS to kontrola, którą można precyzyjnie zmierzyć — więc mierz ją regularnie i alarmuj przy regresji.