HTTP/HTTPS: mi ez, adatátviteli protokollok és TLS titkosítás

Mi az a HTTP és HTTPS?

A HTTP (HyperText Transfer Protocol) — az OSI modell alkalmazási rétegének protokollja, amely hipertext dokumentumok és egyéb adatok továbbítására szolgál a World Wide Web-en. Tim Berners-Lee által 1989-ben kifejlesztett HTTP számos verzión ment keresztül: a HTTP/0.9-től (csak GET kérések és HTML válaszok) a modern HTTP/2 és HTTP/3 protokollokig. A protokoll kérés-válasz séma szerint működik: a kliens kérést küld a szervernek, a szerver feldolgozza azt és választ ad vissza.

A HTTPS (HTTP Secure) — a HTTP protokoll kiterjesztése, amely titkosítási réteget ad a TLS (Transport Layer Security) segítségével. A HTTPS nem külön protokoll — a HTTP és TLS kombinációja. A HTTPS-en keresztül küldött adatok a kliens oldalon titkosításra kerülnek és a szerveren dekódolódnak, ami lehetetlenné teszi azok elfogását és hamisítását. A HTTPS a szerver hitelesítését is biztosítja SSL/TLS tanúsítványokon keresztül, garantálva, hogy a kliens a valódi szerverhez csatlakozik, nem egy támadóhoz.

A HTTP és HTTPS közötti kulcsfontosságú különbség a biztonság. A HTTP nyílt formában továbbítja az adatokat: a kliens és szerver közötti hálózat bármely csomópontja olvashatja a kérés vagy válasz tartalmát. A HTTPS titkosítja a teljes tartalmat, beleértve az URL-t, a fejléceket és a kérés törzsét, csak a szerver IP-címét és a kapcsolódási portot hagyva láthatóan. A nyilvános Wi-Fi hálózatokon keresztül működő mobilalkalmazások számára a HTTPS kötelező biztonsági követelmény.

Hogyan működik a HTTP

A HTTP — állapotmentes (stateless) protokoll, amely TCP/IP felett működik. A kliens TCP kapcsolatot létesít a szerverrel (általában a 80-as porton HTTP vagy 443-as porton HTTPS esetén), elküldi a HTTP kérést, megkapja a HTTP választ és bezárja a kapcsolatot (HTTP/1.1-ben a kapcsolat újra felhasználható). Minden interakció a kliens és szerver között egy kérésből és válaszból áll. Az állapotmentesség azt jelenti, hogy a szerver nem tárol információt a kliens korábbi kéréseiről — minden kérés függetlenül kerül feldolgozásra.

A HTTP interakciós folyamat a következő lépéseket tartalmazza:

• DNS feloldás — a böngésző vagy kliens a domain nevet IP-címmé alakítja DNS-en keresztül
• TCP kézfogás — a TCP kapcsolat háromlépéses kézfogással (SYN, SYN-ACK, ACK) jön létre
• TLS kézfogás — HTTPS esetén további titkosított kapcsolat jön létre (tanúsítványok és kulcsok cseréje)
• HTTP kérés — a kliens elküldi a metódust, URL-t, fejléceket és opcionálisan a kérés törzsét
• HTTP válasz — a szerver visszaadja az állapotkódot, fejléceket és a válasz törzsét

A HTTP egyik fontos jellemzője a metódusok idempotenciája. A GET, HEAD, PUT, DELETE és OPTIONS idempotens: ugyanazon kérés többszöri végrehajtása nem változtatja meg a szerver állapotát az első végrehajtás után. A POST, PATCH és CONNECT nem idempotens — minden hívás új erőforrást hozhat létre vagy módosíthatja az állapotot. A mobilfejlesztésben az idempotencia megértése kritikus: hálózati hiba miatti kérés újraküldésekor a kliensnek tudnia kell, hogy biztonságos-e megismételni a kérést.

HTTPS és TLS titkosítás

A HTTPS a TLS (Transport Layer Security) kriptográfiai protokollt használja a továbbított adatok védelmére. A TLS — az SSL (Secure Sockets Layer) utódja, amelyet a Netscape cég fejlesztett ki 1995-ben. Az SSL 2.0 és 3.0 verziók elavultnak és nem biztonságosnak számítanak; a modern TLS 1.2 (2008-ban kiadva) és TLS 1.3 (2018-ban kiadva) verziók széles körben használtak. A TLS 1.3 különösen csökkenti a kapcsolat létrehozásának idejét 2 round-trips-ről 1-re, ami jelentősen gyorsítja a betöltést mobileszközökön.

