SSL/TLS — vad det är, protokoll och krypteringens funktionsprincip

Vad är SSL/TLS?

SSL (Secure Sockets Layer) — är ett protokoll utvecklat av Netscape 1995 för att skydda webbtrafik. Den första versionen SSL 1.0 publicerades aldrig, SSL 2.0 (1995) och SSL 3.0 (1996) användes fram till början av 2000-talet men innehöll kritiska sårbarheter. I stället för SSL kom TLS (Transport Layer Security) — en förbättrad version standardiserad av IETF. TLS 1.0 (1999) baserades på SSL 3.0, och efterföljande versioner TLS 1.1 (2006), TLS 1.2 (2008) och TLS 1.3 (2018) avlägsnade sig gradvis från den ursprungliga arkitekturen, lade till nya krypteringsalgoritmer och eliminerade sårbarheter. Idag anses SSL vara föråldrat och alla moderna system använder TLS, även om båda protokollen av gammal vana ofta nämns tillsammans som SSL/TLS.

Protokollets historia

Historien om SSL/TLS började med behovet av säker dataöverföring i den tidiga webben. 1994 utvecklade Netscape SSL 1.0 för sin Navigator-webbläsare, men protokollet publicerades aldrig på grund av allvarliga säkerhetsproblem. SSL 2.0 släpptes 1995 och användes i praktiken, men innehöll många sårbarheter: brist på skydd mot Man-in-the-Middle-attacker, svaga krypteringsalgoritmer och sårbarhet för truncation-attacker. SSL 3.0 (1996) åtgärdade de flesta problemen, men år 2014 upptäcktes sårbarheten POODLE, varefter IETF officiellt förklarade alla versioner av SSL som föråldrade. TLS 1.0–1.3 förbättrade successivt kryptografisk styrka, prestanda och konfidentialitet, där TLS 1.3 minskade handshake från två round-trips till en, vilket är avgörande för mobilappar med instabil anslutning.

Hur SSL/TLS Handshake fungerar

Handshake — är processen för att upprätta en säker anslutning mellan klient och server. Den består av flera på varandra följande steg där parterna kommer överens om protokollversion, väljer krypteringsalgoritmer, utbyter nycklar och autentiserar varandra. I TLS 1.3 tar handshake bara en nätverksinteraktion (1-RTT), medan det i TLS 1.2 krävdes två (2-RTT).

I första steget skickar klienten ClientHello — ett meddelande som innehåller en lista över TLS-versioner som stöds, cipher suites och ett slumpmässigt tal. Servern svarar med ServerHello med vald version och chiffer, sitt X.509-certifikat och digitala signatur. Klienten verifierar certifikatet via kedjan av certifikatutfärdare (CA), genererar en sessionsnyckel och skickar den krypterad med serverns publika nyckel från certifikatet. Efter bekräftelse från servern börjar säker dataöverföring. Hela handshake utförs på 1–3 millisekunder på moderna enheter, vilket gör den osynlig för användaren.

X.509-certifikat och förtroendekedja

Grunden för TLS-autentisering är infrastrukturen för publika nycklar (PKI) byggd på certifikat i X.509-format. Varje certifikat innehåller: domännamn (Common Name eller Subject Alternative Name), serverns publika nyckel, utfärdarens namn (Certificate Authority), giltighetsperiod och CA:s digitala signatur. Klienten verifierar serverns certifikat via förtroendekedjan: från servercertifikatet till rot-CA, vars certifikat är inbyggt i operativsystemet. På Android-enheter lagras rotcertifikat i systemförrådet som uppdateras via Google Play Services; i iOS — via iOS Updates. Vid brott mot någon länk i kedjan (utgånget certifikat, domänmatchning misslyckas, okänd CA) avbryter klienten anslutningen. För självsignerade certifikat (används vid utveckling) krävs explicit förtroende — i Android via Network Security Config, i iOS via NSExceptionDomains i Info.plist. Valideringsprocessen för certifikatkedjan inkluderar även kontroll av återkallningsstatus via CRL (Certificate Revocation List) eller OCSP (Online Certificate Status Protocol), även om OCSP-förfrågningar på mobila enheter ofta hoppas över för att påskynda anslutningen — detta är en kompromiss mellan säkerhet och prestanda som arkitekter bör överväga.

