SSL/TLS: nyckelbegrepp och protokoll inom programmering

Vad är SSL/TLS?

SSL (Secure Sockets Layer) och TLS (Transport Layer Security) — kryptografiska protokoll som garanterar säker dataöverföring över nätverket. SSL, utvecklat av Netscape på 1990-talet, förklarades föråldrat efter version 3.0 på grund av sårbarheterna POODLE och BEAST. TLS, dess efterträdare, har gått igenom versionerna 1.0, 1.1, 1.2 och 1.3 — för närvarande anses endast TLS 1.2 och TLS 1.3 vara aktuella. Alla moderna mobilplattformar kräver användning av TLS för nätverksanslutningar, och App Store och Google Play kontrollerar detta vid granskningsstadiet.

Varför TLS behövs för mobilappar

Utan TLS överförs trafik mellan appen och servern som klartext — vem som helst i samma Wi-Fi-nätverk kan avlyssna användarnamn, lösenord, tokens och personuppgifter med Wireshark eller tcpdump. TLS krypterar all överförd data (kryptering på transportnivå) och verifierar serverns äkthet via kedjan av X.509-certifikat. Enligt IETF (2018) använder TLS 1.3 endast moderna AEAD-chiffer (AES-GCM, ChaCha20-Poly1305) och exkluderar föråldrade algoritmer som RC4 och 3DES.

HTTPS och TLS

HTTPS (HTTP Secure) — är HTTP över TLS. När en mobilapp gör en begäran via https:// upprättar den först en TLS-anslutning till servern och överför därefter HTTP-huvuden och begärandets kropp via den krypterade kanalen. Utan HTTPS bör inget seriöst API fungera — detta är grundläggande säkerhetshygien. Enligt OWASP (2026) finns osäkra anslutningar bland de 3 främsta sårbarheterna i mobilappar.

Hur TLS Handshake fungerar

TLS Handshake — processen för att upprätta en säker anslutning mellan klient och server. Parterna förhandlar om protokollversion, väljer chiffer-svit (cipher suite), utbyter nycklar via asymmetrisk kryptografi och verifierar certifikat. I TLS 1.2 kräver handshake 2 Round Trip Time (2 RTT): klient → server med ClientHello, server → klient med ServerHello och Certificate, därefter de slutliga meddelandena Finished. TLS 1.3 förkortar denna process till 1 RTT.

Detaljerade steg i TLS 1.2 handshake

Första steget: ClientHello — klienten skickar versioner av TLS som stöds, en lista över chiffer-sviter och ett slumpmässigt nummer. Servern svarar med ServerHello, väljer version och chiffer-svit, skickar sitt X.509-certifikat (Certificate) och meddelandet ServerHelloDone. Klienten verifierar certifikatet via kedjan av betrodda certifikatutfärdare (CA), genererar pre-master secret, krypterar det med den offentliga nyckeln från certifikatet och skickar det till servern i ClientKeyExchange. Därefter genererar båda parter sessionsnycklar och utbyter ChangeCipherSpec- och Finished-meddelanden. Från och med detta ögonblick krypteras all data symmetriskt.

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

Exempel på hantering av URLAuthenticationChallenge på iOS via URLSessionDelegate. Denna metod anropas vid varje TLS Handshake, vilket gör att appen kan verifiera serverns certifikat på ett anpassat sätt. För produktion, lägg till certifikatverifiering via SecTrustEvaluateWithError och jämför med det förhands sparade fingeravtrycket — först därefter anropa useCredential.

TLS 1.2 vs TLS 1.3

TLS 1.3 (RFC 8446, 2018) — den första stora uppdateringen av protokollet på 10 år. Viktigaste förbättringarna: handshake minskad till 1 RTT (0 RTT för återanslutningar), föråldrade chiffer-sviter (RSA key exchange, CBC-mode) borttagna, obligatorisk forward secrecy (PFS) och skydd mot downgrade-attacker via signed transcript. Enligt Qualys SSL Labs (2026) ger TLS 1.3 skydd även vid kompromettering av långtidsservernyckeln tack vare PFS.