A TLS kézfogás (handshake) folyamata a következő szakaszokat tartalmazza:

• Client Hello — a kliens elküldi a támogatott TLS verziók és titkosítási csomagok listáját
• Server Hello — a szerver kiválasztja a TLS verziót és titkosítási csomagot, elküldi SSL/TLS tanúsítványát
• Tanúsítvány ellenőrzése — a kliens ellenőrzi a szerver tanúsítványát a megbízhatósági láncon keresztül a gyökér CA-ig
• Kulcs csere — a kliens és szerver közös titkos kulcsot (munkamenet kulcsot) generál
• Switch Cipher — mindkét fél megerősíti a titkosított kapcsolatra váltást

Az SSL/TLS tanúsítvány ellenőrzése — kritikus szakasz a biztonság szempontjából. A kliens ellenőrzi, hogy a tanúsítvány: nem járt le, megbízható tanúsítványkiadó (CA) által aláírt, megfelel az URL-ben lévő domainnek és nem lett visszavonva (CRL vagy OCSP útján). Mobilalkalmazásokban ajánlott a Certificate Pinning használata — egy adott tanúsítványhoz vagy a szerver nyilvános kulcsához kötés. Ez megakadályozza az MITM támadásokat még a CA kompromittálása esetén is. A pinning azonban óvatosságot igényel: a tanúsítvány változásakor az alkalmazást előre frissíteni kell.

A HTTP kérés és válasz szerkezete

A HTTP kérés három részből áll: kezdő sorból (request line), fejlécekből (headers) és opcionális törzsből (body). A kezdő sor tartalmazza a HTTP metódust, a kérés URL-jét és a HTTP verziót. A fejlécek meta-információt továbbítanak: tartalom típusa, hitelesítési tokenek, gyorsítótárazási beállítások. A törzs csak az adatokat küldő metódusokban (POST, PUT, PATCH) van jelen, és hiányzik a GET és DELETE esetében.

Példa HTTP kérésre REST API-hoz:

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"
}

A HTTP válasz hasonló szerkezetű: kezdő sor a HTTP verzióval és állapotkóddal, fejlécek és törzs. Az állapotkód — egy háromjegyű szám, amely meghatározza a kérés feldolgozásának eredményét. A válasz fejlécei tartalmazzák a Content-Type, Content-Length, Cache-Control, Set-Cookie és egyéb adatokat. A válasz törzse a kért adatokat tartalmazza a Content-Type-ban megadott formátumban (általában JSON API-hoz, HTML weboldalakhoz, képek média tartalomhoz).

A fejlécek kritikus szerepet játszanak a HTTP működésében. A Content-Type és Accept az adatformátumot kezeli. Az Authorization hozzáférési tokeneket továbbít. A Cache-Control a gyorsítótárazást kezeli. A CORS fejlécek (Access-Control-Allow-Origin) más domainek hozzáférését szabályozzák a böngészőkben. A User-Agent azonosítja a kliens alkalmazást. Mobilalkalmazások számára a gyorsítótárazást kezelő fejlécek különösen fontosak — csökkentik a továbbított adatok mennyiségét és javítják a működést gyenge jel esetén.

HTTP állapotkódok

A HTTP állapotkódok öt osztályba csoportosulnak, amelyeket az első számjegy jelöl: 1xx (információs), 2xx (siker), 3xx (átirányítás), 4xx (kliens hiba), 5xx (szerver hiba). Ezen kódok megértése szükséges a válaszok helyes feldolgozásához egy mobilalkalmazásban: a 2xx sikert jelent és az adatok megjeleníthetők, a 4xx a kérésben lévő problémát jelzi (hibát kell mutatni a felhasználónak), az 5xx — szerverproblémát (a kérést később meg kell ismételni).

Mobilalkalmazások számára a 401 Unauthorized kód kezelése különös jelentőséggel bír. Ezen kód fogadásakor a kliensnek meg kell próbálnia frissíteni a hozzáférési tokent Refresh Token segítségével és megismételni az eredeti kérést. Ha a token frissítése is 401-et ad vissza, a felhasználót át kell irányítani a bejelentkezési képernyőre. Ezt a logikát általában Interceptor-ban (OkHttp) vagy a hálózati kliens middleware rétegében implementálják.

