HTTP/HTTPS: wat is het, gegevens transportprotocollen en TLS-codering

Wat zijn HTTP en HTTPS?

HTTP (HyperText Transfer Protocol) — is een applicatielaagprotocol van het OSI-model, ontworpen voor het verzenden van hypertextdocumenten en andere gegevens op het World Wide Web. Ontwikkeld door Tim Berners-Lee in 1989, heeft HTTP verschillende versies doorgemaakt: van HTTP/0.9 (alleen GET-verzoeken en HTML-antwoorden) tot moderne HTTP/2 en HTTP/3. Het protocol werkt volgens een verzoek-antwoordschema: de client stuurt een verzoek naar de server, de server verwerkt dit en retourneert een antwoord.

HTTPS (HTTP Secure) — is een uitbreiding van het HTTP-protocol die een coderingslaag toevoegt via TLS (Transport Layer Security). HTTPS is geen apart protocol — het is een combinatie van HTTP en TLS. Gegevens die via HTTPS worden verzonden, worden aan de clientzijde gecodeerd en op de server gedecodeerd, waardoor ze ontoegankelijk zijn voor onderschepping en vervalsing. HTTPS zorgt ook voor serverauthenticatie via SSL/TLS-certificaten, waarmee wordt gegarandeerd dat de client verbinding maakt met de echte server en niet met een aanvaller.

Het belangrijkste verschil tussen HTTP en HTTPS is beveiliging. HTTP verzendt gegevens in ongecodeerde vorm: elk netwerk knooppunt tussen client en server kan de inhoud van het verzoek of antwoord lezen. HTTPS codeert alle inhoud, inclusief de URL, headers en de body van het verzoek, en laat alleen het IP-adres van de server en de verbindingspoort zichtbaar. Voor mobiele applicaties die via openbare Wi-Fi-netwerken werken, is HTTPS een verplichte beveiligingseis.

Hoe werkt HTTP

HTTP — is een stateloos protocol dat over TCP/IP werkt. De client maakt een TCP-verbinding met de server (meestal op poort 80 voor HTTP of 443 voor HTTPS), stuurt een HTTP-verzoek, ontvangt een HTTP-antwoord en sluit de verbinding (in HTTP/1.1 kan de verbinding opnieuw worden gebruikt). Elke interactie tussen client en server bestaat uit een verzoek en een antwoord. Stateloos betekent dat de server geen informatie opslaat over eerdere verzoeken van de client — elk verzoek wordt onafhankelijk verwerkt.

Het HTTP-interactieproces omvat de volgende stappen:

• DNS-resolutie — de browser of client converteert de domeinnaam naar een IP-adres via DNS
• TCP-handshake — de TCP-verbinding wordt tot stand gebracht via een drie-weg handshake (SYN, SYN-ACK, ACK)
• TLS-handshake — voor HTTPS wordt aanvullend een gecodeerde verbinding tot stand gebracht (uitwisseling van certificaten en sleutels)
• HTTP-verzoek — de client stuurt de methode, URL, headers en optioneel de verzoek body
• HTTP-antwoord — de server retourneert de statuscode, headers en antwoord body

Een belangrijke eigenschap van HTTP is idempotentie van methoden. GET, HEAD, PUT, DELETE en OPTIONS zijn idempotent: het meerdere keren uitvoeren van hetzelfde verzoek verandert de serverstatus niet na de eerste uitvoering. POST, PATCH en CONNECT zijn niet idempotent — elke aanroep kan een nieuwe resource creëren of de status wijzigen. Voor mobiele ontwikkeling is het begrijpen van idempotentie cruciaal: bij het opnieuw verzenden van een verzoek als gevolg van een netwerkfout moet de client weten of het veilig is om het verzoek te herhalen.

HTTPS en TLS-codering

HTTPS gebruikt het cryptografische protocol TLS (Transport Layer Security) om verzonden gegevens te beschermen. TLS — de opvolger van SSL (Secure Sockets Layer), ontwikkeld door het bedrijf Netscape in 1995. De versies SSL 2.0 en 3.0 worden als verouderd en onveilig beschouwd; de moderne versies TLS 1.2 (uitgebracht in 2008) en TLS 1.3 (uitgebracht in 2018) worden overal gebruikt. TLS 1.3 verkort met name de verbindingstijd van 2 round-trips naar 1, wat het laden op mobiele apparaten aanzienlijk versnelt.

