Prikvačivanje TLS-a i VPN pristup odgovaraju na različita pitanja

Stavite privatnu mobilnu aplikaciju iza VPN-a i razumna osoba će pitati treba li joj još uvijek prikvačivanje certifikata. Pitanje zvuči kao izbor između dvije ravnopravne kontrole, a zapravo je pitanje o dva različita ulaza. VPN odlučuje smije li ovaj uređaj uopće koristiti putanju; aplikacija odlučuje je li server koji je dostigla onaj koji je očekivala. Odgovorite na oboje odvojeno i dizajn postaje jednostavniji.

Dva ulaza, dva pitanja

Pristup mreži tiče se klijenta: je li ovaj uređaj upisan, je li njegov akreditiv valjan i dopušta li mu politika ovu putanju? Povjerenje aplikacije tiče se servera: je li veza stigla do usluge s identitetom koji aplikacija prihvaća? Ti odgovori dolaze iz različitih sistema, padaju iz različitih razloga i popravljaju ih različiti timovi. VPN rukovanje može uspjeti dok aplikacija razgovara s isteklim certifikatom iza partnera. Besprijekorno prikvačena aplikacija može ostati nedostupna svima, jer uređaj nikada nije došao na mrežu.

Oboje se sabira. Ispuštanje bilo kojeg uklanja kontrolu; dodavanje jednog ne zamjenjuje drugo.

Šta prikvačivanje zapravo ograničava

Prikvačivanje sužava skup identiteta servera koje će aplikacija prihvatiti, obično imenovanjem javnog ključa ili heša certifikata umjesto vjerovanja svakom lancu za koji bi neko skladište jamčilo. To je ograničenje naslagano na uobičajenu provjeru, a ne njezina zamjena. Uobičajena provjera odgovara je li lanac uopće pouzdan; prikvačivanje odgovara je li to lanac koji ova aplikacija očekuje. Implementacija koja preskoči prvi korak nije dobila sigurnost, samo novinu.

Objekt koji se prikvačuje razlikuje se među platformama, pa sama riječ malo govori. Kopirati heš iz skladišta povjerenja jednog proizvoda i tretirati ga kao istu stvar u mobilnoj aplikaciji česta je i tiha greška.

Prikvačivanje na platformi je konfiguracija, ne politika

Android izlaže prikvačivanje kroz svoju konfiguraciju mrežne sigurnosti, gdje skup prikvačivanja drži sažetke javnog ključa i lanac mora sadržavati barem jedan od njih. Ta datoteka je po aplikaciji i traži namjernu promjenu builda. iOS nema ekvivalentan mehanizam manifesta, pa prikvačivanje tamo živi u vlastitom kodu za procjenu povjerenja aplikacije.

Budući da se mehanizam razlikuje, zahtjev se mora pisati po platformi. Politika koja kaže prikvači certifikat bez imenovanja platforme nije provediva.

Rotacija odlučuje hoće li prikvačivanje preživjeti

Teški dio nije prvo izdanje, nego obnova certifikata nakon njega. Restriktivna politika povjerenja odbija legitiman novi ključ jednako čvrsto kao i napadačev.

Dva mehanizma čine rotaciju preživljivom: rezervno prikvačivanje kojem se vjeruje prije nego što zatreba, i datum isteka na skupu prikvačivanja da provedba prestane umjesto da blokira aplikaciju. Oboje su političke odluke, a istek je posebno namjerno smanjenje sigurnosti, a ne bezopasan tajmer. Imenujte ko kontrolira build aplikacije, TLS krajnju točku i obnovu certifikata, i stavite ih u jedan proces promjene. Ako su to tri različita tima, prikvačivanje će na kraju izazvati ispad koji nitko nije planirao.

Izgubljeni uređaj je treći problem

Opoziv VPN akreditiva ne završava nužno sesiju aplikacije, a prikvačivanje servera ne čini baš ništa za telefon u tuđoj ruci. Zaključavanje uređaja, pohrana akreditiva, trajanje sesije i daljinski opoziv odvojene su odluke s odvojenim vlasnicima. Ako ih presavijete u raspravu o prikvačivanju, garantirano se nijedna od njih neće projektirati.

Testirajte četiri odnosa umjesto onog jednog koji vidite: namjeravani server i operaciju, račun koji treba biti odbijen, identitet servera koji treba biti odbačen i planiranu rotaciju. Ispravan VPN vježba samo prvi. Zapišite šta je svaki test dokazao, jer će sljedeća osoba pretpostaviti da zeleni tunel znači da su sva četiri prošla.