HTTP/1.1, HTTP/2 és HTTP/3

A HTTP/1.1, amelyet 1999-ben adtak ki, még mindig széles körben használt protokoll verzió. Fő hátránya — head-of-line blocking: az ugyanazon szerverhez irányuló kérések szekvenciálisan hajtódnak végre, minden következő vár az előző befejeződésére. Ennek a korlátozásnak a kikerülésére a böngészők 6–8 párhuzamos TCP kapcsolatot nyitnak ugyanahhoz a domainhez, ami növeli a szerver terhelését és a memória fogyasztást. A HTTP/1.1 a fejléceket is titkosítatlan formában továbbítja és nem támogatja a server push-t.

A HTTP/2 (2015) a multiplexálással oldja meg a blokkolás problémáját – több adatfolyam egyidejűleg továbbítható egyetlen TCP kapcsolaton keresztül. A szerver küldhet erőforrásokat a kliensnek, mielőtt a kliens kérné azokat (server push). A HTTP/2 HPACK-on keresztül tömöríti a fejléceket is, ami csökkenti a továbbított adatok mennyiségét. Mobilalkalmazások számára a HTTP/2 különösen hasznos: egyetlen kapcsolat többet helyettesít, csökkentve a TLS kézfogás idejét és az akkumulátor fogyasztást.

A HTTP/3 (2022) — a protokoll legújabb verziója, amely TCP helyett QUIC-ot (Quick UDP Internet Connections) használ. A QUIC UDP felett működik, kiküszöbölve a head-of-line blocking problémát a szállítási protokoll szintjén. A HTTP/3 a kapcsolat létrehozásának idejét legjobb esetben 0 round-trips-re (újracsatlakozásoknál) és 1 round-trip-re csökkenti az első kapcsolódáskor, ami jelentősen gyorsabb, mint a HTTP/2 2–3 round-trips-ével. Mobileszközök számára a HTTP/3 különösen hatékony a Wi-Fi és mobilhálózat közötti váltáskor – a kapcsolat nem szakad meg, mivel a QUIC kapcsolat azonosítót használ IP-cím helyett.

HTTPS a mobilfejlesztésben

A HTTPS használata mobilalkalmazásokban — nem ajánlás, hanem kötelező követelmény. Az Android 9 (API 28) és iOS 9 (ATS — App Transport Security) óta minden hálózati kérés alapértelmezetten HTTPS-t kell használjon. A HTTP kéréseket a rendszer blokkolja, és engedélyezésükhöz kifejezett kivétel szükséges az alkalmazás konfigurációjában. A Google Play Store és App Store elutasítja azokat az alkalmazásokat, amelyek bizalmas adatokat küldenek HTTP-n keresztül, beleértve a jelszavakat, tokeneket és személyes adatokat.

A HTTPS konfigurációja mobilalkalmazásban Androidon a következőket tartalmazza:

<!-- AndroidManifest.xml — engedély hálózati kérésekhez -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — HTTPS konfiguráció -->
<?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>

iOS-en hasonló konfiguráció az Info.plist fájlon keresztül történik a NSAppTransportSecurity kulccsal. A HTTPS forgalom hibakereséséhez mobilalkalmazásokban proxy eszközöket használnak: Charles Proxy, Proxyman vagy mitmproxy. Ezek megbízható SSL tanúsítvány telepítését igénylik az eszközön. Éles build-ekben ki kell kapcsolni a hibakeresési lehetőséget és ellenőrizni kell, hogy a Certificate Pinning megfelelően van konfigurálva. Az OkHttp használata Androidon a CertificatePinner-rel vagy TrustManager iOS-en a SecTrustEvaluate-val — szabványos megközelítések a pinning implementálásához.

A HTTPS biztonságának fontos aspektusa a mobilfejlesztésben — SSL Pinning. Pinning nélkül az alkalmazás megbízik bármely ismert CA által aláírt tanúsítványban. Ha a CA kompromittálódik, egy támadó elfoghatja az alkalmazás forgalmát. A pinning az alkalmazást egy adott tanúsítványhoz vagy a szerver nyilvános kulcsához köti. A szerver tanúsítványának változásakor az alkalmazás frissítését ki kell adni, ezért a pinning-et tartalékkal tervezik – a felsőbb CA tanúsítványához kötnek vagy több tartalék kulcsot használnak.