Het TLS-handshake-proces omvat de volgende fasen:

• Client Hello — de client stuurt een lijst met ondersteunde TLS-versies en ciphersuites
• Server Hello — de server kiest een TLS-versie en ciphersuite, stuurt zijn SSL/TLS-certificaat
• Certificaatverificatie — de client verifieert het servercertificaat via de vertrouwensketen tot aan de root-CA
• Sleuteluitwisseling — client en server genereren een gedeelde geheime sleutel (sessiesleutel)
• Switch Cipher — beide partijen bevestigen de overgang naar de gecodeerde verbinding

Verificatie van het SSL/TLS-certificaat — een kritieke fase voor de beveiliging. De client controleert of het certificaat: niet is verlopen, is ondertekend door een vertrouwde certificeringsinstantie (CA), overeenkomt met het domein in de URL en niet is ingetrokken (via CRL of OCSP). In mobiele applicaties wordt het gebruik van Certificate Pinning aanbevolen — het vastmaken aan een specifiek certificaat of publieke sleutel van de server. Dit voorkomt MITM-aanvallen, zelfs bij compromittering van de CA. Pinning vereist echter voorzichtigheid: bij wijziging van het certificaat moet de applicatie vooraf worden bijgewerkt.

Structuur van HTTP-verzoek en -antwoord

Een HTTP-verzoek bestaat uit drie delen: de startregel (request line), headers en optioneel een body. De startregel bevat de HTTP-methode, de URL van het verzoek en de HTTP-versie. Headers geven metainformatie door: inhoudstype, authenticatietokens, cache-instellingen. De body is alleen aanwezig bij methoden die gegevens verzenden (POST, PUT, PATCH) en ontbreekt bij GET en DELETE.

Voorbeeld van een HTTP-verzoek naar een 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"
}