SSL vs TLS: viktiga skillnader

Även om termerna SSL och TLS ofta används som synonymer, finns det grundläggande tekniska skillnader mellan dem som påverkar säkerheten och prestandan för mobilappar.

Den största skillnaden med TLS 1.3 jämfört med föregångarna — obligatorisk användning av Perfect Forward Secrecy (PFS) via ECDHE-protokollet. Detta innebär att även om en angripare får tillgång till serverns privata nyckel, kan den inte dekryptera tidigare avlyssnad trafik. För mobilappar där serverintrång är ett verkligt hot är TLS 1.3 med PFS ett obligatoriskt säkerhetskrav.

Kända sårbarheter i äldre versioner

Föråldrade versioner av SSL och TLS har dokumenterade sårbarheter som gör dem olämpliga för produktionsanvändning. POODLE (CVE-2014-3566) attackerar SSL 3.0 via padding oracle och möjliggör dekryptering av sessionskakan på 256 förfrågningar. BEAST (CVE-2011-3389) utnyttjar sårbarheten i TLS 1.0 i CBC-läge via förutsägbar IV. Heartbleed (CVE-2014-0160) — är inte en protokollsårbarhet utan ett fel i OpenSSL-implementationen som gör det möjligt att läsa serverminne: enligt Netcraft var över 500 000 servrar sårbara 2014. Från och med Android 10 (API 29) och iOS 13 är alla nämnda protokoll inaktiverade på systemnivå. Utvecklare bör ändå kontrollera serverkonfigurationen via SSL Labs Test (qualys.com) innan appen lanseras för att säkerställa att inga föråldrade cipher suites finns och att TLS 1.3 stöds.

Hur SSL/TLS skyddar data i mobilappar

I mobilappar skyddar TLS data på tre nivåer: innehållskryptering (ingen utom servern kan läsa data), integritetskontroll (data kan inte ändras under överföring) och serverautentisering (klienten är säker på att den ansluter till rätt server). Autentisering är särskilt kritisk: utan den kan en angripare ersätta servern via DNS-spoofing eller en falsk Wi-Fi-åtkomstpunkt.

Enligt Google Play Protect-studien (2024) använder 76% av Android-apparna TLS korrekt med certifikatkontroll. De återstående 24% gör misstag: stänger av certifikatkontroll för testning (och glömmer att slå på den i produktion), använder självsignerade certifikat utan validering eller tillåter föråldrade protokoll SSL 3.0 och TLS 1.0. Apple App Transport Security (ATS) i iOS kräver minst TLS 1.2 sedan 2017, och från iOS 15 använder den som standard TLS 1.3 för alla nätverksförfrågningar. För extra skydd rekommenderas även implementering av Certificate Pinning — fastsättning till ett specifikt servercertifikat.

Implementering av SSL/TLS i mobilappar

Låt oss titta på ett exempel på konfiguration av en säker HTTPS-anslutning i Android med OkHttp — ett av de mest populära biblioteken för nätverksarbete. Korrekt konfiguration inkluderar obligatorisk användning av TLS 1.3 och certifikatkontroll.

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

I detta exempel begränsar vi uppsättningen av TLS-versioner som stöds till endast protokoll 1.3 och 1.2, med uteslutning av föråldrade TLS 1.0/1.1. Cipher suites väljs från moderna algoritmer med AEAD-läge och obligatorisk Perfect Forward Secrecy. HostnameVerifier kontrollerar att värdnamnet matchar certifikatet. För iOS görs en liknande konfiguration via URLSession-konfiguration med parametern tlsMinimumSupportedProtocolVersion, där .TLSv13 anges. Dessutom kan tlsMaximumSupportedProtocolVersion ställas in i iOS för att begränsa den övre versionsgränsen — detta är användbart för kompatibilitet med äldre servrar som ännu inte har migrerat till TLS 1.3. En sådan konfiguration garanterar maximal säkerhetsnivå vid dataöverföring i mobilappen.