Pripajanje TLS in dostop prek VPN odgovarjata na različna vprašanja

Postavite zasebno mobilno aplikacijo za VPN in razumen človek bo vprašal, ali še vedno potrebuje pripenjanje potrdil. Vprašanje zveni kot izbira med dvema enakovrednima kontrolama, v resnici pa je vprašanje o dveh različnih vratih. VPN odloča, ali sme ta naprava pot sploh uporabljati; aplikacija odloča, ali je doseženi strežnik tisti, ki ga je pričakovala. Odgovorite na obe ločeno in zasnova postane preprostejša.

Dve vrati, dve vprašanji

Dostop v omrežje zadeva odjemalca: je ta naprava vpisana, je njeno pooblastilo veljavno in ali ji politika dovoljuje to pot? Zaupanje aplikacije zadeva strežnik: je povezava dosegla storitev z identiteto, ki jo aplikacija sprejema? Ti odgovori prihajajo iz različnih sistemov, spodletijo iz različnih razlogov in jih popravljajo različne ekipe. VPN rokovanje lahko uspe, medtem ko se aplikacija pogovarja s poteklim potrdilom za partnerjem. Popolnoma pripeta aplikacija je lahko še vedno nedosegljiva za vse, ker naprava nikoli ni prišla v omrežje.

Oba se seštevata. Če eno izpustite, odstranite kontrolo; če dodate drugo, ga ne nadomestite.

Kaj pripenjanje v resnici omejuje

Pripetje zoži množico identitet strežnika, ki jih bo aplikacija sprejela, običajno tako, da navede javni ključ ali zgoščeno vrednost potrdila, namesto da bi zaupala vsaki verigi, za katero bi jamčila kakšna shramba. To je omejitev, položena na običajno preverjanje, ne njegova zamenjava. Običajno preverjanje odgovori, ali je veriga sploh vredna zaupanja; pripetje odgovori, ali je to veriga, ki jo ta aplikacija pričakuje. Izvedba, ki prvi korak preskoči, ni pridobila varnosti, le novost.

Pripeti objekt se med platformami razlikuje, zato sama beseda pove zelo malo. Kopiranje zgoščene vrednosti iz shrambe zaupanja enega izdelka in obravnavanje le-te kot iste stvari v mobilni aplikaciji je pogosta in tiha napaka.

Pripenjanje na platformi je konfiguracija, ne politika

Android izpostavi pripenjanje prek svoje konfiguracije omrežne varnosti, kjer nabor pripetij hrani povzetke javnega ključa in veriga mora vsebovati vsaj enega od njih. Ta datoteka je za vsako aplikacijo in zahteva namerno spremembo gradnje. iOS nima enakovrednega mehanizma manifesta, zato pripenjanje tam živi v lastni kodi aplikacije za ocenjevanje zaupanja.

Ker se mehanizem razlikuje, je treba zahtevo napisati za vsako platformo. Politika, ki pravi pripnite potrdilo, ne da bi navedla platformo, ni izvedljiva.

Rotacija odloča, ali pripetje preživi

Težji del ni prva izdaja, ampak obnova potrdila po njej. Restriktivna politika zaupanja zavrne zakonit nov ključ prav tako trdno kot napadalčev.

Dva mehanizma naredita rotacijo preživljivo: rezervno pripetje, ki mu zaupajo že preden je potrebno, in datum poteka na naboru pripetij, da se izvajanje konča, namesto da bi blokiralo aplikacijo. Oba sta politični odločitvi, potek pa je zlasti namerno zmanjšanje varnosti, ne neškodljiv časovnik. Poimenujte, kdo upravlja gradnjo aplikacije, končno točko TLS in obnovo potrdila, ter jih povežite v en sam proces sprememb. Če so to tri različne ekipe, bo pripetje sčasoma povzročilo izpad, ki ga nihče ni načrtoval.

Izgubljena naprava je tretji problem

Preklic pooblastila VPN ne konča nujno seje aplikacije, pripetje strežnika pa ne naredi prav ničesar s telefonom v tuji roki. Zaklep naprave, shranjevanje pooblastil, življenjska doba seje in oddaljeni preklic so ločene odločitve z ločenimi lastniki. Če jih zložite v razpravo o pripenjanju, zagotovite, da nobena od njih ne bo zasnovana.

Preizkusite štiri razmerja namesto tistega enega, ki ga vidite: predvideni strežnik in operacijo, račun, ki bi moral biti zavrnjen, identiteto strežnika, ki bi morala biti zavrnjena, in načrtovano rotacijo. Delujoč VPN vadi le prvo. Zapišite, kaj je dokazal vsak test, ker bo naslednja oseba domnevala, da zelen tunel pomeni, da so vsi štirje uspeli.