HTTP/HTTPS: vad är det, dataöverföringsprotokoll och TLS-kryptering

Vad är HTTP och HTTPS?

HTTP (HyperText Transfer Protocol) — är ett applikationslagerprotokoll i OSI-modellen, avsett för överföring av hypertextdokument och annan data på World Wide Web. Utvecklat av Tim Berners-Lee 1989, har HTTP gått igenom flera versioner: från HTTP/0.9 (endast GET-förfrågningar och HTML-svar) till moderna HTTP/2 och HTTP/3. Protokollet fungerar enligt en förfrågan-svar-modell: klienten skickar en förfrågan till servern, servern bearbetar den och returnerar ett svar.

HTTPS (HTTP Secure) — är en utökning av HTTP-protokollet som lägger till ett krypteringslager genom TLS (Transport Layer Security). HTTPS är inte ett separat protokoll — det är en kombination av HTTP och TLS. Data som överförs via HTTPS krypteras på klientsidan och dekrypteras på servern, vilket gör dem oåtkomliga för avlyssning och förfalskning. HTTPS ger också serverautentisering via SSL/TLS-certifikat, vilket garanterar att klienten ansluter till den verkliga servern, inte till en angripare.

Den viktigaste skillnaden mellan HTTP och HTTPS är säkerhet. HTTP överför data i klartext: varje nätverksnod mellan klient och server kan läsa innehållet i förfrågan eller svaret. HTTPS krypterar allt innehåll, inklusive URL, rubriker och förfrågans brödtext, och lämnar endast serverns IP-adress och anslutningsport synliga. För mobilapplikationer som fungerar via offentliga Wi-Fi-nätverk är HTTPS ett obligatoriskt säkerhetskrav.

Hur fungerar HTTP

HTTP — är ett tillståndslöst (stateless) protokoll som fungerar över TCP/IP. Klienten upprättar en TCP-anslutning till servern (vanligtvis på port 80 för HTTP eller 443 för HTTPS), skickar en HTTP-förfrågan, tar emot ett HTTP-svar och stänger anslutningen (i HTTP/1.1 kan anslutningen återanvändas). Varje interaktion mellan klient och server består av en förfrågan och ett svar. Tillståndslöshet innebär att servern inte lagrar information om klientens tidigare förfrågningar — varje förfrågan bearbetas oberoende.

HTTP-interaktionsprocessen omfattar följande steg:

• DNS-upplösning — webbläsaren eller klienten omvandlar domännamnet till en IP-adress via DNS
• TCP-handskakning — TCP-anslutningen upprättas genom en trevägshandskakning (SYN, SYN-ACK, ACK)
• TLS-handskakning — för HTTPS upprättas ytterligare en krypterad anslutning (utbyte av certifikat och nycklar)
• HTTP-förfrågan — klienten skickar metod, URL, rubriker och eventuellt brödtext
• HTTP-svar — servern returnerar statuskod, rubriker och svarsbrödtext

En viktig egenskap hos HTTP är idempotens hos metoder. GET, HEAD, PUT, DELETE och OPTIONS är idempotenta: upprepad exekvering av samma förfrågan ändrar inte serverns tillstånd efter den första exekveringen. POST, PATCH och CONNECT är inte idempotenta — varje anrop kan skapa en ny resurs eller ändra tillståndet. För mobil utveckling är förståelse av idempotens kritisk: vid återsändning av en förfrågan på grund av ett nätverksfel måste klienten veta om det är säkert att upprepa förfrågan.

HTTPS och TLS-kryptering

HTTPS använder det kryptografiska protokollet TLS (Transport Layer Security) för att skydda överförda data. TLS — efterträdare till SSL (Secure Sockets Layer), som utvecklades av företaget Netscape 1995. Versionerna SSL 2.0 och 3.0 anses föråldrade och osäkra; moderna versioner TLS 1.2 (släppt 2008) och TLS 1.3 (släppt 2018) används allmänt. TLS 1.3 minskar särskilt anslutningstiden från 2 round-trips till 1, vilket avsevärt snabbar upp laddningen på mobila enheter.

TLS-handskakningsprocessen omfattar följande faser:

• Client Hello — klienten skickar en lista över TLS-versioner och chiffer som stöds
• Server Hello — servern väljer TLS-version och chiffer, skickar sitt SSL/TLS-certifikat
• Certifikatverifiering — klienten verifierar serverns certifikat via förtroendekedjan till rot-CA
• Nyckelutbyte — klienten och servern genererar en gemensam hemlig nyckel (essionsnyckel)
• Switch Cipher — båda parter bekräftar övergången till krypterad anslutning

Verifiering av SSL/TLS-certifikatet — en kritisk fas för säkerheten. Klienten kontrollerar att certifikatet: inte har löpt ut, är signerat av en betrodd certifikatutfärdare (CA), matchar domänen i URL och inte har återkallats (via CRL eller OCSP). I mobilapplikationer rekommenderas användning av Certificate Pinning — bindning till ett specifikt certifikat eller serverns publika nyckel. Detta förhindrar MITM-attacker även vid kompromettering av CA. Pinning kräver dock försiktighet: när certifikatet ändras måste applikationen uppdateras i förväg.

Struktur för HTTP-förfrågan och -svar

En HTTP-förfrågan består av tre delar: startrad (request line), rubriker (headers) och eventuell brödtext (body). Startraden innehåller HTTP-metoden, förfrågans URL och HTTP-version. Rubriker överför metainformation: innehållstyp, autentiseringstoken, cache-inställningar. Brödtexten finns endast i metoder som överför data (POST, PUT, PATCH) och saknas i GET och DELETE.

