TLS (Transport Layer Security) to protokół kryptograficzny, który szyfruje dane przesyłane między przeglądarką użytkownika a serwerem, zapobiegając ich podsłuchaniu lub modyfikacji przez osoby trzecie. Ochrona ta opiera się na algorytmach matematycznych wymieniających klucze publiczne i prywatne, co gwarantuje, że loginy, hasła czy numery kart kredytowych pozostają nieczytelne dla hakerów.
Prawda jest zresztą absolutnie taka, że bez tego mechanizmu cały handel elektroniczny przestałby istnieć w jeden dzień. Wchodzisz na stronę banku. Wpisujesz dane. Naciskasz enter. Pakiety informacji opuszczają twój router domowy i trafiają do węzłów dostawcy internetu. Bez szyfrowania każdy pośrednik w tej drodze widzi twój ruch w postaci zwykłego tekstu. To spory problem.
Dlaczego w ogóle potrzebujemy protokołu TLS na stronach internetowych?
Protokół HTTP przesyła dane czystym tekstem. Jeżeli używasz publicznej sieci Wi-Fi w kawiarni, każdy średnio zaawansowany student informatyki z odpalonym programem Wireshark na laptopie obok może odczytać zawartość twoich pakietów. Zobaczy ciasteczka sesyjne. Przejmie twoje konto. Wdrożenie TLS rozwiązuje ten problem techniczny u samej podstawy.
Kiedy serwer wymusza połączenie przez HTTPS, do akcji wkracza warstwa Transport Layer Security. Pakiet danych zostaje zamieniony w bezużyteczny ciąg losowych znaków. Nawet jeśli ktoś go przechwyci po drodze w ataku typu Man-in-the-Middle, nie ma fizycznej możliwości odczytania zawartości bez klucza deszyfrującego. Asymetria po prostu odcina drogę do podsłuchu.
- Atakujący widzi wyłącznie fakt połączenia z konkretnym adresem IP serwera docelowego oraz objętość przesyłanych danych w bajtach, co w żaden sposób nie pozwala mu zrekonstruować przesyłanego formularza logowania czy treści wysłanej wiadomości e-mail.
- Dostawca internetu (ISP) nie ma wglądu w podstrony.
- Pakiety są podpisane cyfrowo. Zmiana choćby jednego bita w locie natychmiast zrywa połączenie z błędem w przeglądarce.
Jak dokładnie działa szyfrowanie danych w TLS?
System wykorzystuje dwa pozornie sprzeczne podejścia kryptograficzne w jednym procesie. Mamy szyfrowanie asymetryczne i symetryczne. Szyfrowanie asymetryczne pożera ogromne zasoby procesora. Używamy go więc tylko na samym początku do weryfikacji tożsamości i bezpiecznej wymiany znacznie lżejszego klucza symetrycznego. Ten drugi służy potem do szyfrowania właściwego ruchu i pobierania obrazków ze strony.
Zrobiliśmy na wdrożeniu w zeszłym miesiącu testy obciążeniowe na starych maszynach. Serwer Nginx po prostu dławił się przy próbie negocjacji asymetrycznej dla dziesięciu tysięcy użytkowników naraz. Procesory dobiły do stu procent użycia. Optymalizacja procesu wymiany kluczy uratowała ten projekt przed poniedziałkowym paraliżem.
Co się dzieje podczas procesu TLS handshake?
Zanim zobaczysz stronę na ekranie, twój komputer i serwer muszą się dogadać. To ułamek sekundy. Przebiega to według bardzo konkretnego schematu.
Przeglądarka wysyła pakiet ClientHello. Znajduje się w nim lista obsługiwanych algorytmów szyfrujących (Cipher Suites) oraz wersja protokołu. Serwer odpowiada pakietem ServerHello, wybierając najsilniejszy wspólny algorytm. Dorzuca do tego swój certyfikat cyfrowy. Twój komputer sprawdza w lokalnym magazynie zaufanych urzędów certyfikacji (CA), czy dokument jest prawdziwy. Jeśli tak, generuje tak zwany pre-master secret, szyfruje go kluczem publicznym serwera i odsyła. Serwer odkodowuje go swoim kluczem prywatnym. Obie strony generują ten sam klucz sesyjny. Startuje bezpieczny transfer.
Czym różni się starszy SSL od współczesnego TLS?
Większość ludzi w branży IT używa tych nazw zamiennie. To błąd techniczny. SSL (Secure Sockets Layer) to relikt przeszłości wymyślony przez firmę Netscape w latach dziewięćdziesiątych. SSL w wersji 1.0 nigdy nie ujrzał światła dziennego przez krytyczne luki. SSL 2.0 i 3.0 dziurawiono seryjnie w atakach takich jak POODLE. W 1999 roku organizacja IETF przejęła rozwój standardu i zmieniła nazwę na Transport Layer Security. TLS w wersji 1.0 był po prostu aktualizacją SSL 3.0.
Dzisiaj protokoły SSL są całkowicie martwe. Przeglądarki odmawiają nawiązania połączenia przy próbie ich użycia. Używamy wyłącznie TLS.
Czy certyfikat SSL to dzisiaj tak naprawdę certyfikat TLS?
Marketing wygrał z inżynierią. Firmy hostingowe nadal sprzedają produkty pod nazwą „Certyfikat SSL”. Technicznie kupujesz po prostu certyfikat X.509. Sam plik tekstowy z kluczem nie określa wersji protokołu. To oprogramowanie serwera WWW decyduje, czy użyje do niego bezpiecznego TLS 1.3, czy dziurawego SSL 3.0. Dokument poświadcza jedynie własność domeny.
Jak sprawdzić czy strona używa bezpiecznego połączenia TLS?
Klikasz w małą ikonę kłódki obok paska adresu w przeglądarce Chrome lub Firefox. Wybierasz opcję „Połączenie jest bezpieczne”, a następnie „Certyfikat jest ważny”. Zobaczysz okno z detalami technicznymi. Szukaj pola z wersją protokołu. Powinno tam widnieć TLS 1.2 lub TLS 1.3.
Możesz to zrobić profesjonalnie z poziomu terminala. Narzędzie OpenSSL daje twarde i bezlitosne dane o konfiguracji docelowej maszyny. Wpisujesz polecenie na czarnym ekranie i od razu wiesz na czym stoisz.
Jakie wersje TLS są obecnie uznawane za bezpieczne?
Świat kryptografii dzieli się dzisiaj na dwa standardy. TLS 1.2 oraz TLS 1.3. Starsze wersje to proszenie się o kłopoty. TLS 1.2 wprowadzono w 2008 roku i po wycięciu słabych algorytmów nadal trzyma się mocno. TLS 1.3 to nowość z 2018 roku, która mocno zmieniła zasady gry na rynku sieciowym.
Nowa wersja obcina proces „handshake” o połowę. W TLS 1.2 serwer i klient musieli wymienić komunikaty dwukrotnie (2-RTT). TLS 1.3 robi to w jednym przebiegu (1-RTT). A dla powracających klientów wprowadza mechanizm 0-RTT, wznawiając sesję natychmiastowo. To daje mierzalny zysk wydajnościowy dla aplikacji mobilnych działających na wolnych łączach komórkowych.
| Cecha | TLS 1.2 | TLS 1.3 |
| Szybkość negocjacji | Dwa cykle (2-RTT) | Jeden cykl (1-RTT) lub zerowy (0-RTT) |
| Przestarzałe szyfry | Obsługiwane z powodów kompatybilności | Całkowicie usunięte z kodu |
| Poufność przekazywania (PFS) | Opcjonalna w konfiguracji | Wymuszona dla każdego połączenia |
Dlaczego musieliśmy wyłączyć TLS 1.0 i 1.1?
Zarząd po prostu WYMUSIŁ powrót do starszej wersji TLS 1.0 na jednym z naszych portali we wtorek. Starsze aplikacje z Androida 4.4 rzucały błędem. Walczyliśmy z tym do świtu. Tłumaczyłem im, że te protokoły opierają się na funkcjach skrótu MD5 i SHA-1. Ich złamanie zajmuje dzisiaj wynajętym serwerom w chmurze kilkadziesiąt minut. Koniec końców utrzymaliśmy blokadę, bo ryzyko wycieku bazy klientów przewyższyło zyski ze starych urządzeń.
Usterki w TLS 1.0 to nie są teoretyczne rozważania akademickie. Atak BEAST wykorzystywał luki w trybie CBC szyfrów blokowych. Atakujący wstrzykiwał złośliwy kod w przeglądarkę i deszyfrował ciasteczka sesyjne bit po bicie. Przemysł płatniczy (PCI DSS) zakazał używania tych protokołów już w 2018 roku.
Wdrożenie TLS na serwerze z perspektywy administratora
Dobrym pomysłem jest zacząć od darmowych rozwiązań. Let’s Encrypt daje certyfikaty na 90 dni i odnawia je automatycznie przez bota Certbot. Konfiguracja w Nginx wymaga edycji jednego pliku tekstowego i dodania dyrektyw ssl_certificate oraz ssl_certificate_key. To zajmuje trzy minuty na czystym systemie.
Później zaczynają się schody. Trzeba ustawić Cipher Suites. Wrzucasz do konfigu długi ciąg niezrozumiałych znaków definiujących priorytety szyfrów. Wymuszasz krzywe eliptyczne. Wyłączasz wsparcie dla starych metod kompresji podatnych na atak CRIME.
Bez mała prawie osiemdziesiąt procent ruchu w sieci w Polsce jest obecnie szyfrowane poprawnie. Reszta to porzucone strony i stare panele administracyjne z routerów wystawione na świat publiczny. Szukamy ich przez Shodan i łapiemy się za głowę.
Jakie błędy najczęściej popełniamy przy konfiguracji certyfikatów?
Zapominamy o łańcuchu pośrednim. Serwer wysyła klientowi sam certyfikat domeny, bez certyfikatów urzędów pośredniczących (Intermediate CA). Przeglądarka na komputerze stacjonarnym może to zignorować, bo ma szeroką bazę. Mobilny Chrome na tanim telefonie wyrzuci błąd bezpieczeństwa i odetnie użytkownika od sklepu.
Zostawiamy włączone stare wersje protokołów ze strachu przed utratą ruchu. Chociaż prawdę mówiąc brakuje nam twardych danych logowania z wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem rynku. Brak nagłówka HSTS pozwala na ataki typu downgrade, zmuszając serwer do rozmowy w nieszyfrowanym HTTP. Złodziej przechwytuje sesję zanim zdążysz wymusić TLS.
Zaloguj się na swój serwer i odpal zewnętrzny skaner SSL Labs przeciwko własnej domenie. Napraw to, co świeci się na czerwono. Zrób to jeszcze dzisiaj przed końcem zmiany.
Najczęściej zadawane pytania (FAQ)
- Co to jest protokół TLS?
TLS to protokół kryptograficzny zapewniający poufność i integralność danych przesyłanych w internecie między klientem a serwerem. - Jaka jest różnica między SSL a TLS?
SSL to stara, dziurawa technologia z lat 90. TLS to jej nowoczesny, bezpieczny następca. Obecnie używamy wyłącznie TLS, choć nazwa SSL wciąż funkcjonuje w marketingu. - Czy wersja TLS 1.0 jest bezpieczna?
Nie. Wersje 1.0 i 1.1 posiadają krytyczne błędy architektoniczne i są wycofane przez wszystkie nowoczesne przeglądarki i standardy płatnicze. - Skąd wziąć certyfikat TLS na stronę?
Można go wygenerować za darmo korzystając z urzędu Let’s Encrypt lub kupić u komercyjnego dostawcy hostingu i usług IT. - Ile czasu trwa nawiązanie połączenia TLS 1.3?
Wymaga zaledwie jednego cyklu wymiany komunikatów (1-RTT), co znacznie skraca czas ładowania strony w porównaniu do TLS 1.2. - Co to jest asymetryczna wymiana kluczy w TLS?
To proces startowy, w którym przeglądarka używa publicznego klucza serwera do bezpiecznego przekazania lekkiego klucza symetrycznego, który obsłuży resztę ruchu.
Bibliografia
1. CERT Polska – https://cert.pl
2. Internet Engineering Task Force (IETF) – https://www.ietf.org
3. NASK – https://www.nask.pl
4. Mozilla Foundation – https://www.mozilla.org
5. Let’s Encrypt – https://letsencrypt.org
