SSL/TLS: kernbegrippen en protocollen in programmeren

Wat is SSL/TLS?

SSL (Secure Sockets Layer) en TLS (Transport Layer Security) — cryptografische protocollen die veilige gegevensoverdracht via het netwerk garanderen. SSL, ontwikkeld door Netscape in de jaren 1990, werd na versie 3.0 als verouderd beschouwd vanwege de POODLE- en BEAST-kwetsbaarheden. TLS, de opvolger, heeft versies 1.0, 1.1, 1.2 en 1.3 doorlopen — momenteel worden alleen TLS 1.2 en TLS 1.3 als actueel beschouwd. Alle moderne mobiele platforms vereisen het gebruik van TLS voor netwerkverbindingen, en App Store en Google Play controleren dit in de beoordelingsfase.

Waarom TLS nodig is voor mobiele apps

Zonder TLS wordt verkeer tussen app en server als platte tekst verzonden — iedereen in hetzelfde Wi-Fi-netwerk kan inloggegevens, wachtwoorden, tokens en persoonlijke gegevens van gebruikers onderscheppen met Wireshark of tcpdump. TLS versleutelt alle verzonden gegevens (versleuteling op transportniveau) en verifieert de authenticiteit van de server via de X.509-certificaatketen. Volgens IETF (2018) gebruikt TLS 1.3 alleen moderne AEAD-ciphers (AES-GCM, ChaCha20-Poly1305) en sluit verouderde algoritmen zoals RC4 en 3DES uit.

HTTPS en TLS

HTTPS (HTTP Secure) — is HTTP over TLS. Wanneer een mobiele app een verzoek doet via https://, wordt eerst een TLS-verbinding met de server opgezet, waarna HTTP-headers en de verzoekinhoud via het versleutelde kanaal worden verzonden. Zonder HTTPS zou geen enkele serieuze API mogen werken — dit is de basisbeveiligingshygiëne. Volgens OWASP (2026) staan onbeveiligde verbindingen in de top 3 van kwetsbaarheden in mobiele apps.

Hoe werkt TLS Handshake

TLS Handshake — het proces van het opzetten van een veilige verbinding tussen client en server. Partijen onderhandelen over de protocolversie, kiezen een ciphersuite, wisselen sleutels uit via asymmetrische cryptografie en verifiëren certificaten. In TLS 1.2 vereist de handshake 2 Round Trip Time (2 RTT): client → server met ClientHello, server → client met ServerHello en Certificate, gevolgd door de Finished-berichten. TLS 1.3 verkort dit proces tot 1 RTT.

Gedetailleerde fasen van TLS 1.2 handshake

Eerste fase: ClientHello — de client stuurt ondersteunde TLS-versies, een lijst met ciphersuites en een willekeurig getal. De server antwoordt met ServerHello, kiest de versie en ciphersuite, stuurt zijn X.509-certificaat (Certificate) en het ServerHelloDone-bericht. De client verifieert het certificaat via de keten van vertrouwde certificeringsinstanties (CA), genereert een pre-master secret, versleutelt het met de publieke sleutel uit het certificaat en stuurt het naar de server in ClientKeyExchange. Daarna genereren beide partijen sessiesleutels en wisselen ze ChangeCipherSpec- en Finished-berichten uit. Vanaf dit moment worden alle gegevens symmetrisch versleuteld.

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

Voorbeeld van het afhandelen van URLAuthenticationChallenge op iOS via URLSessionDelegate. Deze methode wordt bij elke TLS Handshake aangeroepen, waardoor de app het servercertificaat aangepast kan verifiëren. Voor productie voegt u certificaatverificatie toe via SecTrustEvaluateWithError en vergelijkt u met de vooraf opgeslagen vingerafdruk — roep pas daarna useCredential aan.

TLS 1.2 vs TLS 1.3

TLS 1.3 (RFC 8446, 2018) — de eerste grote update van het protocol in 10 jaar. Belangrijkste verbeteringen: handshake teruggebracht tot 1 RTT (0 RTT voor heraansluitingen), verouderde ciphersuites (RSA key exchange, CBC-mode) verwijderd, verplichte perfect forward secrecy (PFS) en bescherming tegen downgrade-aanvallen via signed transcript. Volgens Qualys SSL Labs (2026) biedt TLS 1.3 bescherming, zelfs bij compromittering van de langetermijnserversleutel dankzij PFS.

