iOS VPN-profil: passwordReference, ikke passordet

Du installerer en profil, tunnelen kommer opp, og alt ser ferdig ut. Så starter telefonen på nytt, on-demand vekker forbindelsen uten noen app i forgrunnen, og tunnelen nekter å starte. Profilen er der fortsatt og passordet er fortsatt riktig, og derfor sender denne feilen folk til å lete på feil sted. En Network Extension kan ikke lese hemmeligheten din fra profilen: den trenger en nøkkelringreferanse den selv kan løse opp.

Gjennomgangen nedenfor følger ett tilkoblingsforsøk gjennom den overleveringen, fra spørringen som bygger referansen, til omstarten som tester den.

Profilen lagrer et håndtak, ikke hemmeligheten

NEVPNProtocol eksponerer passwordReference og sharedSecretReference av en grunn. Når daemonen starter en tunnel, kjører den kanskje ikke inne i prosessen din, så den kan ikke kalle koden din og be om et passord. Den leser en varig nøkkelringreferanse, løser den opp i sin egen kontekst og henter elementet selv.

Du bygger den referansen ved å spørre nøkkelringen om den, noe som er en annen forespørsel enn å spørre om dataene:

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
]

Gi det returnerte objektet til protokollen, ikke dataene til elementet. I praksis registrerer profilen hvor hemmeligheten bor, og derfor dupliserer ikke en sikkerhetskopi av konfigurasjonen passordet lydløst inn i en plist.

Hvorfor API-et svarer -50

errSecParam betyr at forespørselen eller verdien var feilformet for operasjonen, og det er feilen man oftest ser når forespørslene om referanse og data blandes sammen. Å be om data mens koden som mottar forventer en referanse, å tildele rå byte til passwordReference eller å spørre med en tilgangsgruppe appen ikke kan bruke, frembringer den alle.

Innpakningsbiblioteker inviterer til dette. En hjelper som returnerer byte, kan ikke byttes ut med en som returnerer en referanse, så reparasjonen er vanligvis en annen spørring og ikke et annet passord.

Den samme uoverensstemmelsen forklarer en profil som lagres uten klage og deretter ikke kobler til: det som ble lagret, er en blob, ikke et håndtak, og daemonen har ingenting å løse opp.

Lagres fint, feiler ved tilkobling

Lagring utøver konteksten til appen din. Tilkobling utøver daemonens, og de to har ikke samme tilgang. En profil kan derfor bestå alle testene i simulatoren og feile ved den første on-demand-starten.

Det er også formen på omstartssymptomet: det virker mens appen er åpen, og dør når systemet starter tunnelen selv.

Test bakgrunnsveien med vilje før utgivelse. Utløs en on-demand-tilkobling med appen lukket, og les deretter enhetskonsollen i stedet for apploggen, fordi feilen registreres av prosessen som forsøkte å løse opp referansen. Hvis konsollen viser at daemonen avviser elementet, er referansen i orden og problemet er elementets tilgjengelighet.

Tilgjengelighet avgjør om en omstart virker

Elementet må kunne leses av hvilken som helst systemprosess som starter tunnelen, og det er et bredere publikum enn appen din mens den er i forgrunnen. Den begrensningen velger tilgjengelighetsattributtet for deg. Et element beskyttet til første opplåsing er tilgjengelig for en bakgrunnsstart etter at enheten er låst opp én gang; et element som krever at enheten er låst opp akkurat nå, er det ikke.

Å velge den strengeste klassen er fristende, og det er nettopp det som ødelegger en on-demand-profil på en låst telefon.

Etter å ha endret klassen, gjenopprett elementet i stedet for å redigere attributter på det eksisterende, og lagre deretter protokollen på nytt med en fersk referanse. Attributtendringer på et eksisterende element gir ikke alltid atferden dokumentasjonen antyder, og et gjenoppbygd element fjerner tvilen.

Rotasjon er der lagrede profiler råtner

Å endre passordet i nøkkelringen endrer ikke automatisk hva den lagrede profilen peker på. Å slette elementet er verre: profilen beholder en referanse til noe som ikke lenger finnes, og feilen ser ut som en avvist autentisering.

Roter i én rekkefølge. Oppdater elementet, spør om en ny varig referanse, lagre protokollen på nytt, og koble deretter til med appen lukket for å bevise at daemonen fortsatt kan løse den opp. Hold brukerpassordet og den delte hemmeligheten i separate elementer slik at hver roterer etter sin egen plan, og logg aldri spørringsordboken eller referansen selv. Håndtaket er ikke en hemmelighet, men det er et kart til en.