HTTP/HTTPS: co to jest, protokoły transmisji danych i szyfrowanie TLS

Czym są HTTP i HTTPS?

HTTP (HyperText Transfer Protocol) — to protokół warstwy aplikacji modelu OSI przeznaczony do przesyłania dokumentów hipertekstowych i innych danych w World Wide Web. Opracowany przez Tima Bernersa-Lee w 1989 roku, HTTP przeszedł kilka wersji: od HTTP/0.9 (tylko zapytania GET i odpowiedzi HTML) do nowoczesnych HTTP/2 i HTTP/3. Protokół działa w schemacie zapytanie-odpowiedź: klient wysyła zapytanie na serwer, serwer przetwarza je i zwraca odpowiedź.

HTTPS (HTTP Secure) — to rozszerzenie protokołu HTTP dodające warstwę szyfrowania przez TLS (Transport Layer Security). HTTPS nie jest oddzielnym protokołem — to kombinacja HTTP i TLS. Dane przesyłane przez HTTPS są szyfrowane po stronie klienta i deszyfrowane na serwerze, co czyni je niedostępnymi dla przechwycenia i podrobienia. HTTPS zapewnia również uwierzytelnianie serwera przez certyfikaty SSL/TLS, gwarantując, że klient łączy się z prawdziwym serwerem, a nie z atakującym.

Kluczowa różnica między HTTP a HTTPS to bezpieczeństwo. HTTP przesyła dane w otwartej postaci: każdy węzeł sieci między klientem a serwerem może odczytać treść zapytania lub odpowiedzi. HTTPS szyfruje całą treść, w tym URL, nagłówki i treść zapytania, pozostawiając widocznym tylko adres IP serwera i port połączenia. Dla aplikacji mobilnych działających przez publiczne sieci Wi-Fi HTTPS jest obowiązkowym wymogiem bezpieczeństwa.

Jak działa HTTP

HTTP — to protokół bezstanowy (stateless) działający na TCP/IP. Klient ustanawia połączenie TCP z serwerem (zazwyczaj na porcie 80 dla HTTP lub 443 dla HTTPS), wysyła zapytanie HTTP, otrzymuje odpowiedź HTTP i zamyka połączenie (w HTTP/1.1 połączenie może być ponownie użyte). Każda interakcja między klientem a serwerem składa się z zapytania i odpowiedzi. Brak stanu oznacza, że serwer nie przechowuje informacji o poprzednich zapytaniach klienta — każde zapytanie jest przetwarzane niezależnie.

Proces interakcji HTTP obejmuje następujące kroki:

• DNS-resolve — przeglądarka lub klient przekształca nazwę domenową na adres IP przez DNS
• TCP-handshake — ustanawiane jest połączenie TCP przez trójetapowe uzgadnianie (SYN, SYN-ACK, ACK)
• TLS-handshake — dla HTTPS dodatkowo ustanawiane jest szyfrowane połączenie (wymiana certyfikatów i kluczy)
• Zapytanie HTTP — klient wysyła metodę, URL, nagłówki i opcjonalnie treść zapytania
• Odpowiedź HTTP — serwer zwraca kod stanu, nagłówki i treść odpowiedzi

Ważną cechą HTTP jest idempotentność metod. GET, HEAD, PUT, DELETE i OPTIONS są idempotentne: wielokrotne wykonanie tego samego zapytania nie zmienia stanu serwera po pierwszym wykonaniu. POST, PATCH i CONNECT nie są idempotentne — każde wywołanie może tworzyć nowy zasób lub zmieniać stan. W programowaniu mobilnym zrozumienie idempotentności jest krytyczne: przy ponownym wysyłaniu zapytania z powodu błędu sieci klient musi wiedzieć, czy bezpiecznie jest powtórzyć zapytanie.

HTTPS i szyfrowanie TLS

HTTPS używa protokołu kryptograficznego TLS (Transport Layer Security) do ochrony przesyłanych danych. TLS — następca SSL (Secure Sockets Layer), który został opracowany przez firmę Netscape w 1995 roku. Wersje SSL 2.0 i 3.0 są uznawane za przestarzałe i niebezpieczne; nowoczesne wersje TLS 1.2 (wydany w 2008) i TLS 1.3 (wydany w 2018) są używane powszechnie. TLS 1.3, w szczególności, skraca czas ustanawiania połączenia z 2 round-trips do 1, co znacznie przyspiesza ładowanie na urządzeniach mobilnych.

