TLS-fiksado kaj VPN-aliro respondas malsamajn demandojn

Metu privatan poŝtelefonan apon malantaŭ VPN, kaj racia homo demandos, ĉu ĝi ankoraŭ bezonas atestilan fiksadon. La demando sonas kvazaŭ elekto inter du egalaj regiloj, kaj ĝi vere estas demando pri du malsamaj pordegoj. La VPN decidas, ĉu ĉi tiu aparato rajtas uzi la vojon entute; la apo decidas, ĉu la servilo, kiun ĝi atingis, estas la atendita. Respondu ambaŭ aparte kaj la dezajno fariĝas pli simpla.

Du pordegoj, du demandoj

Retaliro temas pri la kliento: ĉu ĉi tiu aparato estas registrita, ĉu ĝia akreditaĵo validas, kaj ĉu la politiko permesas ĝin en ĉi tiu vojo? Apa fido temas pri la servilo: ĉu la konekto atingis servon kun identeco, kiun la apo akceptas? Tiuj respondoj venas el malsamaj sistemoj, malsukcesas pro malsamaj kaŭzoj, kaj estas riparataj de malsamaj teamoj. VPN-manpremo povas sukcesi dum la apo parolas kun eksvalidiĝinta atestilo malantaŭ la kunulo. Perfekte fiksita apo tamen povas resti neatingebla por ĉiuj, ĉar la aparato neniam venis en la reton.

La du sin sumas. Forigi unu forprenas regilon; aldoni la alian ne anstataŭas ĝin.

Kion fiksado efektive limigas

Fiksado mallarĝigas la aron da servilaj identecoj, kiujn la apo akceptos, kutime nomante publikan ŝlosilon aŭ atestilan haketon anstataŭ fidi ĉiun ĉenon, kiun iu konservejo garantius. Ĝi estas limigo metita sur ordinaran validigon, ne anstataŭo por ĝi. Ordinara validigo respondas, ĉu ĉeno entute fidindas; la fiksado respondas, ĉu ĝi estas la ĉeno, kiun ĉi tiu apo atendas. Efektivigo, kiu preterlasas la unuan paŝon, ne gajnis sekurecon, nur novecon.

La fiksata objekto varias inter platformoj, do la vorto sola diras al vi tre malmulte. Kopii haketon el la fida konservejo de unu produkto kaj trakti ĝin kiel la saman aferon en poŝtelefona apo estas ordinara kaj silenta eraro.

Fiksado sur la platformo estas agordo, ne politiko

Android montras fiksadon per sia retsekureca agordo, kie fiksa aro enhavas resumojn de publika ŝlosilo kaj la ĉeno devas enhavi almenaŭ unu el ili. Tiu dosiero estas por ĉiu apo kaj bezonas intencan konstruŝanĝon. iOS ne havas ekvivalentan manifestmekanismon, do fiksado tie loĝas en la propra fida taksokodo de la apo.

Ĉar la mekanismo malsamas, la postulo devas esti skribita por ĉiu platformo. Politiko, kiu diras fiksu la atestilon sen nomi la platformon, ne estas realigebla.

Rotacio decidas, ĉu la fiksado pluvivos

La malfacila parto ne estas la unua eldono, ĝi estas la atestila renovigo post ĝi. Restrikta fida politiko malakceptas laŭleĝan novan ŝlosilon same firme kiel tiun de atakanto.

Du mekanismoj igas rotacion supervivebla: rezerva fiksado, kiu jam estas fidata antaŭ ol ĝi necesas, kaj findato sur la fiksa aro, por ke devigo ĉesu anstataŭ igi la apon neuzebla. Ambaŭ estas politikaj decidoj, kaj la findato aparte estas intenca malpliigo de sekureco, ne senkulpa tempomezurilo. Nomu, kiu kontrolas la konstruon de la apo, la TLS-finpunkton kaj la atestilan renovigon, kaj metu ilin en unu ŝanĝprocezon. Se tiuj estas tri malsamaj teamoj, la fiksado fine kaŭzos paneon, kiun neniu planis.

Perdita aparato estas tria problemo

Malvalidigo de VPN-akreditaĵo ne nepre finas apan sesion, kaj servila fiksado tute nenion faras pri telefono en la mano de iu alia. Aparata ŝloso, akreditaĵa konservado, sesia vivodaŭro kaj fora malvalidigo estas apartaj decidoj kun apartaj posedantoj. Faldi ilin en la fiksadan diskuton garantias, ke neniu el ili estos dezajnita.

Testu kvar rilatojn anstataŭ la unu, kiun vi vidas: la celatan servilon kaj operacion, konton, kiu devus esti rifuzita, servilan identecon, kiu devus esti forĵetita, kaj la planitan rotacion. Funkcianta VPN ekzercas nur la unuan. Skribu, kion pruvis ĉiu testo, ĉar la sekva persono supozos, ke verda tunelo signifas, ke ĉiuj kvar pasis.