Een HTTP-antwoord heeft een vergelijkbare structuur: een startregel met de HTTP-versie en statuscode, headers en body. De statuscode — een driecijferig nummer dat het resultaat van de verwerking van het verzoek bepaalt. Antwoordheaders omvatten Content-Type, Content-Length, Cache-Control, Set-Cookie en andere. De antwoord body bevat de gevraagde gegevens in het formaat gespecificeerd in Content-Type (meestal JSON voor API, HTML voor webpagina's, afbeeldingen voor mediacontent).

Headers spelen een cruciale rol in de werking van HTTP. Content-Type en Accept beheren het gegevensformaat. Authorization geeft toegangstokens door. Cache-Control beheert het cache geheugen. CORS-headers (Access-Control-Allow-Origin) controleren de toegang vanaf andere domeinen in browsers. User-Agent identificeert de clientapplicatie. Voor mobiele applicaties zijn cache-beheerheaders bijzonder belangrijk — ze verminderen de hoeveelheid verzonden gegevens en verbeteren de werking bij een zwak signaal.

HTTP-statuscodes

HTTP-statuscodes worden gegroepeerd in vijf klassen, aangeduid met het eerste cijfer: 1xx (informatief), 2xx (succes), 3xx (omleiding), 4xx (clientfout), 5xx (serverfout). Het begrijpen van deze codes is noodzakelijk voor de juiste verwerking van antwoorden in een mobiele applicatie: 2xx betekent succes en de gegevens kunnen worden weergegeven, 4xx geeft een probleem in het verzoek aan (er moet een fout aan de gebruiker worden getoond), 5xx — een probleem op de server (het verzoek moet later worden herhaald).

Voor mobiele applicaties is de verwerking van code 401 Unauthorized bijzonder belangrijk. Bij ontvangst van deze code moet de client proberen het toegangstoken te vernieuwen via een Refresh Token en het oorspronkelijke verzoek herhalen. Als het vernieuwen van het token ook 401 retourneert, moet de gebruiker worden omgeleid naar het inlogscherm. Deze logica wordt meestal geïmplementeerd in een Interceptor (OkHttp) of in de middleware-laag van de netwerkclient.

HTTP/1.1, HTTP/2 en HTTP/3

HTTP/1.1, gepubliceerd in 1999, is nog steeds een veelgebruikte protocolversie. Het belangrijkste nadeel — head-of-line blocking: verzoeken naar dezelfde server worden sequentieel uitgevoerd, elk volgend verzoek wacht op de voltooiing van het vorige. Om deze beperking te omzeilen, openen browsers 6–8 parallelle TCP-verbindingen naar hetzelfde domein, wat de serverbelasting en het geheugengebruik verhoogt. HTTP/1.1 verzendt ook headers in ongecodeerde vorm en ondersteunt geen server push.

HTTP/2 (2015) lost het blokkeringsprobleem op door multiplexing — meerdere gegevensstromen worden gelijktijdig via één TCP-verbinding verzonden. De server kan bronnen naar de client sturen voordat de client erom vraagt (server push). HTTP/2 comprimeert ook headers via HPACK, wat de hoeveelheid verzonden gegevens vermindert. Voor mobiele applicaties is HTTP/2 bijzonder nuttig: één verbinding vervangt meerdere, waardoor de TLS-handshaketijd en het batterijverbruik worden verminderd.

HTTP/3 (2022) — de nieuwste protocolversie, die QUIC (Quick UDP Internet Connections) gebruikt in plaats van TCP. QUIC werkt over UDP en elimineert het head-of-line blocking-probleem op het niveau van het transportprotocol. HTTP/3 verkort de verbindingstijd in het beste geval tot 0 round-trips (bij herhaalde verbindingen) en tot 1 round-trip bij de eerste verbinding, wat aanzienlijk sneller is dan HTTP/2 met zijn 2–3 round-trips. Voor mobiele apparaten is HTTP/3 bijzonder efficiënt bij het schakelen tussen Wi-Fi en mobiel netwerk — de verbinding wordt niet verbroken omdat QUIC een verbindings-ID gebruikt in plaats van een IP-adres.

HTTPS in mobiele ontwikkeling

Het gebruik van HTTPS in mobiele applicaties — is geen aanbeveling, maar een verplichte vereiste. Vanaf Android 9 (API 28) en iOS 9 (ATS — App Transport Security) moeten alle netwerkverzoeken standaard HTTPS gebruiken. HTTP-verzoeken worden door het systeem geblokkeerd en voor toestemming is een expliciete uitzondering in de applicatieconfiguratie vereist. Google Play Store en App Store wijzen applicaties af die vertrouwelijke gegevens via HTTP verzenden, waaronder wachtwoorden, tokens en persoonlijke gegevens.

HTTPS-configuratie in een mobiele applicatie op Android omvat:

<!-- AndroidManifest.xml — machtiging voor netwerkverzoeken -->
<uses-permission android:name="android.permission.INTERNET" />

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

Op iOS wordt een vergelijkbare configuratie uitgevoerd via Info.plist met de sleutel NSAppTransportSecurity. Voor het debuggen van HTTPS-verkeer in mobiele applicaties worden proxy-tools gebruikt: Charles Proxy, Proxyman of mitmproxy. Ze vereisen installatie van een vertrouwd SSL-certificaat op het apparaat. In productieversies moet de foutopsporingsmogelijkheid worden uitgeschakeld en moet worden gecontroleerd of Certificate Pinning correct is geconfigureerd. Het gebruik van OkHttp op Android met zijn CertificatePinner of TrustManager op iOS met SecTrustEvaluate — zijn standaard benaderingen voor het implementeren van pinning.

Een belangrijk aspect van HTTPS-beveiliging in mobiele ontwikkeling — SSL Pinning. Zonder pinning vertrouwt de applicatie elk certificaat dat is ondertekend door een bekende CA. Als de CA wordt gecompromitteerd, kan een aanvaller het verkeer van de applicatie onderscheppen. Pinning bindt de applicatie aan een specifiek certificaat of publieke sleutel van de server. Bij wijziging van het certificaat op de server moet een applicatie-update worden uitgebracht, daarom wordt pinning met reserve gepland — men bindt zich aan het certificaat van de bovenliggende CA of gebruikt meerdere reservesleutels.