iOS VPN-profil: passwordReference, nem a jelszó

Telepítesz egy profilt, az alagút feljön, és minden késznek látszik. Aztán a telefon újraindul, az on-demand előtérben lévő alkalmazás nélkül felébreszti a kapcsolatot, és az alagút nem indul el. A profil még ott van, és a jelszó még helyes, ezért küldi ez a hiba az embereket rossz helyre keresni. A Network Extension nem tudja kiolvasni a titkodat a profilból: olyan kulcskarikahivatkozás kell neki, amelyet maga is fel tud oldani.

Az alábbi végigvezetés egyetlen kapcsolódási kísérletet követ végig ezen az átadáson, a hivatkozást fölépítő lekérdezéstől az azt próbára tevő újraindításig.

A profil fogantyút tárol, nem a titkot

A NEVPNProtocol okkal teszi elérhetővé a passwordReference és a sharedSecretReference mezőt. Amikor a démon elindít egy alagutat, lehet, hogy nem a te folyamatodon belül fut, így nem tudja meghívni a kódodat és jelszót kérni. Beolvas egy tartós kulcskarikahivatkozást, feloldja a saját környezetében, és maga hozza el az elemet.

Ezt a hivatkozást úgy építed föl, hogy elkérded a kulcskarikától, ami más kérés, mint az adatok elkérése:

let query: [String: Any] = [
  kSecClass as String: kSecClassGenericPassword,
  kSecAttrService as String: "vpn-credentials",
  kSecAttrAccount as String: "user",
  kSecReturnPersistentRef as String: true,
  kSecMatchLimit as String: kSecMatchLimitOne
]

A visszakapott objektumot add át a protokollnak, nem az elem adatait. A gyakorlatban a profil rögzíti, hol lakik a titok, ezért a konfiguráció biztonsági mentése sem másolja csendben a jelszót egy plistbe.

Miért válaszol az API -50-nel

Az errSecParam azt jelenti, hogy a kérés vagy az érték hibás formájú volt a művelethez, és ez a hiba látszik leggyakrabban, amikor a hivatkozás- és adatkérések összekeverednek. Adatot kérni, miközben a fogadó kód hivatkozást vár, nyers bájtokat rendelni a passwordReference mezőhöz, vagy olyan hozzáférési csoporttal lekérdezni, amelyet az alkalmazás nem tud használni, mind előidézi.

A burkoló kódtárak hívják ezt elő. A bájtokat visszaadó segédfüggvény nem cserélhető fel a hivatkozást visszaadóval, ezért a javítás általában másik lekérdezés, nem másik jelszó.

Ugyanez az eltérés magyarázza azt a profilt, amely panaszkodás nélkül mentődik, majd nem csatlakozik: ami eltárolódott, az blob, nem fogantyú, és a démonnak nincs mit feloldania.

Szépen mentődik, kapcsolódáskor elbukik

A mentés az alkalmazásod környezetét gyakorolja. A kapcsolódás a démonét, és a kettőnek nincs ugyanaz a hozzáférése. Ezért egy profil átmehet a szimulátorban futtatott összes teszten, és elbukhat az első on-demand indításnál.

Ez az újraindítási tünet formája is: működik, amíg az alkalmazás nyitva van, és meghal, amikor a rendszer maga indítja el az alagutat.

Teszteld szándékosan a háttérútvonalat szállítás előtt. Válts ki on-demand kapcsolatot zárt alkalmazással, majd az eszköz konzolját olvasd, ne az alkalmazás naplóját, mert a hibát az a folyamat rögzíti, amely megpróbálta feloldani a hivatkozást. Ha a konzol azt mutatja, hogy a démon elutasítja az elemet, a hivatkozás rendben van, és a probléma az elem elérhetősége.

Az elérhetőség dönti el, működik-e az újraindítás

Az elemnek olvashatónak kell lennie bármely rendszerfolyamat számára, amely elindítja az alagutat, és ez szélesebb közönség, mint az alkalmazásod előtérben. Ez a korlát választja ki neked az elérhetőségi attribútumot. Az első feloldásig védett elem elérhető háttérindításhoz, miután az eszközt egyszer feloldották; az olyan elem, amely azt kívánja, hogy az eszköz most legyen feloldva, nem az.

A szigorúbb osztály választása csábító, és pontosan ez töri el az on-demand profilt egy zárolt telefonon.

Az osztály megváltoztatása után hozd létre újra az elemet, ahelyett hogy a meglévő attribútumait szerkesztenéd, majd mentsd újra a protokollt friss hivatkozással. A meglévő elemen végzett attribútumváltozások nem mindig adják azt a viselkedést, amelyet a dokumentáció sugall, és az újraépített elem eloszlatja a kételyt.

A rotáció az, ahol a mentett profilok megrothadnak

A jelszó megváltoztatása a kulcskarikan nem változtatja meg automatikusan azt, amire a mentett profil mutat. Az elem törlése rosszabb: a profil hivatkozást tart valamire, ami már nem létezik, és a hiba hitelesítési elutasításnak látszik.

Egyetlen sorrendben rotálj. Frissítsd az elemet, kérdezz le új tartós hivatkozást, mentsd újra a protokollt, majd kapcsolódj zárt alkalmazással, hogy bizonyítsd, a démon még fel tudja oldani. Tartsd a felhasználói jelszót és a megosztott titkot külön elemekben, hogy mindegyik a saját ütemezése szerint rotálódjon, és soha ne naplózd a lekérdezés szótárát vagy magát a hivatkozást. A fogantyú nem titok, de térkép hozzá.