0-RTT (Zero Round Trip Time) — functie van TLS 1.3 waarmee de client bij heraansluiting via PSK (Pre-Shared Key) direct gegevens samen met ClientHello kan verzenden. Dit versnelt het laden van volgende schermen in mobiele apps, vooral bij frequente verzoeken aan dezelfde server. 0-RTT-gegevens zijn echter niet beschermd tegen replay-aanvallen — ze kunnen worden onderschept en opnieuw verzonden. Gebruik 0-RTT alleen voor idempotente verzoeken (GET, PUT) zonder bijwerkingen.

TLS op iOS: App Transport Security

App Transport Security (ATS) — Apple-mechanisme dat HTTPS-verbindingen met TLS 1.2 of hoger vereist, standaard ingeschakeld vanaf iOS 9. ATS blokkeert alle HTTP-verbindingen en HTTPS met TLS onder 1.2. De ontwikkelaar kan uitzonderingen configureren in Info.plist via NSAppTransportSecurity voor specifieke domeinen, maar Apple raadt aan uitzonderingen te minimaliseren en overal HTTPS te gebruiken. Overtreding van ATS-vereisten is een reden voor afwijzing van de app bij App Store-beoordeling.

<!-- 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>

ATS-configuratie in Info.plist. NSAllowsArbitraryLoads is ingesteld op false — alle verbindingen moeten HTTPS gebruiken. Voor domein cdn.example.com is minimale TLS 1.2-versie ingesteld, NSAllowsLocalNetworking=true staat HTTP toe voor het lokale netwerk (nuttig voor ontwikkelservers). Apple raadt ten zeerste af om NSAllowsArbitraryLoads in te schakelen zonder NSExceptionDomains — dit moet een uitzondering zijn, geen algemene regel.

TLS op Android: Network Security Config

Network Security Config — Android-mechanisme voor het configureren van HTTPS en TLS zonder Java/Kotlin-code te wijzigen. De configuratie wordt gedefinieerd in het XML-bestand network_security_config.xml en gekoppeld in AndroidManifest via het attribuut android:networkSecurityConfig. Het ondersteunt configuratie van vertrouwde certificaten (user en system CA), Certificate Pinning, uitschakelen van cleartext HTTP, debug-overrides en verkeersomleiding.

<!-- 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 voor Android. Base-config verbiedt cleartext-verkeer en vertrouwt alleen systeem-CA-certificaten (zonder gebruikerscertificaten — bescherming tegen installatie van MitM-certificaten door de gebruiker). Domain-config voor api.example.com bevat een pin-set met de SHA-256-vingerafdruk van het certificaat. Als het servercertificaat vóór de opgegeven vervaldatum verandert, wordt de verbinding geweigerd — dit is een strikte vorm van Certificate Pinning.

Certificate Pinning en beveiliging

Certificate Pinning — techniek waarbij het certificaat of de publieke sleutel van de server in de app-code wordt vastgelegd. Bij elke TLS Handshake vergelijkt de client het servercertificaat met de vooraf opgeslagen vingerafdruk (SHA-256-hash). Zelfs als een aanvaller een vertrouwd CA-certificaat verkrijgt of een certificeringsinstantie compromitteert, kan hij geen MitM-aanval uitvoeren — de app controleert de specifieke vingerafdruk, niet de CA-keten. Dit is vooral belangrijk voor financiële apps en apps met gevoelige gegevens.

Risico's en alternatieven van Pinning

Certificate Pinning vereist voorzichtigheid: bij wijziging van het certificaat op de server kunnen alle oude versies van de app geen verbinding meer maken. Het wordt aanbevolen meerdere reserve-vingerafdrukken op te slaan (primair + reserve), een vervaldatum voor de pin-set in te stellen en een fallback-mechanisme via standaard CA-verificatie te implementeren. Een alternatief is Trust On First Use (TOFU), waarbij de app het certificaat onthoudt bij de eerste verbinding en de gebruiker waarschuwt bij wijziging. Volgens OWASP (2026) staat het ontbreken van Certificate Pinning in de top 3 van kwetsbaarheden in mobiele apps (M3: Insecure Communication).

Pinning implementeren in Alamofire

In Alamofire 5+ wordt Certificate Pinning geconfigureerd via ServerTrustManager met PinnedCertificatesTrustEvaluator (controle van het hele certificaat) of PublicKeysTrustEvaluator (alleen de publieke sleutel). De publieke sleutel heeft de voorkeur — deze verandert niet bij certificaatvernieuwing bij dezelfde CA. Maak een ServerTrustManager met een woordenboek [host: evaluator], geef dit door aan Session en gebruik het voor alle verzoeken aan beveiligde API's.