Proces uzgadniania TLS (handshake) obejmuje następujące etapy:

• Client Hello — klient wysyła listę obsługiwanych wersji TLS i zestawów szyfrów
• Server Hello — serwer wybiera wersję TLS i zestaw szyfrów, wysyła swój certyfikat SSL/TLS
• Weryfikacja certyfikatu — klient sprawdza certyfikat serwera przez łańcuch zaufania do głównego CA
• Wymiana kluczy — klient i serwer generują wspólny klucz tajny (klucz sesji)
• Switch Cipher — obie strony potwierdzają przejście na szyfrowane połączenie

Weryfikacja certyfikatu SSL/TLS — krytyczny etap dla bezpieczeństwa. Klient sprawdza, czy certyfikat: nie wygasł, jest podpisany przez zaufany urząd certyfikacji (CA), odpowiada domenie w URL i nie został unieważniony (przez CRL lub OCSP). W aplikacjach mobilnych zaleca się stosowanie Certificate Pinning — przypięcie do konkretnego certyfikatu lub klucza publicznego serwera. Zapobiega to atakom MITM nawet w przypadku kompromitacji CA. Jednak pinning wymaga ostrożności: przy zmianie certyfikatu aplikacja musi być wcześniej zaktualizowana.

Struktura zapytania i odpowiedzi HTTP

Zapytanie HTTP składa się z trzech części: linii początkowej (request line), nagłówków (headers) i opcjonalnie treści (body). Linia początkowa zawiera metodę HTTP, URL zapytania i wersję HTTP. Nagłówki przekazują metainformację: typ treści, tokeny uwierzytelniające, ustawienia buforowania. Treść występuje tylko w metodach przesyłających dane (POST, PUT, PATCH) i nie występuje w GET i DELETE.

Przykład zapytania HTTP do REST API:

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache

{
    "name": "Anna",
    "email": "anna@example.com"
}

Odpowiedź HTTP ma analogiczną strukturę: linia początkowa z wersją HTTP i kodem stanu, nagłówki i treść. Kod stanu — trzycyfrowa liczba określająca wynik przetwarzania zapytania. Nagłówki odpowiedzi obejmują Content-Type, Content-Length, Cache-Control, Set-Cookie i inne. Treść odpowiedzi zawiera żądane dane w formacie określonym w Content-Type (zazwyczaj JSON dla API, HTML dla stron internetowych, obrazy dla treści medialnych).

Nagłówki odgrywają kluczową rolę w działaniu HTTP. Content-Type i Accept zarządzają formatem danych. Authorization przekazuje tokeny dostępu. Cache-Control zarządza buforowaniem. Nagłówki CORS (Access-Control-Allow-Origin) kontrolują dostęp z innych domen w przeglądarkach. User-Agent identyfikuje aplikację klienta. Dla aplikacji mobilnych szczególnie ważne są nagłówki zarządzania buforowaniem — pozwalają one zmniejszyć objętość przesyłanych danych i poprawić działanie przy słabym sygnale.

Kody stanu HTTP

Kody stanu HTTP są grupowane w pięć klas oznaczanych pierwszą cyfrą: 1xx (informacyjne), 2xx (sukces), 3xx (przekierowanie), 4xx (błąd klienta), 5xx (błąd serwera). Zrozumienie tych kodów jest niezbędne do prawidłowego przetwarzania odpowiedzi w aplikacji mobilnej: 2xx oznacza sukces i dane można wyświetlić, 4xx wskazuje na problem w zapytaniu (należy pokazać błąd użytkownikowi), 5xx — na problem na serwerze (należy powtórzyć zapytanie później).

Dla aplikacji mobilnych szczególne znaczenie ma obsługa kodu 401 Unauthorized. Po otrzymaniu tego kodu klient powinien próbować odświeżyć token dostępu przez Refresh Token i powtórzyć oryginalne zapytanie. Jeśli odświeżenie tokena również zwraca 401, użytkownika należy przekierować na ekran logowania. Ta logika jest zazwyczaj implementowana w Interceptor (OkHttp) lub w warstwie middleware klienta sieciowego.

