SSL/TLS — wat is het, protocollen en het werkingsprincipe van versleuteling

Wat is SSL/TLS?

SSL (Secure Sockets Layer) — is een protocol ontwikkeld door Netscape in 1995 om webverkeer te beveiligen. De eerste versie SSL 1.0 is nooit gepubliceerd, SSL 2.0 (1995) en SSL 3.0 (1996) werden gebruikt tot begin 2000, maar bevatten kritieke kwetsbaarheden. In de plaats van SSL kwam TLS (Transport Layer Security) — een verbeterde versie gestandaardiseerd door de IETF. TLS 1.0 (1999) was gebaseerd op SSL 3.0, en de volgende versies TLS 1.1 (2006), TLS 1.2 (2008) en TLS 1.3 (2018) verwijderden zich geleidelijk van de oorspronkelijke architectuur, voegden nieuwe versleutelingsalgoritmen toe en verhelpen kwetsbaarheden. Vandaag de dag wordt SSL als verouderd beschouwd en gebruiken alle moderne systemen TLS, hoewel beide protocollen uit gewoonte vaak samen als SSL/TLS worden genoemd.

Geschiedenis van het protocol

De geschiedenis van SSL/TLS begon met de behoefte aan beveiligde gegevensoverdracht in het vroege web. In 1994 ontwikkelde Netscape SSL 1.0 voor zijn Navigator-browser, maar het protocol werd nooit gepubliceerd vanwege ernstige beveiligingsproblemen. SSL 2.0 werd uitgebracht in 1995 en werd in de praktijk gebruikt, maar bevatte talloze kwetsbaarheden: gebrek aan bescherming tegen Man-in-the-Middle-aanvallen, zwakke versleutelingsalgoritmen en gevoeligheid voor truncation-aanvallen. SSL 3.0 (1996) verhelpen de meeste problemen, maar in 2014 werd de POODLE-kwetsbaarheid ontdekt, waarna de IETF officieel alle versies van SSL als verouderd verklaarde. TLS 1.0–1.3 hebben achtereenvolgens de cryptografische sterkte, prestaties en vertrouwelijkheid verbeterd, waarbij TLS 1.3 de handshake van twee round-trips naar één heeft teruggebracht, wat cruciaal is voor mobiele apps met een onstabiele verbinding.

Hoe werkt SSL/TLS Handshake

Handshake — is het proces van het tot stand brengen van een beveiligde verbinding tussen client en server. Het bestaat uit verschillende opeenvolgende stappen waarbij de partijen de protocolversie afstemmen, versleutelingsalgoritmen kiezen, sleutels uitwisselen en elkaar authenticeren. In TLS 1.3 duurt de handshake slechts één netwerkinteractie (1-RTT), terwijl in TLS 1.2 twee (2-RTT) nodig waren.

In de eerste stap stuurt de client ClientHello — een bericht met een lijst van ondersteunde TLS-versies, cipher suites en een willekeurig getal. De server antwoordt met ServerHello met de gekozen versie en cipher, zijn X.509-certificaat en digitale handtekening. De client controleert het certificaat via de keten van certificeringsinstanties (CA), genereert een sessiesleutel en stuurt deze versleuteld met de openbare sleutel van de server uit het certificaat. Na bevestiging door de server begint de beveiligde gegevensoverdracht. De hele handshake wordt uitgevoerd in 1–3 milliseconden op moderne apparaten, wat het onzichtbaar maakt voor de gebruiker.

X.509-certificaten en de vertrouwensketen

De basis van TLS-authenticatie is de infrastructuur voor openbare sleutels (PKI), gebouwd op certificaten in X.509-formaat. Elk certificaat bevat: de domeinnaam (Common Name of Subject Alternative Name), de openbare sleutel van de server, de naam van de uitgever (Certificate Authority), de geldigheidsperiode en de digitale handtekening van de CA. De client controleert het servercertificaat via de vertrouwensketen: van het servercertificaat tot de root-CA, waarvan het certificaat in het besturingssysteem is ingebouwd. Op Android-apparaten worden root-certificaten opgeslagen in de systeemopslag die wordt bijgewerkt via Google Play Services; in iOS — via iOS Updates. Bij schending van een schakel in de keten (verlopen certificaat, domeinnaam komt niet overeen, onbekende CA) verbreekt de client de verbinding. Voor zelf-ondertekende certificaten (gebruikt in ontwikkeling) is expliciet vertrouwen vereist — in Android via Network Security Config, in iOS via NSExceptionDomains in Info.plist. Het validatieproces van de certificaatketen omvat ook het controleren van de intrekkingsstatus via CRL (Certificate Revocation List) of OCSP (Online Certificate Status Protocol), hoewel op mobiele apparaten OCSP-verzoeken vaak worden overgeslagen om de verbinding te versnellen — dit is een compromis tussen beveiliging en prestaties waar architecten rekening mee moeten houden.

