Nag-i-install ng Signed na VPN Profile sa iPhone? Basahin ang mga Payload

Dumarating ang mga profile sa Settings na may pangalan, signer at Install button, at ang linya ng signer ang madalas basahin ng mga tao. Sinasagot ng linyang iyon ang isang tanong: sino ang nag-package ng mga setting na ito ayon sa mga patakaran ng pag-verify ng lagda. Hindi nito sinasabi na ang VPN payload ay tumuturo sa gateway ng iyong employer, o na ang naka-embed na root certificate ay kabilang sa iyong TLS trust store. Binubuksan ng walkthrough sa ibaba ang package sa pagkakasunod-sunod na gagamitin ng device.

Magsimula sa envelope: sino ang pumirma sa profile na ito

Sa iOS lumilitaw ang profile sa Settings, General, VPN at Device Management, at nakalagay ang signer sa itaas ng Install button. Basahin ang pangalang iyon bago ka mag-tap ng kahit ano, at itanong kung ito ang organisasyong inaasahan mong magpadala ng mga setting. Ang wastong lagda mula sa taong hindi mo kilala ay wasto pa ring lagda, at pinapahintulutan nito ang kanilang configuration, hindi ang sa iyo. Sinasabi rin ng parehong screen kung may lagda ang profile o wala.

Kung nasa Mac ang file, suriin ito bago pa ito makarating sa telepono. Binubuksan ng security tool ang CMS envelope at ipinapakita ang plist na babasahin ng device, na parehong nilalaman na walang Install button sa daan. Inilalarawan ng dokumentasyon ng Apple tungkol sa pagpapatupad ng configuration ang pagpirma bilang pagpapatunay ng pinagmulan, at iyon mismo ang saklaw na tinutukoy dito.

security cms -D -i corp-vpn.mobileconfig -o corp-vpn.plist
plutil -p corp-vpn.plist

Tumigil dito kung ang signer ay hindi ang inaasahan mo, o kung walang lagda ang file at dumating sa channel na hindi ito masisiguro. Wala sa mga susunod na hakbang ng walkthrough na ito ang gagawa ng mapagkakatiwalaang envelope mula sa hindi pinagkakatiwalaan.

Buksan ang bawat payload at pangalanan ang ini-install nito

Ang profile ay isang container, at ang kawili-wiling bahagi ay ang PayloadContent array sa loob nito. Bawat entry ay may PayloadType na nagsasabi kung ano ang i-install ng device: isang managed na VPN configuration, isang PKCS#12 identity, isang root certificate, o isang management enrollment. I-print ang mga uri bago mo basahin ang alinman sa mga setting.

plutil -extract PayloadContent xml1 -o - corp-vpn.plist |
  grep -E 'PayloadType|PayloadDisplayName'

Ang VPN payload ay nagpapangalan ng koneksyon: server address, paraan ng authentication, at maaaring isang per-app o on-demand na patakaran. Ang identity payload ay nagbibigay ng client credential na ipapakita ng koneksyong iyon. Ang root certificate payload ay nagdadagdag ng trust anchor, at ang management payload ay nagbibigay ng patuloy na kontrol sa isang server. Apat na magkaibang pangako iyon, at ang lagda ay sumasaklaw sa package sa halip na magpatunay sa bawat isa nang hiwalay. Basahin ang mga ito sa ganoong pagkakasunod-sunod, dahil walang silbi ang VPN kung walang identity at kakaunti ang kahulugan ng identity kung hindi mo alam kung sino ang nagbigay nito.

Ang proteksyon ng password sa file ay hiwalay na katangian. Itinatago ng naka-encrypt na package ang nilalaman sa taong walang password; hindi nito pinagpapasyahan kung dapat mong payagan ang nasa loob. Ituring ang password bilang paraan ng paghahatid, hindi bilang pagsusuri.

Sundan ang mga certificate hanggang sa koneksyong gumagamit sa kanila

Ilista ang mga certificate sa package at itugma ang bawat isa sa isang tungkulin. Kinikilala ng client certificate ang device na ito sa gateway, ang CA na nagbigay nito ay kabilang sa trust chain para sa koneksyong iyon, at ang root na ini-install para sa proxy o panloob na serbisyo ay hindi awtomatikong anchor para sa bawat HTTPS site. Sa iOS, ang root na ini-install nang manu-mano ay nananatiling hindi pinagkakatiwalaan para sa TLS hanggang i-enable mo ito sa Settings, About, Certificate Trust Settings, samantalang ang root na hatid ng management ay pinagkakatiwalaan nang wala ang hakbang na iyon. Ang pagkakaibang iyon ang dahilan kung bakit mahalaga ang layunin ng payload.

openssl pkcs7 -inform DER -in corp-vpn.mobileconfig -print_certs -noout
security find-certificate -a -c "Corp Root" -p | openssl x509 -noout -subject -dates

Ang provider na nagdadala ng iyong traffic ay hindi, dahil doon, ang TLS endpoint ng bawat website na binibisita mo. Ang interception ay nangangailangan ng daan ng traffic at trust anchor na tinatanggap ng application, at ang profile na may isang certificate ay hindi nagpapatunay ng alinman sa dalawa. Itanong kung aling koneksyon ang gumagamit ng certificate at aling mga application ang tatanggap nito, sa halip na ipagpalagay na ang pag-install ng profile ay nagde-decrypt ng lahat.

Pagkatapos ng install: i-verify, at alamin ang ginagawa ng pag-alis

Kapag naka-install na ang profile, kumpirmahin ito mula sa device sa halip na mula sa na-download na file. Ilista ng settings screen ang naka-install na profile, signer at mga payload nito, at ipinapakita ng VPN screen kung ang koneksyon ay naka-configure ayon sa intensyon. Walang inaalis ang pag-delete ng na-download na file; ang naka-install na configuration ay hiwalay na bagay.

profiles show -type configuration
scutil --nc list

Kung may kasamang management enrollment ang profile, basahin ang mga kahihinatnan ng pag-alis bago mo ito i-install, hindi pagkatapos. Kapag inalis ang enrollment na iyon, kasama nitong aalis ang mga kaugnay na configuration at maaaring alisin ang mga managed app, depende sa kung paano na-enroll ang device. Hindi ito hakbang sa pag-aayos na susubukan kapag mukhang mali ang isang certificate. Itanong sa administrator kung aling payload ang may problema bago mag-alis ng kahit ano.

Nagtatapos ang walkthrough sa apat na magkaibang sagot: sino ang pumirma sa package, aling mga payload ang ini-install nito, aling identity at trust ang ginagamit ng bawat koneksyon, at ano ang aalisin ng pag-alis. Panatilihing hiwalay ang mga ito at ang signed na profile ay magiging sinuring desisyon sa halip na berdeng tsek.