Exempel på HTTP-förfrågan till ett 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"
}

Ett HTTP-svar har en liknande struktur: startrad med HTTP-version och statuskod, rubriker och brödtext. Statuskoden — ett tresiffrigt nummer som bestämmer resultatet av förfrågan. Svarsrubriker inkluderar Content-Type, Content-Length, Cache-Control, Set-Cookie och andra. Svarsbrödtexten innehåller den begärda datan i formatet som anges i Content-Type (vanligtvis JSON för API, HTML för webbsidor, bilder för medieinnehåll).

Rubriker spelar en kritisk roll i HTTP:s funktion. Content-Type och Accept hanterar dataformat. Authorization överför åtkomsttoken. Cache-Control hanterar cachning. CORS-rubriker (Access-Control-Allow-Origin) kontrollerar åtkomst från andra domäner i webbläsare. User-Agent identifierar klientapplikationen. För mobilapplikationer är cachningsrubriker särskilt viktiga — de minskar mängden överförd data och förbättrar prestanda vid svag signal.

HTTP-statuskoder

HTTP-statuskoder grupperas i fem klasser, indikerade av den första siffran: 1xx (informativ), 2xx (framgång), 3xx (omdirigering), 4xx (klientfel), 5xx (serverfel). Att förstå dessa koder är nödvändigt för korrekt bearbetning av svar i en mobilapplikation: 2xx innebär framgång och data kan visas, 4xx indikerar ett problem i förfrågan (fel ska visas för användaren), 5xx — ett problem på servern (förfrågan ska upprepas senare).

För mobilapplikationer är hantering av koden 401 Unauthorized särskilt viktig. Vid mottagande av denna kod bör klienten försöka uppdatera åtkomsttoken via Refresh Token och upprepa den ursprungliga förfrågan. Om tokenuppdatering också returnerar 401 ska användaren omdirigeras till inloggningsskärmen. Denna logik implementeras vanligtvis i en Interceptor (OkHttp) eller i middleware-lagret hos nätverksklienten.

HTTP/1.1, HTTP/2 och HTTP/3

HTTP/1.1, publicerad 1999, är fortfarande en allmänt använd protokollversion. Dess främsta nackdel — head-of-line blocking: förfrågningar till samma server utförs sekventiellt, varje efterföljande väntar på att den föregående ska slutföras. För att kringgå denna begränsning öppnar webbläsare 6–8 parallella TCP-anslutningar till samma domän, vilket ökar serverbelastningen och minnesförbrukningen. HTTP/1.1 överför också rubriker i okrypterad form och stöder inte server push.

HTTP/2 (2015) löser blockeringsproblemet genom multiplexering — flera dataströmmar överförs samtidigt över en enda TCP-anslutning. Servern kan skicka resurser till klienten innan klienten begär dem (server push). HTTP/2 komprimerar också rubriker via HPACK, vilket minskar mängden överförd data. För mobilapplikationer är HTTP/2 särskilt användbart: en anslutning ersätter flera, vilket minskar TLS-handskakningstiden och batteriförbrukningen.

HTTP/3 (2022) — den senaste protokollversionen, som använder QUIC (Quick UDP Internet Connections) istället för TCP. QUIC fungerar över UDP och eliminerar head-of-line blocking-problemet på transportprotokollnivå. HTTP/3 minskar anslutningstiden till 0 round-trips i bästa fall (vid återanslutningar) och till 1 round-trip vid första anslutningen, vilket är betydligt snabbare än HTTP/2 med dess 2–3 round-trips. För mobila enheter är HTTP/3 särskilt effektivt vid växling mellan Wi-Fi och mobilt nätverk — anslutningen bryts inte eftersom QUIC använder en anslutningsidentifierare istället för IP-adress.

HTTPS i mobil utveckling

Användning av HTTPS i mobilapplikationer — är inte en rekommendation, utan ett obligatoriskt krav. Från och med Android 9 (API 28) och iOS 9 (ATS — App Transport Security) måste alla nätverksförfrågningar som standard använda HTTPS. HTTP-förfrågningar blockeras av systemet och för att tillåta dem krävs ett uttryckligt undantag i applikationskonfigurationen. Google Play Store och App Store avvisar applikationer som överför konfidentiell data via HTTP, inklusive lösenord, token och personuppgifter.

HTTPS-konfiguration i en mobilapplikation på Android omfattar:

<!-- AndroidManifest.xml — behörighet för nätverksförfrågningar -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — HTTPS-konfiguration -->
<?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>

På iOS görs en liknande konfiguration via Info.plist med nyckeln NSAppTransportSecurity. För felsökning av HTTPS-trafik i mobilapplikationer används proxyverktyg: Charles Proxy, Proxyman eller mitmproxy. De kräver installation av ett betrott SSL-certifikat på enheten. I produktionsbyggen måste felsökningsmöjligheten stängas av och Certificate Pinning måste vara korrekt konfigurerat. Användning av OkHttp på Android med dess CertificatePinner eller TrustManager på iOS med SecTrustEvaluate — är standardmetoder för att implementera pinning.

En viktig aspekt av HTTPS-säkerhet i mobil utveckling — SSL Pinning. Utan pinning litar applikationen på alla certifikat signerade av en känd CA. Om CA komprometteras kan en angripare avlyssna applikationens trafik. Pinning binder applikationen till ett specifikt certifikat eller serverns publika nyckel. När certifikatet på servern ändras måste en applikationsuppdatering släppas, därför planeras pinning med marginal — man binder till det överordnade CA-certifikatet eller använder flera reservnycklar.