SSL vs TLS: belangrijkste verschillen

Hoewel de termen SSL en TLS vaak als synoniemen worden gebruikt, zijn er fundamentele technische verschillen tussen die de beveiliging en prestaties van mobiele apps beïnvloeden.

Het belangrijkste verschil van TLS 1.3 ten opzichte van voorgangers — het verplichte gebruik van Perfect Forward Secrecy (PFS) via het ECDHE-protocol. Dit betekent dat zelfs als een aanvaller toegang krijgt tot de privésleutel van de server, hij eerder onderschept verkeer niet kan ontsleutelen. Voor mobiele apps, waar serverinbraak een reële bedreiging is, is TLS 1.3 met PFS een verplichte beveiligingseis.

Bekende kwetsbaarheden van oude versies

Verouderde versies van SSL en TLS hebben gedocumenteerde kwetsbaarheden die ze ongeschikt maken voor productiegebruik. POODLE (CVE-2014-3566) valt SSL 3.0 aan via padding oracle, waardoor sessiecookies in 256 verzoeken kunnen worden ontsleuteld. BEAST (CVE-2011-3389) maakt misbruik van de kwetsbaarheid van TLS 1.0 in CBC-modus via een voorspelbare IV. Heartbleed (CVE-2014-0160) — is geen protocolkwetsbaarheid, maar een fout in de OpenSSL-implementatie waarmee servergeheugen kan worden gelezen: volgens Netcraft waren in 2014 meer dan 500.000 servers kwetsbaar. Vanaf Android 10 (API 29) en iOS 13 zijn alle genoemde protocollen uitgeschakeld op systeemniveau. Desalniettemin moeten ontwikkelaars de serverconfiguratie controleren via SSL Labs Test (qualys.com) voordat ze de app lanceren om te controleren of er geen verouderde cipher suites zijn en TLS 1.3 wordt ondersteund.

Hoe SSL/TLS gegevens beschermt in mobiele apps

In mobiele apps beschermt TLS gegevens op drie niveaus: inhoudsversleuteling (niemand behalve de server kan de gegevens lezen), integriteitscontrole (gegevens kunnen niet onderweg worden gewijzigd) en serverauthenticatie (de client is er zeker van dat hij met de juiste server verbinding maakt). Authenticatie is bijzonder kritiek: zonder kan een aanvaller de server vervangen via DNS-spoofing of een vals Wi-Fi-toegangspunt.

Volgens onderzoek van Google Play Protect (2024) gebruikt 76% van de Android-apps TLS correct met certificaatcontrole. De overige 24% maakt fouten: schakelt certificaatcontrole uit voor testen (en vergeet het in productie in te schakelen), gebruikt zelf-ondertekende certificaten zonder validatie of staat verouderde protocollen SSL 3.0 en TLS 1.0 toe. Apple App Transport Security (ATS) in iOS vereist sinds 2017 minimaal TLS 1.2, en vanaf iOS 15 gebruikt het standaard TLS 1.3 voor alle netwerkverzoeken. Voor extra bescherming wordt ook aanbevolen Certificate Pinning te implementeren — het vastpinnen aan een specifiek servercertificaat.

Implementatie van SSL/TLS in mobiele apps

Laten we een voorbeeld bekijken van het configureren van een beveiligde HTTPS-verbinding in Android met OkHttp — een van de populairste bibliotheken voor netwerkwerk. De juiste configuratie omvat het geforceerd gebruiken van TLS 1.3 en certificaatcontrole.

val client = OkHttpClient.Builder()
    .connectionSpecs(
        listOf(
            ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
                .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
                .cipherSuites(
                    CipherSuite.TLS_AES_128_GCM_SHA256,
                    CipherSuite.TLS_AES_256_GCM_SHA384,
                    CipherSuite.TLS_CHACHA20_POLY1305_SHA256
                )
                .build()
        )
    )
    .hostnameVerifier { hostname, session ->
        SSLSession.DefaultHostnameVerifier.verify(hostname, session)
    }
    .build()

In dit voorbeeld beperken we de set ondersteunde TLS-versies tot alleen protocollen 1.3 en 1.2, met uitsluiting van verouderde TLS 1.0/1.1. Cipher suites worden gekozen uit moderne algoritmen met AEAD-modus en verplichte Perfect Forward Secrecy. HostnameVerifier controleert of de hostnaam overeenkomt met het certificaat. Voor iOS wordt een vergelijkbare configuratie uitgevoerd via URLSession-configuratie met de parameter tlsMinimumSupportedProtocolVersion, waar .TLSv13 wordt opgegeven. Bovendien kan in iOS tlsMaximumSupportedProtocolVersion worden ingesteld om de bovenste versielimiet te beperken — dit is nuttig voor compatibiliteit met oudere servers die nog niet zijn overgestapt op TLS 1.3. Een dergelijke configuratie garandeert het maximale beveiligingsniveau bij gegevensoverdracht in de mobiele app.