Profile ng VPN sa iOS: passwordReference, hindi ang password

Nag-i-install ka ng profile, bumabangon ang tunnel, at mukhang tapos na ang lahat. Pagkatapos, nag-reboot ang telepono, ginigising ng on-demand ang koneksyon na walang app sa harapan, at tumatanggi ang tunnel na magsimula. Nandiyan pa rin ang profile at tama pa rin ang password, kaya nga ipinapadala ng pagpalya na ito ang mga tao sa maling lugar. Hindi mabasa ng Network Extension ang sikreto mo mula sa profile: kailangan nito ng reference sa keychain na kaya nitong lutasin mismo.

Sinusundan ng gabay sa ibaba ang isang pagtatangkang kumonekta sa pagpasa na iyon, mula sa query na bumubuo ng reference hanggang sa reboot na sumusubok dito.

Nag-iimbak ang profile ng hawakan, hindi ang sikreto

Inilalabas ng NEVPNProtocol ang passwordReference at sharedSecretReference para sa isang dahilan. Kapag nagsimula ang daemon ng tunnel, maaaring hindi ito tumatakbo sa loob ng proseso mo, kaya hindi nito matawagan ang code mo at makahingi ng password. Nagbabasa ito ng permanenteng reference sa keychain, nilulutas ito sa sarili nitong konteksto, at kinukuha mismo ang item.

Binubuo mo ang reference na iyon sa pamamagitan ng paghingi nito sa keychain, na ibang kahilingan kaysa sa kahilingan ng data:

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
]

Ibigay sa protocol ang ibinalik na object, hindi ang data ng item. Sa praktika, itinatala ng profile kung saan nakatira ang sikreto, kaya hindi rin kinokopya ng backup ng configuration ang password nang tahimik sa isang plist.

Bakit sumasagot ng -50 ang API

Ang errSecParam ay nangangahulugang ang kahilingan o halaga ay mali ang anyo para sa operasyon, at ito ang error na pinakamadalas makita kapag naghalo ang mga kahilingan sa reference at sa data. Humihingi ng data habang naghihintay ng reference ang tumatanggap na code, nagtatalaga ng hilaw na bytes sa passwordReference, o nagtatanong gamit ang access group na hindi magagamit ng app, lahat ito ay gumagawa nito.

Inaanyayahan ito ng mga wrapper library. Ang helper na nagbabalik ng bytes ay hindi mapapalitan ng isang nagbabalik ng reference, kaya ang pag-aayos ay karaniwang ibang query at hindi ibang password.

Ang parehong pagkakatugma ang nagpapaliwanag sa profile na nai-save nang walang reklamo at pagkatapos ay hindi makakonekta: ang nakatago ay isang blob, hindi hawakan, at walang malulutas ang daemon.

Nai-save nang maayos, pumapalya sa koneksyon

Sinasanay ng pag-save ang konteksto ng app mo. Sinasanay ng pagkonekta ang sa daemon, at hindi pareho ang access ng dalawa. Kaya ang isang profile ay maaaring makapasa sa lahat ng pagsubok sa simulator at pumalya sa unang pagsisimula ng on-demand.

Ganoon din ang hugis ng sintomas sa reboot: gumagana habang bukas ang app at namamatay kapag ang sistema mismo ang nagsimula ng tunnel.

Subukan nang sadya ang landas sa background bago i-release. Mag-trigger ng on-demand na koneksyon habang sarado ang app, pagkatapos ay basahin ang console ng device at hindi ang log ng app, dahil ang pagpalya ay itinatala ng prosesong nagtangkang lumutas ng reference. Kung ipinapakita ng console na tinatanggihan ng daemon ang item, maayos ang reference at ang problema ay ang accessibility ng item.

Ang accessibility ang nagtatakda kung gagana ang reboot

Dapat mabasa ang item ng kahit anong proseso ng sistema na naglulunsad ng tunnel, at iyon ay mas malawak na madla kaysa sa app mo habang nasa harapan. Pinipili ng paghihigpit na iyon ang attribute ng accessibility para sa iyo. Ang item na protektado hanggang sa unang pag-unlock ay magagamit para sa pagsisimula sa background pagkatapos ma-unlock ang device nang isang beses; ang item na nangangailangan na naka-unlock ang device ngayon ay hindi.

Nakakaakit ang pagpili ng mas mahigpit na klase, at iyon mismo ang sumisira sa on-demand na profile sa naka-lock na telepono.

Pagkatapos baguhin ang klase, muling likhain ang item sa halip na i-edit ang mga attribute ng umiiral, pagkatapos ay i-save muli ang protocol gamit ang bagong reference. Hindi laging nagbubunga ang mga pagbabago sa attribute ng umiiral na item ng pag-uugaling ipinahihiwatig ng dokumentasyon, at inaalis ng muling itinayong item ang pagdududa.

Ang rotation ang lugar kung saan nabubulok ang mga naka-save na profile

Ang pagpapalit ng password sa keychain ay hindi awtomatikong nagbabago ng tinutukoy ng naka-save na profile. Mas masahol ang pagbura ng item: nagtatago ang profile ng reference sa isang bagay na wala na, at ang pagpalya ay mukhang pagtanggi sa authentication.

I-rotate sa isang pagkakasunod-sunod. I-update ang item, mag-query ng bagong permanenteng reference, i-save muli ang protocol, pagkatapos ay kumonekta habang sarado ang app upang patunayang kayang lutasin pa rin ito ng daemon. Itago ang password ng user at ang shared secret sa magkahiwalay na item upang ang bawat isa ay umikot ayon sa sariling iskedyul, at huwag kailanman i-log ang diksyunaryo ng query o ang reference mismo. Ang hawakan ay hindi sikreto, ngunit mapa ito patungo sa isa.