iOS VPN-profil: passwordReference, ikkje passordet

Du installerer ein profil, tunnelen kjem opp, og alt ser ferdig ut. Så startar telefonen på nytt, on-demand vekkjer sambandet utan noka app i framgrunnen, og tunnelen nektar å starta. Profilen er der framleis og passordet er framleis rett, og difor sender denne feilen folk til å leita på feil stad. Ein Network Extension kan ikkje lesa hemmelegheita di frå profilen: han treng ei nøkkelringreferanse som han sjølv kan løysa opp.

Gjennomgangen nedanfor følgjer eitt tilkoplingsforsøk gjennom den overleveringa, frå spørjinga som byggjer referansen, til omstarten som prøver han.

Profilen lagrar eit handtak, ikkje hemmelegheita

NEVPNProtocol eksponerer passwordReference og sharedSecretReference av ein grunn. Når daemonen startar ein tunnel, køyrer han kanskje ikkje inne i prosessen din, så han kan ikkje kalla koden din og be om eit passord. Han les ei varig nøkkelringreferanse, løyser henne opp i sin eigen kontekst og hentar elementet sjølv.

Du byggjer den referansen ved å spørja nøkkelringen om han, noko som er ei anna førespurnad enn å spørja om dataa:

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
]

Gje det returnerte objektet til protokollen, ikkje dataa til elementet. I praksis registrerer profilen kvar hemmelegheita bur, og difor dupliserer ikkje ein sikkerheitskopi av konfigurasjonen passordet lydlaust inn i ein plist.

Kvifor API-et svarar -50

errSecParam tyder at førespurnaden eller verdien var feilforma for operasjonen, og det er feilen ein oftast ser når førespurnadene om referanse og data blir blanda saman. Å be om data medan koden som tek imot ventar ein referanse, å tildele rå byte til passwordReference eller å spørja med ei tilgangsgruppe appen ikkje kan bruka, framkallar han alle.

Innpakningsbibliotek inviterer til dette. Ein hjelpar som returnerer byte, kan ikkje bytast ut med ein som returnerer ein referanse, så reparasjonen er vanlegvis ei anna spørjing og ikkje eit anna passord.

Den same uoverensstemminga forklarar ein profil som blir lagra utan klage og deretter ikkje koplar til: det som vart lagra, er ein blob, ikkje eit handtak, og daemonen har ingenting å løysa opp.

Lagrast fint, feilar ved tilkopling

Lagring utøver konteksten til appen din. Tilkopling utøver daemonen sin, og dei to har ikkje same tilgang. Ein profil kan difor klara alle testane i simulatoren og feila ved den første on-demand-starten.

Det er også forma på omstartssymptomet: det verkar medan appen er open, og døyr når systemet startar tunnelen sjølv.

Test bakgrunnsvegen med vilje før utgiving. Utløys ein on-demand-tilkopling med appen lukka, og les deretter einingskonsollen i staden for apploggen, fordi feilen blir registrert av prosessen som freista å løysa opp referansen. Viss konsollen viser at daemonen avviser elementet, er referansen i orden og problemet er tilgjengelegheita til elementet.

Tilgjengelegheit avgjer om ein omstart verkar

Elementet må kunna lesast av kva som helst systemprosess som startar tunnelen, og det er eit breiare publikum enn appen din medan han er i framgrunnen. Den avgrensinga vel tilgjengelegheitsattributtet for deg. Eit element som er verna til første opplåsing, er tilgjengeleg for ein bakgrunnsstart etter at eininga er låst opp éin gong; eit element som krev at eininga er låst opp akkurat no, er det ikkje.

Å velja den strengaste klassen er freistande, og det er nettopp det som øydelegg ein on-demand-profil på ein låst telefon.

Etter å ha endra klassen, gjenopprett elementet i staden for å redigera attributtar på det eksisterande, og lagra deretter protokollen på nytt med ein fersk referanse. Attributtendringar på eit eksisterande element gjev ikkje alltid åtferda dokumentasjonen antydar, og eit gjenoppbygd element fjernar tvilen.

Rotasjon er der lagra profilar råtna

Å endra passordet i nøkkelringen endrar ikkje automatisk kva den lagra profilen peikar på. Å sletta elementet er verre: profilen held på ein referanse til noko som ikkje finst lenger, og feilen ser ut som ei avvist autentisering.

Roter i éin rekkjefølgje. Oppdater elementet, spør om ein ny varig referanse, lagra protokollen på nytt, og kople deretter til med appen lukka for å prova at daemonen framleis kan løysa han opp. Hald brukarpassordet og den delte hemmelegheita i separate element slik at kvar roterer etter sin eigen plan, og logg aldri spørjingsordboka eller referansen sjølv. Handtaket er ikkje ei hemmelegheit, men det er eit kart til ei.