Den Wi-Fi-sertifikatmeldinga er ikkje ein ny rot-CA

Dialogen blir vist medan du koplar til eit campus- eller kontornettverk, han nemner eit sertifikat og tilbyr ein knapp der det står stol på eller hald fram. Bak den knappen skjuler det seg to svært ulike endringar. Den eine lærer Wi-Fi-klienten kva autentiseringsserver han skal godta for akkurat dette nettverket. Den andre installerer ei sertifiseringsstyresmakt som andre program deretter kan bruke. Ordlyden på skjermen er det einaste hintet du får, så les han før du trykkjer.

Steg 1: les kva dialogen eigentleg spør om

Sjå etter tre ting: det viste tenarnamnet, den oppgitte utferdaren og om handlinga blir skildra som å stole på ein tenar for denne tilkoplinga eller som å installere eit sertifikat på eininga. Dette er ulike objekt, og ei melding som ikkje seier kva du godkjenner, fortener ein pause.

Ikkje godkjenn nokon av versjonane berre fordi nettverksnamnet ser kjent ut. SSID-ar blir valde av den som driv tilgangspunktet, og namnet på den captive portalen er ikkje bevis for autentiseringsserveren bak. Alle med eit tilgangspunkt kan sende ut ein overtydande SSID. Det er nettopp derfor sertifikatkontrollen finst.

Kva eit 802.1X-tenarsertifikat beviser

I ei 802.1X-utrulling med sertifikat validerer supplikanten til eininga autentiseringsserveren under forhandlinga. Apples rettleing for 802.1X-utrulling skildrar at RADIUS-tenaren viser sertifikatet sitt, og at tillitsavgjerda høyrer til den tenesta.

Den siste delen er heile poenget. Eit sertifikat som er utstedt av ein kjend CA, beviser at utferdaren signerte det, ikkje at akkurat denne tenaren høyrer til institusjonen du trur du kopla deg til. Formålsavgrensa tillit finst nettopp fordi det andre spørsmålet er det som tel.

Støtta konfigurasjonar kan avgrense tillita til utvalde tenarsertifikat eller forventa tenarnamn. Derfor deler institusjonar ut ein verifisert Wi-Fi-profil i staden for å be brukarane godta det første sertifikatet som dukkar opp, og derfor er ein dialog utan forventa namn ein dårleg stad å ta avgjerda.

Steg 2: kontroller om ei breiare styresmakt er installert

Ein CA som ein nettlesar eller operativsystemet stolar på, rekk mykje lenger enn eit Wi-Fi-tenarsertifikat som er godtatt for eitt nettverk. Identifiser objektet, lageret det hamna i, føremålet det er tillate for, og kva program som konsulterer det lageret.

Ein konfigurasjonspakke kan innehalde fleire innstillingar samtidig, så gransk innhaldet i staden for å stole på Wi-Fi-etiketten på installasjonsprogrammet. Etiketten skildrar ærendet, ikkje nødvendigvis alt pakken gjer.

Ikkje ein gong ei brei rot beviser at kvar HTTPS-økt blir inspisert. Inspeksjon krev ein eigna trafikkveg og eit tenarsertifikat som programmet godtar etter sin reelle valideringspolicy, og program kan bruke ulike tillitslager med ekstra kontrollar.

Steg 3: hald VPN-en utanfor tillitsavgjerda

Ein VPN verner den vegen han dekkjer etter at eininga når VPN-peer-en. Han fjernar ikkje ei installert rot, endrar ikkje tillitsavgjerdene til eit program og verifiserer ikkje ein uventa Wi-Fi-autentiseringsserver på dine vegne.

Spør administratoren om nettverksautentisering, einingstyring og autorisert TLS-inspeksjon som tre separate spørsmål. Det er ikkje tre namn for den same sertifikatfunksjonen, og eit støttesvar som slår dei saman, fortel deg ikkje kva endring du godkjende.

Steg 4: løys avviket utan å øydeleggje alt

Noter dei ikkje-hemmelege opplysningane frå dialogen: tenarnamnet, utferdaren og fingeravtrykket om det blir vist. Samanlikn dei med verdiane institusjonen publiserer for sitt eige nettverk, og handsam eit avvik som eit spørsmål til eigaren av konfigurasjonen, ikkje som noko du klikkar bort.

Gå gjennom den installerte konfigurasjonen via dei støtta innstillingane på plattforma, så du veit kva som faktisk gjeld. Å slette alle sertifikata på eininga bryt urelatert tilgang, og å godta ei ukjend erstatning svekkjer identitetskontrollen du ville behalde. Rett det konkrete avviket, og lat resten av tillitslageret vere.