SSL/TLS: kluczowe pojęcia i protokoły w programowaniu

Czym jest SSL/TLS?

SSL (Secure Sockets Layer) i TLS (Transport Layer Security) — protokoły kryptograficzne zapewniające bezpieczny przesył danych przez sieć. SSL, opracowany przez Netscape w latach 90., został uznany za przestarzały po wersji 3.0 z powodu podatności POODLE i BEAST. TLS, jego następca, przeszedł wersje 1.0, 1.1, 1.2 i 1.3 — obecnie za aktualne uważa się tylko TLS 1.2 i TLS 1.3. Wszystkie nowoczesne platformy mobilne wymagają używania TLS do połączeń sieciowych, a App Store i Google Play sprawdzają to na etapie recenzji.

Po co TLS aplikacjom mobilnym

Bez TLS ruch między aplikacją a serwerem przesyłany jest otwartym tekstem — każdy w tej samej sieci Wi-Fi może przechwycić loginy, hasła, tokeny i dane osobowe użytkowników za pomocą Wireshark lub tcpdump. TLS szyfruje wszystkie przesyłane dane (szyfrowanie na poziomie transportu) i weryfikuje autentyczność serwera poprzez łańcuch certyfikatów X.509. Według danych IETF (2018), TLS 1.3 używa tylko nowoczesnych szyfrów AEAD (AES-GCM, ChaCha20-Poly1305), eliminując przestarzałe algorytmy takie jak RC4 i 3DES.

HTTPS i TLS

HTTPS (HTTP Secure) — to HTTP przez TLS. Gdy aplikacja mobilna wysyła zapytanie przez https://, najpierw ustanawia połączenie TLS z serwerem, a następnie przesyła nagłówki HTTP i treść zapytania już przez zaszyfrowany kanał. Bez HTTPS żadne poważne API nie powinno działać — to podstawowa higiena bezpieczeństwa. Według danych OWASP (2026), niezabezpieczone połączenia znajdują się w top 3 podatności aplikacji mobilnych.

Jak działa TLS Handshake

TLS Handshake — proces ustanawiania bezpiecznego połączenia między klientem a serwerem. Strony uzgadniają wersję protokołu, wybierają zestaw szyfrów (cipher suite), wymieniają klucze przez kryptografię asymetryczną i weryfikują certyfikaty. W TLS 1.2 uzgadnianie wymaga 2 Round Trip Time (2 RTT): klient → serwer z ClientHello, serwer → klient z ServerHello i Certificate, a następnie końcowe komunikaty Finished. TLS 1.3 skraca ten proces do 1 RTT.

Szczegółowe etapy uzgadniania TLS 1.2

Pierwszy etap: ClientHello — klient wysyła obsługiwane wersje TLS, listę zestawów szyfrów i liczbę losową. Serwer odpowiada ServerHello, wybierając wersję i zestaw szyfrów, przesyła swój certyfikat X.509 (Certificate) oraz komunikat ServerHelloDone. Klient weryfikuje certyfikat przez łańcuch zaufanych urzędów certyfikacji (CA), generuje pre-master secret, szyfruje go kluczem publicznym z certyfikatu i wysyła do serwera w ClientKeyExchange. Następnie obie strony generują klucze sesji i wymieniają komunikaty ChangeCipherSpec oraz Finished. Od tego momentu wszystkie dane są szyfrowane symetrycznie.

import Security

let url = URL(string: "https://api.example.com")!
let session = URLSession(configuration: .default,
                           delegate: self,
                           delegateQueue: nil)

func urlSession(
    _ session: URLSession,
    didReceive challenge: URLAuthenticationChallenge,
    completionHandler: @escaping (URLSession.AuthChallengeDisposition,
                                    URLCredential?) -> Void
) {
    let trust = challenge.protectionSpace.serverTrust
    guard let trust else {
        completionHandler(.cancelAuthenticationChallenge, nil)
        return
    }
    completionHandler(.useCredential, URLCredential(trust: trust))
}

Przykład obsługi URLAuthenticationChallenge na iOS przez URLSessionDelegate. Ta metoda jest wywoływana przy każdym TLS Handshake, umożliwiając aplikacji niestandardowe sprawdzenie certyfikatu serwera. Do użytku produkcyjnego dodaj weryfikację certyfikatu przez SecTrustEvaluateWithError i porównaj z wcześniej zapisanym odciskiem — dopiero potem wywołaj useCredential.

TLS 1.2 a TLS 1.3

TLS 1.3 (RFC 8446, 2018) — pierwsza poważna aktualizacja protokołu od 10 lat. Główne ulepszenia: uzgadnianie skrócone do 1 RTT (0 RTT dla ponownych połączeń), usunięto przestarzałe zestawy szyfrów (RSA key exchange, CBC-mode), obowiązkowe doskonałe szyfrowanie przyszłościowe (PFS) oraz ochrona przed atakami downgrade przez signed transcript. Według danych Qualys SSL Labs (2026), TLS 1.3 zapewnia ochronę nawet przy kompromitacji długoterminowego klucza serwera dzięki PFS.

