Perfil de VPN a l’iOS: passwordReference, no la contrasenya

Instal·leu un perfil, el túnel s’aixeca i tot sembla enllestit. Llavors el telèfon es reinicia, la connexió on-demand es desperta sense cap app en primer pla i el túnel es nega a arrencar. El perfil continua allà i la contrasenya continua sent correcta, i per això aquesta fallada envia la gent a buscar al lloc equivocat. Una Network Extension no pot llegir el vostre secret del perfil: necessita una referència del clauer que pugui resoldre pel seu compte.

El recorregut següent segueix un sol intent de connexió per aquest lliurament, des de la consulta que construeix la referència fins al reinici que la prova.

El perfil desa un mànec, no el secret

NEVPNProtocol exposa passwordReference i sharedSecretReference per un motiu. Quan el dimoni arrenca un túnel potser no s’executa dins del vostre procés, així que no pot cridar el vostre codi i demanar una contrasenya. Llegeix una referència persistent del clauer, la resol en el seu propi context i obté l’element ell mateix.

Construeu aquesta referència demanant-la al clauer, que és una petició diferent de demanar les dades:

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
]

Lliureu l’objecte retornat al protocol, no les dades de l’element. A la pràctica el perfil enregistra on viu el secret, i per això una còpia de seguretat de la configuració no duplica la contrasenya silenciosament en un plist.

Per què l’API respon -50

errSecParam significa que la petició o el valor eren malformats per a l’operació, i és l’error que es veu més sovint quan es barregen les peticions de referència i de dades. Demanar dades mentre el codi receptor espera una referència, assignar bytes en brut a passwordReference o consultar amb un grup d’accés que l’app no pot fer servir, totes el produeixen.

Les biblioteques embolcall conviden a això. Un auxiliar que retorna bytes no és intercanviable amb un que retorna una referència, així que la reparació sol ser una consulta diferent i no una contrasenya diferent.

La mateixa desavinença explica un perfil que es desa sense queixa i després no pot connectar: el que s’ha desat és un blob, no un mànec, i el dimoni no té res a resoldre.

Es desa bé, falla en connectar

Desar exercita el context de la vostra app. Connectar exercita el del dimoni, i els dos no tenen el mateix accés. Per tant, un perfil pot passar tots els tests que feu al simulador i fallar al primer arrencament on-demand.

Aquesta és també la forma del símptoma del reinici: funciona mentre l’app és oberta i mor quan el sistema arrenca el túnel tot sol.

Proveu el camí de fons deliberadament abans de publicar. Desencadeneu una connexió on-demand amb l’app tancada i llegiu la consola del dispositiu, no el registre de l’app, perquè la fallada la registra el procés que va intentar resoldre la referència. Si la consola mostra que el dimoni rebutja l’element, la referència és bona i el problema és l’accessibilitat de l’element.

L’accessibilitat decideix si un reinici funciona

L’element ha de ser llegible pel procés del sistema que arrenqui el túnel, i això és un públic més ampli que la vostra app mentre és en primer pla. Aquesta restricció tria l’atribut d’accessibilitat per vosaltres. Un element protegit fins al primer desbloqueig està disponible per a un arrencament en segon pla després que el dispositiu s’hagi desbloquejat un cop; un element que exigeix que el dispositiu estigui desbloquejat ara mateix no ho està.

Triar la classe més estricta és temptador i és exactament el que trenca un perfil on-demand en un telèfon bloquejat.

Després de canviar la classe, recreu l’element en lloc d’editar atributs al que ja existeix, i torna a desar el protocol amb una referència nova. Els canvis d’atributs en un element existent no sempre produeixen el comportament que implica la documentació, i un element reconstruït elimina el dubte.

La rotació és on es podreixen els perfils desats

Canviar la contrasenya al clauer no canvia automàticament allò a què apunta el perfil desat. Esborrar l’element és pitjor: el perfil guarda una referència a una cosa que ja no existeix, i la fallada sembla un rebuig d’autenticació.

Roteu en un sol ordre. Actualitzeu l’element, consulteu una referència persistent nova, torneu a desar el protocol i connecteu amb l’app tancada per demostrar que el dimoni encara la pot resoldre. Mantingueu la contrasenya de l’usuari i el secret compartit en elements separats perquè cadascun roti segons el seu calendari, i no registreu mai el diccionari de la consulta ni la referència mateixa. El mànec no és un secret, però és un mapa cap a un.