SSL/TLS — co to jest, protokoły i zasada działania szyfrowania

Co to jest SSL/TLS?

SSL (Secure Sockets Layer) — to protokół opracowany przez firmę Netscape w 1995 roku do ochrony ruchu internetowego. Pierwsza wersja SSL 1.0 nigdy nie została opublikowana, SSL 2.0 (1995) i SSL 3.0 (1996) były używane do początku lat 2000., ale zawierały krytyczne luki bezpieczeństwa. Na miejsce SSL-a przyszedł TLS (Transport Layer Security) — ulepszona wersja zestandaryzowana przez IETF. TLS 1.0 (1999) został oparty na SSL 3.0, a kolejne wersje TLS 1.1 (2006), TLS 1.2 (2008) i TLS 1.3 (2018) stopniowo odchodziły od oryginalnej architektury, dodając nowe algorytmy szyfrowania i eliminując luki. Dziś SSL jest uważany za przestarzały, a wszystkie nowoczesne systemy używają TLS, choć z przyzwyczajenia oba protokoły często są wymieniane razem jako SSL/TLS.

Historia powstania protokołu

Historia SSL/TLS rozpoczęła się od potrzeby bezpiecznej transmisji danych we wczesnej erze internetu. W 1994 roku firma Netscape opracowała SSL 1.0 dla swojej przeglądarki Navigator, ale protokół nigdy nie został opublikowany z powodu poważnych problemów bezpieczeństwa. SSL 2.0 został wydany w 1995 roku i był używany w praktyce, jednak zawierał wiele luk: brak ochrony przed atakami Man-in-the-Middle, słabe algorytmy szyfrowania i podatność na ataki typu truncation. SSL 3.0 (1996) naprawił większość problemów, ale do 2014 roku odkryto w nim lukę POODLE, po czym IETF oficjalnie uznała wszystkie wersje SSL za przestarzałe. TLS 1.0–1.3 sukcesywnie poprawiały siłę kryptograficzną, wydajność i poufność, przy czym TLS 1.3 skrócił handshake z dwóch round-trip do jednego, co jest krytyczne dla aplikacji mobilnych z niestabilnym połączeniem.

Jak działa SSL/TLS Handshake

Handshake — to proces nawiązywania bezpiecznego połączenia między klientem a serwerem. Składa się z kilku następujących po sobie kroków, podczas których strony uzgadniają wersję protokołu, wybierają algorytmy szyfrowania, wymieniają klucze i uwierzytelniają się nawzajem. W TLS 1.3 handshake zajmuje tylko jedną interakcję sieciową (1-RTT), podczas gdy w TLS 1.2 wymagał dwóch (2-RTT).

Pierwszym krokiem klient wysyła ClientHello — wiadomość zawierającą listę obsługiwanych wersji TLS, zestaw szyfrów (cipher suites) i liczbę losową. Serwer odpowiada ServerHello z wybraną wersją i szyfrem, swoim certyfikatem X.509 i podpisem cyfrowym. Klient weryfikuje certyfikat poprzez łańcuch urzędów certyfikacji (CA), generuje klucz sesyjny i wysyła go zaszyfrowanego kluczem publicznym serwera z certyfikatu. Po potwierdzeniu przez serwer rozpoczyna się bezpieczna transmisja danych. Cały handshake wykonuje się w ciągu 1–3 milisekund na nowoczesnych urządzeniach, co czyni go niewidocznym dla użytkownika.

Certyfikaty X.509 i łańcuch zaufania

Podstawą uwierzytelniania TLS jest infrastruktura klucza publicznego (PKI) zbudowana na certyfikatach formatu X.509. Każdy certyfikat zawiera: nazwę domeny (Common Name lub Subject Alternative Name), klucz publiczny serwera, nazwę wystawcy (Certificate Authority), okres ważności i podpis cyfrowy CA. Klient weryfikuje certyfikat serwera poprzez łańcuch zaufania: od certyfikatu serwera do głównego CA, którego certyfikat jest wbudowany w system operacyjny. Na urządzeniach Android główne certyfikaty są przechowywane w magazynie systemowym, aktualizowanym przez Google Play Services; w iOS — przez iOS Updates. W przypadku naruszenia któregokolwiek ogniwa łańcucha (przeterminowany certyfikat, niezgodność domeny, nieznany CA) klient zrywa połączenie. Dla certyfikatów samopodpisanych (używanych w rozwoju) wymagane jest jawne zaufanie — w Android przez Network Security Config, w iOS przez NSExceptionDomains w Info.plist. Proces walidacji łańcucha certyfikatów obejmuje również sprawdzanie statusu unieważnienia przez CRL (Certificate Revocation List) lub OCSP (Online Certificate Status Protocol), choć na urządzeniach mobilnych zapytania OCSP są często pomijane w celu przyspieszenia połączenia — jest to kompromis między bezpieczeństwem a wydajnością, który architekci powinni wziąć pod uwagę.

SSL vs TLS: kluczowe różnice

