Du har säkert hört talas om HTTPS och hur det gröna hänglåset i din webbläsare ger oss sinnesro. Men i apputvecklingens värld räcker det inte alltid att blint lita på att certifikatet är giltigt. Det finns en latent risk där någon, även med en krypterad anslutning, i hemlighet kan lyssna på vad som händer mellan din enhet och servern.
För att åtgärda denna säkerhetsbrist har en teknik som kallas Certificate Pinning utvecklats . I huvudsak säger den till vår applikation: "Lita inte på vilken certifikatutfärdare som helst; acceptera bara anslutningen om servern presenterar exakt detta certifikat eller denna publika nyckel." Det är som att sätta en mycket strikt grindvakt vid dörren till vår kommunikation.
Vad exakt är SSL-pinning och varför behöver vi det?
För att förstå detta ordentligt måste vi först komma ihåg att standard HTTPS är baserat på en förtroendekedja . När du ansluter till en server skickar den ditt digitala certifikat. Din mobila enhet kontrollerar att detta dokument har signerats av en certifikatutfärdare (CA) som operativsystemet litar på. Om signaturen är giltig och certifikatet inte har löpt ut upprättas anslutningen.
Problemet uppstår när en angripare lyckas infiltrera anslutningen mitt i attacken, den ökända Man-in-the-Middle (MITM)-attacken . Om hackaren får en certifikatutfärdare (CA) att utfärda ett bedrägligt men giltigt certifikat, eller om de lyckas installera ett skadligt rotcertifikat på offrets enhet, kommer operativsystemet att godkänna anslutningen. Vid den tidpunkten kan angriparen fånga upp och ändra känsliga uppgifter, såsom bankuppgifter eller lösenord, utan att användaren märker något ovanligt.
Det är här pinning kommer in i bilden. Istället för att lita på någon erkänd certifikatutfärdare lagrar appen en kopia av serverns certifikat eller hash för den publika nyckeln. Under handskakningen jämför appen det mottagna certifikatet med det den har lagrat. Om de inte matchar bit för bit avslutas anslutningen omedelbart, vilket förhindrar serverförfalskning.
Typer av förankring: Certifikat kontra publika nycklar
All pinning görs inte på samma sätt. Beroende på vad vi väljer att "pinna" har vi två huvudsakliga metoder. Den första är Certificate Pinning , där vi lagrar hela certifikatfilen (.pem eller .der). Det är det enklaste alternativet att implementera men det mest mödosamma att underhålla, eftersom vi varje gång servercertifikatet löper ut och förnyas måste uppdatera applikationen i arkivet, annars förlorar användarna tjänsten.
Det andra alternativet är Public Key Pinning . I det här fallet lagrar vi bara hashen (vanligtvis SHA-256) för certifikatets publika nyckel. Den största fördelen är att den publika nyckeln kan förbli intakt även om certifikatet förnyas, vilket ger oss större certifikatflexibilitet och minskar frekvensen av påtvingade appuppdateringar. Genom att bara lagra en hash blir koden dessutom renare och svårare för någon som försöker sig på reverse engineering att extrahera.
Teknisk implementering pĂĄ olika plattformar
Om vi ​​arbetar med AndroidDet modernaste sättet är att använda filen network_security_config.xmlI den här XML-filen definierar vi domänerna och hashkoderna för de certifikat (PIN-koder) som vi vill auktorisera, vilket gör att vi kan Aktivera viktiga säkerhetsinställningar på Android direkt. Sedan länkar vi helt enkelt den här filen i AndroidManifest.xmlFörr i tiden gjordes mer komplexa saker genom att skriva över klassen. DefaultHttpClient och hantera Java-certifikatarkiv via keytoolXML-baserad konfiguration är dock mycket effektivare.
I ekosystemet av iOSSaker och ting förändras lite. Vi kan dra nytta av App Transport Security (ATS) genom att konfigurera filen Info.plist för att definiera de förankrade domänerna. För fullständig kontroll är det dock vanligt att implementera runtime-validering med hjälp av URLSessionDelegateI autentiseringsutmaningsmetoden extraherar vi certifikatet från servern och jämför det med lokalt lagrat certifikat i applikationspaketet.
För de som använder Kondensator- eller hybridramverkDet finns plugins som @capgo/capacitor-ssl-pinning som förenar processen. I dessa fall görs konfigurationen vanligtvis i appens konfigurationsfil, vilket anger certifikatlistan och aktiverar validering. Det är viktigt att testa dessa implementeringar med verktyg som Charles Proxy, simulerar en MITM-attack för att bekräfta att applikationen effektivt avvisar anslutningen när certifikatet inte är det förväntade.
Risker, begränsningar och underhåll
Att fästa är inte bara solsken och rosor. Den största faran är det som kallas utgångsspärr . Om servercertifikatet går ut och du inte har uppdaterat appen med den nya PIN-koden kommer alla dina användare att se anslutningsfel. För att undvika denna katastrof är det bästa att implementera reserv-PIN-koder . Vi lagrar hashen för en sekundär offentlig nyckel som vi bara använder i nödfall eller oväntad rotation.
Å andra sidan kan pinning vara ett huvudbry för utvecklare som behöver felsöka sin kommunikation. För att övervakningsverktyg ska fungera är det ibland nödvändigt att inaktivera pinning i utvecklingsmiljöer eller skapa specifika felsökningsversioner, och alltid se till att den här funktionen är aktiverad i produktionsversionen som når slutanvändaren.
När det gäller webben var Chrome en pionjär i att implementera liknande koncept. Den använder HSTS (HTTP Strict Transport Security) för att upprätthålla användningen av HTTPS och upprätthåller en lista över "förinstallerade" webbplatser för att förhindra sårbarhet vid första kontakt. Även om HPKP-standarden fanns för webben, föll den så småningom i obruk eftersom den var för riskabel och kunde göra webbplatser oåtkomliga om ett konfigurationsfel uppstod.
Att implementera certifikatfästning är ett strategiskt beslut som balanserar maximal säkerhet med tjänstens driftsäkerhet. Genom att begränsa förtroendet till specifika enheter skyddar vi kommunikationen mot sofistikerade attacker, förutsatt att vi upprätthåller rigorös kontroll över livscykeln för våra nycklar och certifikat för att undvika att lämna kunder utan åtkomst.
