Android-varsel om nettverksovervaking: les endringa i tillit

Tre varsel ser like ut på ein telefon, og berre eitt av dei handlar om eit sertifikat. Ei VPN-statuslinje, ei åtvaring frå tillitslageret og eit banner for styrt eining nemner kvar sin kontroll, og appen som er på skjermen i augneblinken eig kanskje ingen av dei. Å lese den nøyaktige ordlyden først sparer deg for å slette feil ting. Gå gjennom dei fem sjekkane nedanfor i rekkefølgje og stopp ved den første som feilar, fordi rett handling endrar seg heilt på kvart trinn.

Trinn 0: identifiser kva varsel du ser på

Ordlyden betyr meir enn ikonet. Eit VPN-statusvarsel betyr at ein app held ein aktiv VpnService. Ei sertifikatåtvaring betyr at noko er installert i eit tillitslager. Eit varsel om styrt eining betyr at ein administrator har brukt ein policy, som kan ha installert tillita som ein del av den policyen.

Når teksten bokstaveleg talt seier «Network may be monitored», er avsendaren systemet og ikkje VPN-leverandøren: Android skriv ut den linja kvar gong ein app held ein aktiv VpnService, så ein vanleg kommersiell klient produserer henne utan å leggje noko i tillitslageret. To av dei tre varsla kan vere sanne samstundes, og difor nemner klaga vanlegvis det gale. Viss setninga seier at ein CA er installert, er VPN-en på det meste ein mistenkt, og å avinstallere han kan la åtvaringa stå nøyaktig der ho var.

Trinn 1: finn legitimasjonen og lageret hans

På Android 9 til 12 er banen Innstillingar, deretter Tryggleik, deretter Kryptering og legitimasjon, deretter Klarerte legitimasjonar; Android 13 og seinare flyttar same skjerm til Tryggleik og personvern, deretter Fleire tryggingsinnstillingar, og grensesnitta til leverandørane gir nivåa nye namn igjen, så søk i Innstillingar-appen etter «Klarerte legitimasjonar» når banen ikkje stemmer. Fana Brukar inneheld autoritetar installerte av ein person eller ein app, og fana System inneheld det som følgde med bygget. Ein autoritet som administrasjonen skyv ut, viser seg gjennom einingapolicyen eller inne i ein arbeidsprofil, ikkje som eit vanleg trykk i brukarlageret.

Noter utgivaren, gyldigheitsdatoane og kven som installerte han. Viss oppføringa ikkje er i brukarlageret i det heile, stopp her, fordi det er eit system- eller styrt element, og det er ikkje di oppgåve å slette det frå ein innstillingsskjerm. Å slette feil rad der er korleis ein telefon mistar Wi-Fi eller ei jobbinnlogging medan tillitsspørsmålet står ubesvart.

Trinn 2: skil CA-en til ein VPN-profil frå tillita til telefonen

Ein OpenVPN-profil, eller ein kva som helst klient som autentiserer serveren sin over TLS, kan innehalde ein CA som berre den klienten brukar for å stadfeste sin eigen server. Ein WireGuard-profil inneheld ingen CA i det heile: han byggjer på offentlege nøkkelpar, så ein autoritet i tillitslageret til Android kan aldri ha kome frå ein WireGuard-konfigurasjon. Det profillokale sertifikatet når ingen annan app, og å kopiere det til tillitslageret i systemet er ein separat operasjon med eit separat påverkingsområde. Å halde dei to frå kvarandre er heile poenget med dette trinnet, fordi berre det andre endrar kva andre apper vil godta.

Ein VPN-profil som inneheld ein CA er difor ikkje bevis på avlytting, og ein VPN-app er ikkje eigar av ei tillitsoppføring han aldri har laga. Testen er billeg: stopp VPN-en og les varselet på nytt. Viss sertifikatåtvaringa framleis er der, sette ikkje VPN-en henne der, og å fjerne appen vil ikkje fjerne henne.

Trinn 3: skil ein serverautoritet frå ein klientidentitet

Eit klientidentitetssertifikat og den private nøkkelen autentiserer denne eininga mot ein server. Ein CA er betrodd for å autentisere serverar mot apper. Dei blir lagra saman og ser like ut i ei liste, men gjer heilt ulike jobbar.

Å fjerne ein klientidentitet kan bryte Wi-Fi- eller VPN-autentisering utan å gjere noko med HTTPS-tillita, og å fjerne ein CA påverkar kvar app som godtek den autoriteten. Avgjer kva av dei to du ser på før du trykkjer på noko, fordi svaret namngir eigaren og gjenopprettingsvegen.

Trinn 4: spør kva apper som faktisk stolar på han

Nettverkstryggingskonfigurasjonen til Android set grensa for appen. Apper som rettar seg mot API 24 eller nyare, stolar som standard på systemautoritetar, medan apper som rettar seg mot API 23 eller eldre, som standard òg stolar på autoritetar brukaren har lagt til, og ein app kan namngi sine eigne anker, leggje til reglar per domene eller melde seg heilt ut av standardverdiane.

Så «installert på telefonen» skildrar ikkje HTTPS-tillita til kvar app: ein autoritet brukaren har lagt til, kan bli respektert av ein eldre app, ignorert av ein noverande og eksplisitt betrodd av ein app som har eigne anker. Viss autoriteten vart installert for jobb-Wi-Fi, ein privat webtjeneste eller eit godkjent inspeksjonsoppsett, er det nyttige spørsmålet kva apper og profilar som er avhengige av han. Rettleiinga for nettverkstryggingskonfigurasjon er referansen for kor langt ein installert autoritet rekk i ein gitt app, og det er delen dei fleste samandrag av dette varselet utelèt.

Trinn 5: avgjer, og registrer deretter eigaren og utgangsplanen

Viss autoriteten er venta, dokumenter kven som installerte han, kva tilkoplingar som er avhengige av han, og korleis han skal avviklast. Å stole på ein autoritet er ei viktig avgjerd sjølv når inga avlytting skjer i dag, fordi tillita er det som gjer avlytting mogleg seinare.

Viss han er uventa, undersøk gjennom eigaren av eininga eller tenesta før du legg inn sensitive data på den telefonen. Viss han er utdatert, fjern akkurat det elementet gjennom den som installerte det, etter å ha sjekka kva som er avhengig av det, og byrja aldri med å slette all legitimasjon. Å skjule åtvaringa endrar visninga og ingenting anna. Ein privat nøkkel eller ein full profil bør aldri lastast opp til ein offentleg sertifikatkontrollteneste for å avgjere spørsmålet.

Før du forlèt skjermen vil du ha tre svar: kven som installerte han, kva tilkoplingar som er avhengige av han, og korleis han blir avvikla.