Den Wi-Fi-sertifikatmeldingen er ikke en ny rot-CA

Dialogen vises mens du kobler til et campus- eller kontornettverk, den nevner et sertifikat og tilbyr en knapp der det står stol på eller fortsett. Bak den knappen skjuler det seg to svært forskjellige endringer. Den ene lærer Wi-Fi-klienten hvilken autentiseringsserver den skal godta for akkurat dette nettverket. Den andre installerer en sertifiseringsmyndighet som andre programmer deretter kan bruke. Ordlyden på skjermen er det eneste hintet du får, så les den før du trykker.

Trinn 1: les hva dialogen egentlig spør om

Se etter tre ting: det viste servernavnet, den oppgitte utstederen og om handlingen beskrives som å stole på en server for denne tilkoblingen eller som å installere et sertifikat på enheten. Dette er forskjellige objekter, og en melding som ikke sier hvilket du godkjenner, fortjener en pause.

Ikke godkjenn noen av versjonene bare fordi nettverksnavnet ser kjent ut. SSID-er velges av den som driver tilgangspunktet, og navnet på den captive portalen er ikke bevis for autentiseringsserveren bak. Alle med et tilgangspunkt kan sende ut en overbevisende SSID. Det er nettopp derfor sertifikatkontrollen finnes.

Hva et 802.1X-serversertifikat beviser

I en 802.1X-utrulling med sertifikater validerer enhetens supplikant autentiseringsserveren under forhandlingen. Apples veiledning for 802.1X-utrulling beskriver at RADIUS-serveren viser sertifikatet sitt, og at tillitsbeslutningen hører til den tjenesten.

Den siste delen er hele poenget. Et sertifikat utstedt av en kjent CA beviser at utstederen signerte det, ikke at akkurat denne serveren tilhører institusjonen du tror du koblet deg til. Formålsbegrenset tillit finnes nettopp fordi det andre spørsmålet er det som betyr noe.

Støttede konfigurasjoner kan begrense tilliten til utvalgte serversertifikater eller forventede servernavn. Derfor distribuerer institusjoner en verifisert Wi-Fi-profil i stedet for å be brukerne godta det første sertifikatet som dukker opp, og derfor er en dialog uten forventet navn et dårlig sted å ta beslutningen.

Trinn 2: kontroller om en bredere myndighet er installert

En CA som en nettleser eller operativsystemet stoler på, rekker mye lenger enn et Wi-Fi-serversertifikat som er godtatt for ett nettverk. Identifiser objektet, lageret det havnet i, formålet det er tillatt for, og hvilke programmer som konsulterer det lageret.

En konfigurasjonspakke kan inneholde flere innstillinger samtidig, så undersøk innholdet i stedet for å stole på Wi-Fi-etiketten på installasjonsprogrammet. Etiketten beskriver ærendet, ikke nødvendigvis alt pakken gjør.

Selv en bred rot beviser ikke at hver HTTPS-økt blir inspisert. Inspeksjon krever en egnet trafikkvei og et serversertifikat som programmet godtar etter sin reelle valideringspolicy, og programmer kan bruke forskjellige tillitslagre med ekstra kontroller.

Trinn 3: hold VPN-en utenfor tillitsbeslutningen

En VPN beskytter veien den dekker etter at enheten når VPN-peer-en. Den fjerner ikke en installert rot, endrer ikke et programs tillitsbeslutninger og verifiserer ikke en uventet Wi-Fi-autentiseringsserver på dine vegne.

Spør administratoren om nettverksautentisering, enhetsstyring og autorisert TLS-inspeksjon som tre separate spørsmål. Det er ikke tre navn for den samme sertifikatfunksjonen, og et støttesvar som slår dem sammen, forteller deg ikke hvilken endring du godkjente.

Trinn 4: løs avviket uten å ødelegge alt

Noter de ikke-hemmelige opplysningene fra dialogen: servernavnet, utstederen og fingeravtrykket hvis det vises. Sammenlign dem med verdiene institusjonen publiserer for sitt eget nettverk, og behandle et avvik som et spørsmål til eieren av konfigurasjonen, ikke som noe du klikker bort.

Gå gjennom den installerte konfigurasjonen via plattformens støttede innstillinger, så du vet hva som faktisk gjelder. Å slette alle sertifikatene på enheten bryter urelatert tilgang, og å godta en ukjent erstatning svekker identitetskontrollen du ville beholde. Rett det konkrete avviket, og la resten av tillitslageret være.