Je hebt vast wel eens gehoord van HTTPS en hoe het groene hangslotje in je browser je een gerust gevoel geeft. In de wereld van app-ontwikkeling is blindelings vertrouwen op de geldigheid van het certificaat echter niet altijd voldoende. Er bestaat een verborgen risico: zelfs met een versleutelde verbinding kan iemand stiekem meeluisteren met wat er tussen je apparaat en de server gebeurt.
Om deze beveiligingskwetsbaarheid aan te pakken, is een techniek genaamd Certificate Pinning ontwikkeld . In essentie vertelt deze techniek onze applicatie: "Vertrouw niet zomaar elke certificeringsinstantie; accepteer de verbinding alleen als de server dit specifieke certificaat of deze publieke sleutel presenteert." Het is alsof we een zeer strenge poortwachter bij de deur van onze communicatie plaatsen.
Wat is SSL-pinning precies en waarom hebben we het nodig?
Om dit goed te begrijpen, moeten we eerst bedenken dat standaard HTTPS gebaseerd is op een vertrouwensketen . Wanneer je verbinding maakt met een server, stuurt deze je een digitaal certificaat. Je mobiele apparaat controleert of dit document is ondertekend door een certificeringsinstantie (CA) die door het besturingssysteem wordt vertrouwd. Als de handtekening geldig is en het certificaat niet is verlopen, wordt de verbinding tot stand gebracht.
Het probleem ontstaat wanneer een aanvaller erin slaagt de verbinding halverwege te infiltreren, de beruchte Man-in-the-Middle (MITM)-aanval . Als de hacker een certificeringsinstantie (CA) zover krijgt om een ​​frauduleus maar geldig certificaat uit te geven, of als hij erin slaagt een kwaadaardig rootcertificaat op het apparaat van het slachtoffer te installeren, zal het besturingssysteem de verbinding goedkeuren. Op dat moment kan de aanvaller gevoelige gegevens, zoals bankgegevens of wachtwoorden, onderscheppen en wijzigen zonder dat de gebruiker iets merkt.
Hier komt pinning om de hoek kijken. In plaats van een erkende CA te vertrouwen, slaat de app een kopie van het certificaat of de hash van de publieke sleutel van de server op. Tijdens de handshake vergelijkt de app het ontvangen certificaat met het opgeslagen certificaat. Als ze niet bit voor bit overeenkomen, wordt de verbinding onmiddellijk verbroken, waardoor serverspoofing wordt voorkomen .
Soorten verankering: certificaten versus openbare sleutels
Niet alle pinning werkt op dezelfde manier. Afhankelijk van wat we willen "pinnen", zijn er twee belangrijke benaderingen. De eerste is certificaatpinning , waarbij we het volledige certificaatbestand (.pem of .der) opslaan. Dit is de eenvoudigste optie om te implementeren, maar ook de meest bewerkelijke om te onderhouden. Telkens wanneer het servercertificaat verloopt en vernieuwd moet worden, moeten we de applicatie in de certificaatopslag bijwerken, anders verliezen gebruikers de toegang tot de service.
De tweede optie is Public Key Pinning . In dit geval slaan we alleen de hash (meestal SHA-256) van de publieke sleutel van het certificaat op. Het grootste voordeel hiervan is dat de publieke sleutel intact blijft, zelfs als het certificaat wordt vernieuwd. Dit geeft ons meer flexibiliteit met certificaten en vermindert de frequentie van verplichte app-updates. Bovendien is de code, door alleen een hash op te slaan, overzichtelijker en moeilijker te achterhalen voor iemand die reverse engineering toepast.
Technische implementatie op verschillende platforms
Als we samenwerken met AndroidDe modernste manier is om het bestand te gebruiken. network_security_config.xmlIn dit XML-bestand definiëren we de domeinen en hashes van de certificaten (pincodes) die we willen autoriseren, waardoor we het volgende kunnen doen: Activeer essentiële beveiligingsinstellingen op Android. native. Vervolgens koppelen we dit bestand eenvoudigweg in de AndroidManifest.xmlIn het verleden werden complexere zaken opgelost door de klasse te overschrijven. DefaultHttpClient en het beheren van Java-certificaatarchieven via keytoolDe XML-gebaseerde configuratie is echter veel efficiënter.
In het ecosysteem van iOSDe situatie verandert enigszins. We kunnen gebruikmaken van App Transport Security (ATS) door het bestand te configureren. Info.plist om de verankerde domeinen te definiëren. Voor volledige controle is het echter gebruikelijk om runtime-validatie te implementeren met behulp van URLSessionDelegateBij de authenticatie-uitdagingmethode halen we het certificaat van de server op en vergelijken we het met de lokaal opgeslagen certificaat in het applicatiepakket.
Voor degenen die gebruiken Condensator- of hybride frameworksEr zijn plugins zoals @capgo/capacitor-ssl-pinning die het proces verenigen. In deze gevallen wordt de configuratie meestal gedaan in het configuratiebestand van de app, waarbij de certificatenlijst wordt gespecificeerd en validatie wordt ingeschakeld. Het is essentieel om deze implementaties te testen met tools zoals Charles volmachtwaarbij een MITM-aanval wordt gesimuleerd om te bevestigen dat de applicatie de verbinding daadwerkelijk weigert wanneer het certificaat niet het verwachte certificaat is.
Risico's, beperkingen en onderhoud
Het gebruik van pincodes is niet zonder risico's. Het grootste gevaar is de zogenaamde ' vervaldatum-lockout' . Als het servercertificaat verloopt en u de app niet hebt bijgewerkt met de nieuwe pincode, zullen al uw gebruikers verbindingsfouten zien. Om dit te voorkomen, is het raadzaam om back-up-pincodes te implementeren . We slaan de hash op van een secundaire publieke sleutel die we alleen gebruiken in geval van nood of onverwachte wijziging.
Aan de andere kant kan het vastzetten van communicatiekanalen een hoofdpijn opleveren voor ontwikkelaars die hun communicatie moeten debuggen. Om monitoringtools te laten werken, is het soms nodig om het vastzetten van communicatiekanalen in ontwikkelomgevingen uit te schakelen of specifieke debugversies te maken. Zorg er altijd voor dat deze functionaliteit is ingeschakeld in de productieversie die de eindgebruiker bereikt.
Wat het web betreft, was Chrome een pionier in het implementeren van vergelijkbare concepten. Het gebruikt HSTS (HTTP Strict Transport Security) om het gebruik van HTTPS af te dwingen en houdt een lijst bij van "vooraf geladen" sites om kwetsbaarheden bij het eerste contact te voorkomen. Hoewel de HPKP-standaard ook voor het web bestond, raakte deze uiteindelijk in onbruik omdat deze te riskant was en websites ontoegankelijk kon maken als er een configuratiefout optrad.
Het implementeren van certificaatpinning is een strategische beslissing die een balans vindt tussen maximale beveiliging en de operationele betrouwbaarheid van de dienstverlening. Door het vertrouwen te beperken tot specifieke entiteiten, beschermen we de communicatie tegen geavanceerde aanvallen, mits we strikte controle behouden over de levenscyclus van onze sleutels en certificaten om te voorkomen dat klanten zonder toegang komen te zitten.
