Tiu Wi-Fi-atestila invito ne estas nova radika atestinstanco

La dialogo aperas dum vi aliĝas al kampusa aŭ ofica reto, ĝi mencias atestilon kaj proponas butonon kun la teksto fidi aŭ daŭrigi. Malantaŭ tiu butono kaŝiĝas du tre malsamaj ŝanĝoj. Unu instruas al la Wi-Fi-kliento, kiun aŭtentiga servilo akcepti por ĉi tiu unu reto. La alia instalas atestinstancon, kiun aliaj aplikoj poste povos uzi. La vortumo sur la ekrano estas la sola postsigno, kiun vi havas, do legu ĝin antaŭ ol tuŝi.

Paŝo 1: legu, kion la dialogo efektive petas

Serĉu tri aferojn: la montritan servilnomon, la indikitan eldonanton kaj ĉu la ago estas priskribita kiel fidi servilon por ĉi tiu konekto aŭ kiel instali atestilon sur la aparaton. Tiuj estas malsamaj objektoj, kaj invito, kiu ne diras, kiun vi aprobas, meritas paŭzon.

Ne aprobu unu el la du versioj nur ĉar la retnomo aspektas konata. La SSID-ojn elektas tiu, kiu funkciigas la alirpunkton, kaj la nomo en la kaptita portalo ne pruvas ion pri la aŭtentiga servilo malantaŭ ĝi. Ĉiu kun alirpunkto povas elsendi konvinkan SSID-on. Ĝuste tial ekzistas la atestila kontrolo.

Kion pruvas 802.1X-servila atestilo

En 802.1X-enkonduko uzanta atestilojn, la suplikanto de la aparato validigas la aŭtentigan servilon dum la intertraktado. La gvidilo de Apple pri 802.1X-enkonduko priskribas la RADIUS-servilon prezentanta sian atestilon kaj la fiddecidon taŭgan por tiu servo.

Tiu lasta parto estas la tuta punkto. Atestilo eldonita de konata atestinstanco pruvas, ke la eldonanto subskribis ĝin, ne ke ĉi tiu konkreta servilo apartenas al la institucio, al kiu vi kredas, ke vi aliĝis. Celo-limigita fido ekzistas ĝuste tial, ĉar la dua demando estas la grava.

Subtenataj agordoj povas limigi fidon al elektitaj servilatestiloj aŭ al atendataj servilnomoj. Tial institucioj disdonas kontrolitan Wi-Fi-profilo anstataŭ diri al uzantoj akcepti la unuan atestilon, kiu aperas, kaj tial invito sen atendata nomo estas malbona loko por fari la decidon.

Paŝo 2: kontrolu, ĉu pli larĝa aŭtoritato eniris

Atestinstanco, kiun fidas retumilo aŭ la operaciumo, atingas multe pli longe ol Wi-Fi-servila atestilo akceptita por unu reto. Identigu la objekton, la konservejon, en kiun ĝi eniris, la celon, por kiu ĝi estas permesita, kaj kiuj aplikoj konsultas tiun konservejon.

Agorda pakaĵo povas enhavi plurajn agordojn samtempe, do inspektu la enhavon anstataŭ fidi la Wi-Fi-etikedon de la instalilo. La etikedo priskribas la taskon, ne nepre ĉion, kion faras la ŝarĝo.

Eĉ larĝa radiko ne pruvas, ke ĉiu HTTPS-sesio estas inspektata. Inspektado bezonas taŭgan trafikan vojon kaj servilatestilon, kiun la apliko akceptas laŭ sia reala validiga politiko, kaj aplikoj povas uzi malsamajn fido-konservejojn kun pliaj kontroloj.

Paŝo 3: tenu la VPN ekster la fiddecido

VPN protektas sian kovritan vojon post kiam la aparato atingas la VPN-peeron. Ĝi ne forigas instalitan radikon, ne ŝanĝas la fiddecidojn de apliko kaj ne kontrolas anstataŭ vi neatenditan Wi-Fi-aŭtentigan servilon.

Demandu la administranton pri reta aŭtentigo, aparata administrado kaj rajtigita TLS-inspektado kiel tri apartajn demandojn. Ili ne estas tri nomoj por la sama atestila funkcio, kaj subtena respondo, kiu kunfandas ilin, ne diros al vi, kiun ŝanĝon vi aprobis.

Paŝo 4: solvu la malkongruon sen rompi ĉion

Notu la ne-sekretajn detalojn el la invito: la servilnomon, la eldonanton kaj la fingrospuron, se ĝi estas montrata. Komparu ilin kun la valoroj, kiujn la institucio publikigas por sia propra reto, kaj traktu malkongruon kiel demandon por la posedanto de la agordo, ne kiel ion por alklaki.

Revizuu la instalitan agordon per la subtenataj agordoj de la platformo, por ke vi sciu, kio efektive validas. Forigi ĉiujn atestilojn de la aparato rompas neligitajn alirojn, kaj akcepti nekonatan anstataŭaĵon malfortigas la identeckontrolon, kiun vi volis konservi. Korektu la konkretan malkongruon kaj lasu la reston de la fido-konservejo trankvile.