Chociaż terminy SSL i TLS są często używane zamiennie, istnieją między nimi zasadnicze różnice techniczne, które wpływają na bezpieczeństwo i wydajność aplikacji mobilnych.

Główna różnica TLS 1.3 od poprzedników — obowiązkowe użycie Perfect Forward Secrecy (PFS) poprzez protokół ECDHE. Oznacza to, że nawet jeśli atakujący uzyska dostęp do klucza prywatnego serwera, nie będzie mógł odszyfrować wcześniej przechwyconego ruchu. Dla aplikacji mobilnych, gdzie włamanie na serwer stanowi realne zagrożenie, TLS 1.3 z PFS jest obowiązkowym wymogiem bezpieczeństwa.

Znane luki w starszych wersjach

Starsze wersje SSL i TLS mają udokumentowane luki bezpieczeństwa, które czynią je nieodpowiednimi do użytku produkcyjnego. POODLE (CVE-2014-3566) atakuje SSL 3.0 przez padding oracle, umożliwiając odszyfrowanie ciasteczka sesji w 256 żądaniach. BEAST (CVE-2011-3389) wykorzystuje lukę TLS 1.0 w trybie CBC przez przewidywalny IV. Heartbleed (CVE-2014-0160) — to nie luka protokołu, ale błąd w implementacji OpenSSL, umożliwiający odczyt pamięci serwera: według Netcraft, w 2014 roku podatnych było ponad 500 tysięcy serwerów. Począwszy od Android 10 (API 29) i iOS 13, wszystkie wymienione protokoły są wyłączone na poziomie systemu. Niemniej jednak, programiści powinni sprawdzać konfigurację serwera przez SSL Labs Test (qualys.com) przed uruchomieniem aplikacji, aby upewnić się, że nie ma przestarzałych cipher suites i że TLS 1.3 jest obsługiwany.

Jak SSL/TLS chroni dane w aplikacjach mobilnych

W aplikacjach mobilnych TLS chroni dane na trzech poziomach: szyfrowanie treści (nikt oprócz serwera nie może odczytać danych), sprawdzanie integralności (dane nie mogą zostać zmodyfikowane w trakcie transmisji) i uwierzytelnianie serwera (klient ma pewność, że łączy się właśnie z właściwym serwerem). Szczególnie krytyczne jest uwierzytelnianie: bez niego atakujący może podmienić serwer poprzez DNS-spoofing lub fałszywy punkt dostępu Wi-Fi.

Według badania Google Play Protect (2024), 76% aplikacji Android poprawnie używa TLS z weryfikacją certyfikatów. Pozostałe 24% popełnia błędy: wyłączają weryfikację certyfikatów do testów (i zapominają włączyć w produkcji), używają certyfikatów samopodpisanych bez walidacji lub zezwalają na przestarzałe protokoły SSL 3.0 i TLS 1.0. Apple App Transport Security (ATS) w iOS wymaga TLS 1.2 co najmniej od 2017 roku, a od iOS 15 domyślnie używa TLS 1.3 dla wszystkich żądań sieciowych. Dla dodatkowej ochrony zaleca się również wdrożenie Certificate Pinning — przypięcie do konkretnego certyfikatu serwera.

Implementacja SSL/TLS w aplikacjach mobilnych

Rozważmy przykład konfiguracji bezpiecznego połączenia HTTPS w Android z użyciem OkHttp — jednej z najpopularniejszych bibliotek do pracy z siecią. Prawidłowa konfiguracja obejmuje wymuszone użycie TLS 1.3 i weryfikację certyfikatów.

val client = OkHttpClient.Builder()
    .connectionSpecs(
        listOf(
            ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
                .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
                .cipherSuites(
                    CipherSuite.TLS_AES_128_GCM_SHA256,
                    CipherSuite.TLS_AES_256_GCM_SHA384,
                    CipherSuite.TLS_CHACHA20_POLY1305_SHA256
                )
                .build()
        )
    )
    .hostnameVerifier { hostname, session ->
        SSLSession.DefaultHostnameVerifier.verify(hostname, session)
    }
    .build()

W tym przykładzie ograniczamy zestaw obsługiwanych wersji TLS tylko do protokołów 1.3 i 1.2, wykluczając przestarzałe TLS 1.0/1.1. Cipher suites są wybierane z nowoczesnych algorytmów z trybem AEAD i obowiązkową Perfect Forward Secrecy. HostnameVerifier sprawdza zgodność nazwy hosta z certyfikatem. Dla iOS analogiczna konfiguracja jest wykonywana poprzez konfigurację URLSession z parametrem tlsMinimumSupportedProtocolVersion, gdzie podaje się .TLSv13. Dodatkowo w iOS można ustawić tlsMaximumSupportedProtocolVersion w celu ograniczenia górnej granicy wersji — jest to przydatne dla kompatybilności ze starszymi serwerami, które jeszcze nie przeszły na TLS 1.3. Taka konfiguracja gwarantuje maksymalny poziom bezpieczeństwa podczas transmisji danych w aplikacji mobilnej.