HTTP/1.1, HTTP/2 i HTTP/3

HTTP/1.1, opublikowany w 1999 roku, wciąż pozostaje szeroko używaną wersją protokołu. Jego główna wada — head-of-line blocking: zapytania do jednego serwera są wykonywane sekwencyjnie, każde następne czeka na zakończenie poprzedniego. Aby ominąć to ograniczenie, przeglądarki otwierają 6–8 równoległych połączeń TCP do jednej domeny, co zwiększa obciążenie serwera i zużycie pamięci. HTTP/1.1 przesyła również nagłówki w niezaszyfrowanej postaci i nie obsługuje server push.

HTTP/2 (2015) rozwiązuje problem blokowania przez multipleksowanie — wiele strumieni danych jest przesyłanych przez jedno połączenie TCP jednocześnie. Serwer może wysyłać zasoby do klienta zanim klient je zażąda (server push). HTTP/2 również kompresuje nagłówki przez HPACK, co zmniejsza objętość przesyłanych danych. Dla aplikacji mobilnych HTTP/2 jest szczególnie przydatne: jedno połączenie zastępuje kilka, skracając czas uzgadniania TLS i zużycie baterii.

HTTP/3 (2022) — najnowsza wersja protokołu, która używa QUIC (Quick UDP Internet Connections) zamiast TCP. QUIC działa na UDP, eliminując problem head-of-line blocking na poziomie protokołu transportowego. HTTP/3 skraca czas ustanawiania połączenia do 0 round-trips w najlepszym przypadku (przy ponownych połączeniach) i do 1 round-trip przy pierwszym połączeniu, co jest znacznie szybsze niż HTTP/2 z jego 2–3 round-trips. Dla urządzeń mobilnych HTTP/3 jest szczególnie efektywny przy przełączaniu między Wi-Fi a siecią komórkową — połączenie nie zostaje przerwane, ponieważ QUIC używa identyfikatora połączenia, a nie adresu IP.

HTTPS w programowaniu mobilnym

Używanie HTTPS w aplikacjach mobilnych — to nie zalecenie, ale obowiązkowy wymóg. Począwszy od Android 9 (API 28) i iOS 9 (ATS — App Transport Security), wszystkie zapytania sieciowe domyślnie muszą używać HTTPS. Zapytania HTTP są blokowane przez system, a do ich zezwolenia wymagane jest jawne wyjątki w konfiguracji aplikacji. Google Play Store i App Store odrzucają aplikacje przesyłające poufne dane przez HTTP, w tym hasła, tokeny i dane osobowe.

Konfiguracja HTTPS w aplikacji mobilnej na Android obejmuje:

<!-- AndroidManifest.xml — zezwolenie na zapytania sieciowe -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — konfiguracja HTTPS -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">rDjsFv3bGf...</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Na iOS analogiczna konfiguracja jest wykonywana przez Info.plist z kluczem NSAppTransportSecurity. Do debugowania ruchu HTTPS w aplikacjach mobilnych używa się narzędzi proxy: Charles Proxy, Proxyman lub mitmproxy. Wymagają one zainstalowania zaufanego certyfikatu SSL na urządzeniu. W kompilacjach produkcyjnych należy wyłączyć możliwość debugowania i sprawdzić, czy Certificate Pinning jest skonfigurowany poprawnie. Używanie OkHttp na Android z jego CertificatePinner lub TrustManager na iOS z SecTrustEvaluate — standardowe podejścia do implementacji pinning.

Ważny aspekt bezpieczeństwa HTTPS w programowaniu mobilnym — SSL Pinning. Bez pinning aplikacja ufa każdemu certyfikatowi podpisanemu przez znany CA. Jeśli CA zostanie skompromitowany, atakujący będzie mógł przechwytywać ruch aplikacji. Pinning przywiązuje aplikację do konkretnego certyfikatu lub klucza publicznego serwera. Przy zmianie certyfikatu na serwerze konieczne jest wydanie aktualizacji aplikacji, dlatego pinning planuje się z zapasem — przywiązuje się do certyfikatu nadrzędnego CA lub używa kilku zapasowych kluczy.