0-RTT (Zero Round Trip Time) — funkcja TLS 1.3, pozwalająca klientowi wysyłać dane od razu razem z ClientHello przy ponownym połączeniu przez PSK (Pre-Shared Key). Przyspiesza to ładowanie kolejnych ekranów w aplikacjach mobilnych, szczególnie przy częstych zapytaniach do tego samego serwera. Jednak dane 0-RTT nie są chronione przed atakami replay — można je przechwycić i wysłać ponownie. Używaj 0-RTT tylko do zapytań idempotentnych (GET, PUT) bez efektów ubocznych.

TLS na iOS: App Transport Security

App Transport Security (ATS) — mechanizm Apple wymagający połączeń HTTPS z TLS 1.2 lub wyższym, włączony domyślnie od iOS 9. ATS blokuje wszystkie połączenia HTTP oraz HTTPS z TLS poniżej 1.2. Deweloper może skonfigurować wyjątki w Info.plist przez NSAppTransportSecurity dla konkretnych domen, ale Apple zaleca minimalizowanie wyjątków i używanie HTTPS wszędzie. Naruszenie wymagań ATS jest powodem odrzucenia aplikacji podczas recenzji w App Store.

<!-- Info.plist — App Transport Security -->
<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <false/>
    <key>NSExceptionDomains</key>
    <dict>
        <key>cdn.example.com</key>
        <dict>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <false/>
            <key>NSExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
        </dict>
    </dict>
    <key>NSAllowsLocalNetworking</key>
    <true/>
</dict>

Konfiguracja ATS w Info.plist. NSAllowsArbitraryLoads ustawiony na false — wszystkie połączenia muszą używać HTTPS. Dla domeny cdn.example.com ustawiono minimalną wersję TLS 1.2, NSAllowsLocalNetworking=true zezwala na HTTP w sieci lokalnej (przydatne dla serwerów deweloperskich). Apple zdecydowanie zaleca niewłączanie NSAllowsArbitraryLoads bez NSExceptionDomains — to powinien być wyjątek, a nie reguła ogólna.

TLS na Android: Network Security Config

Network Security Config — mechanizm Androida do konfiguracji HTTPS i TLS bez zmiany kodu Java/Kotlin. Konfigurację określa się w pliku XML network_security_config.xml i podłącza w AndroidManifest przez atrybut android:networkSecurityConfig. Obsługuje konfigurację zaufanych certyfikatów (user i system CA), Certificate Pinning, wyłączenie cleartext HTTP, nadpisania debug i przekierowanie ruchu.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-01-01">
            <pin digest="SHA-256">
                47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
            </pin>
        </pin-set>
    </domain-config>
</network-security-config>

Network Security Config dla Androida. Base-config zabrania ruchu cleartext i ufa tylko systemowym certyfikatom CA (bez użytkownika — ochrona przed instalacją certyfikatów MitM przez użytkownika). Domain-config dla api.example.com zawiera pin-set z odciskiem SHA-256 certyfikatu. Jeśli certyfikat serwera zmieni się przed podaną datą expiration, połączenie zostanie odrzucone — to ścisła forma Certificate Pinning.

Certificate Pinning i bezpieczeństwo

Certificate Pinning — technika przypisania certyfikatu lub klucza publicznego serwera w kodzie aplikacji. Przy każdym TLS Handshake klient porównuje certyfikat serwera z wcześniej zapisanym odciskiem (hash SHA-256). Nawet jeśli atakujący uzyska zaufany certyfikat CA lub skompromituje urząd certyfikacji, nie będzie mógł przeprowadzić ataku MitM — aplikacja sprawdzi konkretny odcisk, a nie łańcuch CA. Jest to szczególnie ważne dla aplikacji finansowych i aplikacji z wrażliwymi danymi.

Ryzyka i alternatywy Pinning

Certificate Pinning wymaga ostrożności: przy zmianie certyfikatu na serwerze wszystkie stare wersje aplikacji przestaną się łączyć. Zaleca się przechowywanie kilku zapasowych odcisków (główny + zapasowy), określenie daty wygaśnięcia pin-set i zaimplementowanie mechanizmu fallback przez standardową weryfikację CA. Alternatywą jest Trust On First Use (TOFU), gdzie aplikacja zapamiętuje certyfikat przy pierwszym połączeniu i ostrzega użytkownika przy jego zmianie. Według OWASP (2026), brak Certificate Pinning znajduje się w top 3 podatności aplikacji mobilnych (M3: Insecure Communication).

Implementacja Pinning w Alamofire

W Alamofire 5+ Certificate Pinning konfiguruje się przez ServerTrustManager z PinnedCertificatesTrustEvaluator (sprawdzanie całego certyfikatu) lub PublicKeysTrustEvaluator (tylko klucz publiczny). Klucz publiczny jest preferowany — nie zmienia się przy aktualizacji certyfikatu u tego samego CA. Utwórz ServerTrustManager ze słownikiem [host: evaluator], przekaż go do Session i używaj dla wszystkich zapytań do chronionych API.