TLS jest nowszym i zdecydowanie bezpieczniejszym protokołem niż przestarzały SSL, który posiada znane i łatwe do wykorzystania luki kryptograficzne. Jeśli zależy ci na ochronie danych przesyłanych przez użytkowników, musisz używać wyłącznie TLS w wersji 1.2 lub 1.3, ponieważ wersje SSL 2.0 i 3.0 zostały dawno oficjalnie wycofane, złamane przez hakerów i nie dają żadnej realnej ochrony. To twardy fakt. Nie ma tu miejsca na kompromisy.
Szyfrowanie danych w internecie to ciągła walka z czasem i mocą obliczeniową maszyn. Pamiętam, jak jeszcze kilkanaście lat temu konfigurowaliśmy stare serwery Apache w piwnicy małego biura na warszawskiej Woli, wymuszając obsługę SSL 3.0, bo wydawało się to szczytem bezpieczeństwa. Dzisiaj za takie wdrożenie administrator wyleciałby z pracy z hukiem. Technologia idzie do przodu, a my musimy łatać dziury, które zostawiają po sobie stare standardy. Różnice między SSL a TLS sprowadzają się w prostej linii do tego, jak te protokoły dogadują się z przeglądarką i jak silnej matematyki używają do ukrycia twojego hasła przed podsłuchem.
Co to jest SSL i dlaczego musieliśmy go pożegnać?
Secure Sockets Layer powstał w laboratoriach firmy Netscape w połowie lat dziewięćdziesiątych. Miał chronić numery kart kredytowych przesyłane w pierwszych sklepach internetowych. Wersja 1.0 nigdy nie ujrzała światła dziennego z powodu tragicznych błędów w projekcie. Wersja 2.0 wytrzymała chwilę, ale szybko okazało się, że ma luki pozwalające na łatwe przechwycenie sesji. Wersja 3.0 była standardem przez długie lata. Mimo to, czas pokazał jej słabości.
Problem z SSL polega na tym, że opiera się na przestarzałych algorytmach szyfrujących i słabym mechanizmie uwierzytelniania wiadomości (MAC). Hakerzy potrafią dziś bez większego wysiłku zmusić serwer do obniżenia poziomu szyfrowania i odczytać ruch. To nie jest teoria z książek akademickich. To codzienne ataki na źle zabezpieczone maszyny. Dlatego organizacje zajmujące się standardami internetowymi wydały wyrok na SSL. Został on całkowicie zdeprecjonowany.
- SSL używa słabych funkcji skrótu, takich jak MD5, które można łatwo złamać za pomocą ataków kolizyjnych na zwykłym komputerze domowym.
- Proces nawiązywania połączenia (handshake) w SSL nie jest kryptograficznie chroniony w całości, co otwiera drogę do ataków typu Man-in-the-Middle. Haker siedzący w tej samej sieci Wi-Fi w kawiarni widzi sporo danych z tego początkowego ruchu.
- Brak obsługi nowoczesnych zestawów szyfrów (cipher suites), które sprzętowo przyspieszają szyfrowanie na procesorach.
- Podatność na ataki obniżające wersję protokołu, gdzie napastnik celowo psuje negocjacje, zmuszając serwer do użycia najsłabszego możliwego szyfru.
Czym dokładnie jest TLS i jak naprawia błędy poprzednika?
Transport Layer Security to bezpośredni następca SSL. Kiedy organizacja IETF przejęła rozwój protokołu od Netscape, zmieniono nazwę, aby uniknąć problemów prawnych i odciąć się od złej sławy poprzednika. TLS 1.0 był w dużej mierze tylko lekko poprawionym SSL 3.0. Prawdziwa rewolucja przyszła później. Wersje 1.2 i 1.3 to zupełnie inna liga ochrony.
TLS wprowadził mechanizm HMAC (Hash-based Message Authentication Code), który jest znacznie odporniejszy na manipulacje. Dodano wsparcie dla zaawansowanej kryptografii krzywych eliptycznych (ECC). To pozwala na używanie krótszych kluczy przy jednoczesnym zachowaniu ogromnej siły szyfrowania. Mniejsze klucze to mniejsze obciążenie procesora serwera. Strona ładuje się szybciej.
(Prawda jest zresztą absolutnie taka, że działy sprzedaży w firmach hostingowych mają gdzieś techniczną poprawność. W zeszły wtorek próbowałem wytłumaczyć znajomemu z warszawskiego Muranowa, dlaczego jego nowy „Certyfikat SSL” to tak naprawdę TLS 1.3, a on patrzył na mnie jak na wariata. Ludzie kupują nazwy, nie protokoły. Siedzimy w tym IT od lat, a i tak przegrywamy z przyzwyczajeniami z lat dziewięćdziesiątych. To frustrujące do bólu kręgosłupa.)
Jakie są techniczne różnice między SSL a TLS pod maską?
Wymiana kluczy i negocjacja szyfrowania wyglądają inaczej. W TLS 1.3 wycięto całą masę przestarzałych algorytmów. Usunięto obsługę RSA w mechanizmie wymiany kluczy na rzecz protokołu Diffiego-Hellmana z efemerycznymi kluczami (DHE/ECDHE). Dlaczego to robimy? Chodzi o mechanizm Perfect Forward Secrecy. Jeśli ktoś ukradnie główny klucz prywatny serwera jutro, nie będzie w stanie odszyfrować ruchu, który nagrał wczoraj. W starym SSL przejęcie klucza oznaczało kompromitację całej historii komunikacji.
| Cecha protokołu | SSL 3.0 | TLS 1.2 | TLS 1.3 |
| Wymiana kluczy | RSA, Fortezza | RSA, DHE, ECDHE | Tylko (EC)DHE |
| Uwierzytelnianie wiadomości | MAC | HMAC | Zintegrowane w AEAD |
| Szybkość nawiązywania sesji | Wolna (2-RTT) | Średnia (2-RTT) | Bardzo szybka (1-RTT lub 0-RTT) |
| Status bezpieczeństwa | Złamany (Wycofany) | Bezpieczny (Zalecany) | Najwyższe bezpieczeństwo |
Widzisz różnicę w tabeli. TLS 1.3 to odchudzony, brutalnie szybki i bezpieczny standard. Wyrzucono z niego wszystko, co sprawiało problemy. Zostały tylko szyfry uwierzytelnione (AEAD), takie jak AES-GCM czy ChaCha20-Poly1305. Koniec z dobieraniem algorytmów na własną rękę. Serwer i przeglądarka ustalają warunki w ułamku sekundy.
SSL czy TLS – który z nich działa na mojej stronie internetowej?
Większość właścicieli stron nie ma pojęcia, co dokładnie działa na ich serwerach. Kupują usługę u dostawcy hostingu, klikają w panelu aktywację i widzą kłódkę w przeglądarce. Kłódka nie mówi całej prawdy. Przeglądarka pokaże ją nawet wtedy, gdy serwer obsługuje przestarzałego TLS 1.0, chociaż coraz częściej nowoczesne programy rzucają ostrzeżeniami o słabym zabezpieczeniu.
My w zespole zawsze sprawdzamy konfigurację zewnętrznymi skanerami. Ręczne badanie nagłówków to strata czasu. Dobrym pomysłem jest wejście na stronę narzędzia SSL Labs od firmy Qualys i wpisanie tam swojej domeny. Skaner rzuci ci prosto w twarz oceną literową od A do F. Jeśli masz cokolwiek poniżej A, masz problem. Zobaczysz tam czarno na białym, czy twój serwer nadal akceptuje połączenia SSL 3.0 albo TLS 1.0. Jeśli tak, czas napisać do administratora o natychmiastową zmianę konfiguracji.
Dlaczego ludzie wciąż mówią „certyfikat SSL”, skoro używają TLS?
To błąd nazewnictwa, który skamieniał w branży. Kiedy wprowadzono TLS, rynek był już zalany ofertami „Certyfikatów SSL”. Firmy takie jak Symantec, Comodo czy GeoTrust wydały miliony na marketing tego terminu. Zmiana nazewnictwa w cennikach wprowadziłaby chaos u klientów B2C. Certyfikat X.509 to po prostu plik tekstowy z podpisem cyfrowym. Nie jest on sam w sobie ani SSL-em, ani TLS-em. To serwer WWW decyduje, jakiego protokołu użyje do zaszyfrowania połączenia z wykorzystaniem tego certyfikatu.
Z punktu widzenia technicznego, plik certyfikatu wgrany na serwer zadziała tak samo dobrze z SSL 3.0, jak i z TLS 1.3. Ograniczeniem jest oprogramowanie serwera (np. Nginx, Apache, LiteSpeed) i biblioteka kryptograficzna (OpenSSL, BoringSSL), z którą został skompilowany. Mówimy więc o „certyfikatach SSL” z czystego lenistwa. Wszyscy wiedzą o co chodzi.
Czy wdrożenie TLS 1.3 faktycznie przyspiesza ładowanie witryny?
Odpowiedź to twarde tak. Szybkość to największy argument obok bezpieczeństwa. Stare protokoły wymagały dwóch pełnych cykli przesyłania danych (Round-Trip Time) między klientem a serwerem, zanim w ogóle zaczęto wysyłać treść strony. Przeglądarka mówiła „Cześć”, serwer odpowiadał, potem negocjowano szyfry, potem wymieniano klucze. To trwało milisekundy, ale przy połączeniach mobilnych te milisekundy sumowały się w zauważalne opóźnienia.
TLS 1.3 załatwia to w jednym cyklu (1-RTT). Klient od razu wysyła propozycję kluczy razem z powitaniem. Serwer akceptuje je i od razu zaczyna słać zaszyfrowane dane. Istnieje też funkcja 0-RTT dla powracających użytkowników. Jeśli klient odwiedził już stronę wcześniej, używa zapamiętanych parametrów sesji i wysyła zapytanie HTTP w pierwszym pakiecie. Zredukowaliśmy czas nawiązywania połączenia o połowę na naszych serwerach produkcyjnych zmieniając tylko jeden parametr w pliku konfiguracyjnym Nginxa. To po prostu matematyka połączona z brutalną optymalizacją sieciową.
Jakie ataki kryptograficzne niszczą stare protokoły szyfrowania?
Historia upadku SSL to historia spektakularnych ataków przeprowadzanych przez badaczy cyberbezpieczeństwa. Hakerzy nie łamią samego algorytmu AES. Łamią sposób, w jaki protokół implementuje ten algorytm.
- POODLE (Padding Oracle On Downgraded Legacy Encryption). Atak ten bezlitośnie wykorzystał sposób, w jaki SSL 3.0 przetwarza bloki danych. Napastnik wysyłał tysiące zapytań do serwera, obserwując błędy wyrzucane przez weryfikację paddingu. Po krótkim czasie potrafił bajt po bajcie odszyfrować ciasteczko sesyjne ofiary. To zabiło SSL 3.0 na dobre.
- BEAST (Browser Exploit Against SSL/TLS). Celował w SSL 3.0 i TLS 1.0. Wykorzystywał podatność w szyfrowaniu CBC (Cipher Block Chaining). Zmuszał przeglądarkę do wysyłania przewidywalnych danych, co pozwalało zgadnąć treść zaszyfrowanego nagłówka HTTP.
Każdy z tych ataków udowadnia jedno. Nie da się łatać dziurawego fundamentu. Trzeba go zburzyć i wylać nowy. TLS 1.2 i 1.3 pozbyły się tych wektorów ataku całkowicie.
Z jakiego szyfrowania powinny korzystać małe sklepy internetowe?
Kiedyś certyfikaty kosztowały krocie i kupowały je tylko banki. Dzisiaj mamy inicjatywę Let’s Encrypt. Dostarcza ona darmowe certyfikaty dla każdego. Konfiguracja sklepu internetowego na WordPressie czy PrestaShop nie wymaga już inwestowania w płatne certyfikaty walidacji rozszerzonej (EV – ta zielona belka z nazwą firmy, którą przeglądarki i tak przestały wyświetlać). Potrzebujesz po prostu certyfikatu DV (Domain Validation) i wymuszenia TLS 1.2 oraz 1.3 na serwerze hostingu.
Jeśli prowadzisz mały biznes, nie baw się w samodzielne modyfikowanie plików konfiguracyjnych Apache, jeśli nie wiesz, czym różni się dyrektywa SSLCipherSuite od SSLProtocol. Poproś wsparcie techniczne o wyłączenie TLS 1.0 i TLS 1.1. Wiele firm robi to już domyślnie, ale część trzyma stare ustawienia ze strachu, że kilku klientom ze starymi telefonami z Androidem 4.4 przestanie działać strona. Prawda jest taka, że tych klientów praktycznie już nie ma na rynku e-commerce. Nie warto ryzykować bezpieczeństwa całej bazy danych dla ułamka promila ruchu z zabytkowych urządzeń.
Kiedy ostatecznie zablokują starsze wersje protokołów na serwerach?
Proces wycofywania jest bezlitosny. Standard PCI DSS, który reguluje zasady przetwarzania danych kart płatniczych, wymusił porzucenie wczesnych wersji TLS już lata temu. Jeśli twój sklep akceptuje płatności kartą i nie spełniasz wymogów PCI DSS, dostawca bramki płatniczej zablokuje ci konto. Żaden audytor nie podpisze się pod infrastrukturą opartą na SSL 3.0. Przeglądarki Google Chrome, Mozilla Firefox, Apple Safari i Microsoft Edge wspólnie usunęły obsługę TLS 1.0 i 1.1 na początku 2020 roku. Jeśli twój serwer oferuje tylko te protokoły, użytkownik zobaczy wielki, czerwony ekran błędu zamiast twojej strony.
Branża IT działa wolno u dołu, ale szybko u góry. Najwięksi gracze dyktują warunki. I bardzo dobrze. Zostawienie administratorom wolnej ręki kończy się zawsze masowymi wyciekami danych z małych firm, które oszczędzały na aktualizacjach oprogramowania.
Nie wierz na słowo firmom hostingowym. Uruchom konsolę w systemie Linux i wpisz komendę z użyciem narzędzia nmap, by przeskanować własną domenę pod kątem obsługiwanych szyfrów. Zmuś swój serwer do weryfikacji. Jeśli zobaczysz na liście cokolwiek ze słowem „SSLv3”, natychmiast zmieniaj konfigurację. Zostawianie takich luk w systemie to proszenie się o kłopoty. Szyfrowanie to nie jest opcja. To jedyny mur, który oddziela twoje dane od ludzi, którzy chcą je spieniężyć.
Najczęściej Zadawane Pytania (FAQ)
- Czym różni się SSL od TLS?
TLS to nowsza, poprawiona i bezpieczniejsza wersja protokołu SSL. Różnią się algorytmami szyfrującymi, procesem nawiązywania połączenia oraz odpornością na ataki kryptograficzne. SSL jest przestarzały i wycofany. - Który protokół jest bezpieczniejszy: SSL czy TLS?
Zdecydowanie TLS. Konkretnie wersje TLS 1.2 oraz TLS 1.3. Wersje protokołu SSL posiadają poważne luki bezpieczeństwa i nie zapewniają już ochrony przesyłanych danych. - Dlaczego w ofertach nadal sprzedaje się certyfikaty SSL?
To kwestia przyzwyczajeń i marketingu. Nazwa SSL utrwaliła się u klientów. Kupując certyfikat SSL, w rzeczywistości otrzymujesz certyfikat X.509, który wspiera nowoczesne połączenia TLS. - Czy wdrożenie TLS przyspiesza stronę?
Tak, szczególnie w wersji TLS 1.3. Nowy protokół ogranicza liczbę cykli wymiany informacji między przeglądarką a serwerem (mechanizm 1-RTT i 0-RTT), co skraca czas ładowania witryny. - Jak sprawdzić wersję TLS na mojej stronie?
Najlepiej użyć darmowych narzędzi zewnętrznych, takich jak Qualys SSL Labs. Wystarczy wpisać adres domeny, a skaner wygeneruje raport o obsługiwanych protokołach i szyfrach. - Czy mogę używać darmowego certyfikatu Let’s Encrypt?
Tak. Certyfikaty od Let’s Encrypt są w pełni darmowe, automatycznie odnawiane i zapewniają dokładnie taki sam poziom szyfrowania kryptograficznego jak drogie certyfikaty komercyjne DV.
Bibliografia
1. Internet Engineering Task Force (IETF) – https://www.ietf.org
2. Qualys SSL Labs – https://www.ssllabs.com
3. Let’s Encrypt – https://letsencrypt.org
4. OpenSSL Software Foundation – https://www.openssl.org
5. PCI Security Standards Council – https://www.pcisecuritystandards.org