0-RTT (Zero Round Trip Time) — funktion i TLS 1.3 som gör att klienten vid återanslutning via PSK (Pre-Shared Key) kan skicka data omedelbart tillsammans med ClientHello. Detta snabbar upp laddningen av efterföljande skärmar i mobilappar, särskilt vid frekventa förfrågningar till samma server. 0-RTT-data är dock inte skyddade mot replay-attacker — de kan avlyssnas och skickas igen. Använd 0-RTT endast för idempotenta förfrågningar (GET, PUT) utan sidoeffekter.

TLS på iOS: App Transport Security

App Transport Security (ATS) — Apples mekanism som kräver HTTPS-anslutningar med TLS 1.2 eller högre, aktiverad som standard från iOS 9. ATS blockerar alla HTTP-anslutningar och HTTPS med TLS under 1.2. Utvecklaren kan konfigurera undantag i Info.plist via NSAppTransportSecurity för specifika domäner, men Apple rekommenderar att minimera undantag och använda HTTPS överallt. Brott mot ATS-kraven är en anledning till avvisning av appen vid App Store-granskning.

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

Konfiguration av ATS i Info.plist. NSAllowsArbitraryLoads är inställt på false — alla anslutningar måste använda HTTPS. För domänen cdn.example.com är lägsta TLS 1.2-version inställd, NSAllowsLocalNetworking=true tillåter HTTP för lokalt nätverk (användbart för utvecklingsservrar). Apple rekommenderar starkt att inte aktivera NSAllowsArbitraryLoads utan NSExceptionDomains — detta bör vara ett undantag, inte en allmän regel.

TLS på Android: Network Security Config

Network Security Config — Androids mekanism för att konfigurera HTTPS och TLS utan att ändra Java/Kotlin-kod. Konfigurationen definieras i XML-filen network_security_config.xml och kopplas i AndroidManifest via attributet android:networkSecurityConfig. Den stöder konfiguration av betrodda certifikat (user och system CA), Certificate Pinning, inaktivering av cleartext HTTP, debug-överskrivningar och trafikomdirigering.

<!-- 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 för Android. Base-config förbjuder cleartext-trafik och litar endast på systemets CA-certifikat (utan användarcertifikat — skydd mot installation av MitM-certifikat av användaren). Domain-config för api.example.com innehåller en pin-set med certifikatets SHA-256-fingeravtryck. Om servercertifikatet ändras före det angivna utgångsdatumet kommer anslutningen att avvisas — detta är en strikt form av Certificate Pinning.

Certificate Pinning och säkerhet

Certificate Pinning — teknik för att fixera serverns certifikat eller offentliga nyckel i appkoden. Vid varje TLS Handshake jämför klienten servercertifikatet med det förhands sparade fingeravtrycket (SHA-256-hash). Även om en angripare får ett betrott CA-certifikat eller komprometterar en certifikatutfärdare kan han inte utföra en MitM-attack — appen kontrollerar det specifika fingeravtrycket, inte CA-kedjan. Detta är särskilt viktigt för finansiella appar och appar med känslig data.

Risker och alternativ till Pinning

Certificate Pinning kräver försiktighet: när certifikatet på servern ändras kommer alla gamla versioner av appen inte att kunna ansluta. Det rekommenderas att lagra flera reservfingeravtryck (primärt + reserv), ange utgångsdatum för pin-set och implementera en fallback-mekanism via standard CA-verifiering. Ett alternativ är Trust On First Use (TOFU), där appen memorerar certifikatet vid första anslutningen och varnar användaren vid ändring. Enligt OWASP (2026) finns avsaknad av Certificate Pinning bland de 3 främsta sårbarheterna i mobilappar (M3: Insecure Communication).

Implementera Pinning i Alamofire

I Alamofire 5+ konfigureras Certificate Pinning via ServerTrustManager med PinnedCertificatesTrustEvaluator (kontroll av hela certifikatet) eller PublicKeysTrustEvaluator (endast offentlig nyckel). Den offentliga nyckeln är att föredra — den ändras inte vid certifikatförnyelse hos samma CA. Skapa en ServerTrustManager med ordlistan [host: evaluator], skicka den till Session och använd den för alla förfrågningar till skyddade API:er.