TLS-pinning och VPN-åtkomst besvarar olika frågor

Sätt en privat mobilapp bakom en VPN och en rimlig person frågar om den fortfarande behöver certifikatpinning. Frågan låter som ett val mellan två likvärdiga kontroller, och den är egentligen en fråga om två olika portar. VPN:n avgör om den här enheten ens får använda vägen; appen avgör om servern den nådde är den förväntade. Svara på båda var för sig och designen blir enklare.

Två portar, två frågor

Nätverksåtkomst handlar om klienten: är enheten registrerad, är dess legitimation giltig och tillåter policyn den här vägen? Apptillit handlar om servern: nådde anslutningen en tjänst med en identitet som appen accepterar? Dessa svar kommer från olika system, misslyckas av olika skäl och rättas av olika team. En VPN-handskakning kan lyckas medan appen talar med ett utgånget certifikat bakom peeren. En perfekt pinnad app kan ändå vara oåtkomlig för alla, eftersom enheten aldrig kom ut på nätverket.

De två adderas. Att släppa en tar bort en kontroll; att lägga till den andra ersätter den inte.

Vad en pin faktiskt begränsar

En pin snävar in mängden serveridentiteter som appen accepterar, vanligtvis genom att namnge en offentlig nyckel eller en certifikathash i stället för att lita på varje kedja ett arkiv skulle gå i god för. Det är en begränsning ovanpå vanlig validering, inte en ersättning för den. Vanlig validering svarar på om en kedja är tillförlitlig alls; pinnen svarar på om det är kedjan den här appen förväntar sig. En implementering som hoppar över första steget har inte vunnit säkerhet, bara nyhet.

Objektet som pinnas varierar mellan plattformar, så ordet ensamt säger dig väldigt lite. Att kopiera en hash från en produkts tillitslager och behandla den som samma sak i en mobilapp är ett vanligt och tyst fel.

Pinning på plattformen är en konfiguration, inte en policy

Android exponerar pinning via sin nätverkssäkerhetskonfiguration, där en pinnmängd håller digest av en offentlig nyckel och kedjan måste innehålla minst en av dem. Den filen är per app och kräver en medveten byggändring. iOS har ingen motsvarande manifestmekanism, så pinningen där lever i appens egen kod för tillitsbedömning.

Eftersom mekanismen skiljer sig måste kravet skrivas per plattform. En policy som säger pinna certifikatet utan att namnge plattformen är inte genomförbar.

Rotation avgör om pinnen överlever

Den svåra delen är inte första utgåvan, det är certifikatförnyelsen efteråt. En restriktiv tillitspolicy avvisar en legitim ny nyckel lika bestämt som en angripares.

Två mekanismer gör rotation överlevbar: en reservpin som redan är betrodd innan den behövs, och ett utgångsdatum på pinnmängden så att genomdrivandet upphör i stället för att göra appen obrukbar. Båda är policybeslut, och utgången är särskilt en medveten säkerhetssänkning, inte en oskyldig timer. Namnge vem som styr appens bygge, TLS-slutpunkten och certifikatförnyelsen, och sätt dem i en enda ändringsprocess. Om det är tre olika team kommer pinningen till slut att orsaka ett avbrott som ingen hade planerat.

En förlorad enhet är ett tredje problem

Att återkalla en VPN-legitimation avslutar inte nödvändigtvis en appsession, och en serverpin gör absolut ingenting åt en telefon i någon annans hand. Enhetslås, lagring av legitimation, sessionslivslängd och fjärråterkallning är separata beslut med separata ägare. Att vika in dem i pinningdiskussionen garanterar att ingen av dem blir designad.

Testa fyra relationer i stället för den enda du ser: den avsedda servern och operationen, ett konto som borde avvisas, en serveridentitet som borde förkastas och den planerade rotationen. En fungerande VPN övar bara den första. Skriv ned vad varje test bevisade, för nästa person kommer att anta att en grön tunnel betyder att alla fyra klarades.