Android-varsel om nettverksovervåking: les endringen i tillit

Tre varsler ser like ut på en telefon, og bare ett av dem handler om et sertifikat. En VPN-statuslinje, en advarsel fra tillitslageret og et banner for administrert enhet nevner hver sin kontroll, og appen som er på skjermen i øyeblikket eier kanskje ingen av dem. Å lese den nøyaktige ordlyden først sparer deg for å slette feil ting. Gå gjennom de fem sjekkene nedenfor i rekkefølge og stopp ved den første som feiler, fordi riktig handling endres helt på hvert trinn.

Trinn 0: identifiser hvilket varsel du ser på

Ordlyden betyr mer enn ikonet. Et VPN-statusvarsel betyr at en app holder en aktiv VpnService. En sertifikatadvarsel betyr at noe er installert i et tillitslager. Et varsel om administrert enhet betyr at en administrator har brukt en policy, som kan ha installert tilliten som en del av den policyen.

Når teksten bokstavelig talt sier «Network may be monitored», er avsenderen systemet og ikke VPN-leverandøren: Android skriver ut den linjen hver gang en app holder en aktiv VpnService, så en vanlig kommersiell klient produserer den uten å legge noe i tillitslageret. To av de tre varslene kan være sanne samtidig, og derfor nevner klagen vanligvis det gale. Hvis setningen sier at en CA er installert, er VPN-en på det meste en mistenkt, og å avinstallere den kan la advarselen stå nøyaktig der den var.

Trinn 1: finn legitimasjonen og lageret dens

På Android 9 til 12 er banen Innstillinger, deretter Sikkerhet, deretter Kryptering og legitimasjon, deretter Klarerte legitimasjoner; Android 13 og senere flytter samme skjerm til Sikkerhet og personvern, deretter Flere sikkerhetsinnstillinger, og leverandørenes grensesnitt gir nivåene nye navn igjen, så søk i Innstillinger-appen etter «Klarerte legitimasjoner» når banen ikke stemmer. Fanen Bruker inneholder autoriteter installert av en person eller en app, og fanen System inneholder det som fulgte med bygget. En autoritet som administrasjonen skyver ut, vises gjennom enhetspolicyen eller inne i en arbeidsprofil, ikke som et vanlig trykk i brukerlageret.

Noter utstederen, gyldighetsdatoene og hvem som installerte den. Hvis oppføringen ikke er i brukerlageret i det hele tatt, stopp her, fordi det er et system- eller administrert element, og det er ikke din oppgave å slette det fra en innstillingsskjerm. Å slette feil rad der er hvordan en telefon mister Wi-Fi eller en jobbinnlogging mens tillitsspørsmålet står ubesvart.

Trinn 2: skill CA-en til en VPN-profil fra telefonens tillit

En OpenVPN-profil, eller en hvilken som helst klient som autentiserer serveren sin over TLS, kan inneholde en CA som bare den klienten bruker for å verifisere sin egen server. En WireGuard-profil inneholder ingen CA i det hele tatt: den bygger på offentlige nøkkelpar, så en autoritet i Androids tillitslager kan aldri ha kommet fra en WireGuard-konfigurasjon. Det profillokale sertifikatet når ingen annen app, og å kopiere det til systemets tillitslager er en separat operasjon med et separat påvirkningsområde. Å holde de to fra hverandre er hele poenget med dette trinnet, fordi bare det andre endrer hva andre apper vil godta.

En VPN-profil som inneholder en CA er derfor ikke bevis på avlytting, og en VPN-app er ikke eier av en tillitsoppføring den aldri har laget. Testen er billig: stopp VPN-en og les varselet på nytt. Hvis sertifikatadvarselen fortsatt er der, satte ikke VPN-en den der, og å fjerne appen vil ikke fjerne den.

Trinn 3: skill en serverautoritet fra en klientidentitet

Et klientidentitetssertifikat og den private nøkkelen autentiserer denne enheten mot en server. En CA er betrodd for å autentisere servere mot apper. De lagres sammen og ser like ut i en liste, men gjør helt forskjellige jobber.

Å fjerne en klientidentitet kan bryte Wi-Fi- eller VPN-autentisering uten å gjøre noe med HTTPS-tilliten, og å fjerne en CA påvirker hver app som godtar den autoriteten. Bestem hvilken av de to du ser på før du trykker på noe, fordi svaret navngir eieren og gjenopprettingsveien.

Trinn 4: spør hvilke apper som faktisk stoler på den

Androids nettverkssikkerhetskonfigurasjon setter appens grense. Apper som retter seg mot API 24 eller nyere, stoler som standard på systemautoriteter, mens apper som retter seg mot API 23 eller eldre, som standard også stoler på autoriteter brukeren har lagt til, og en app kan navngi sine egne ankre, legge til regler per domene eller melde seg helt ut av standardverdiene.

Så «installert på telefonen» beskriver ikke HTTPS-tilliten til hver app: en autoritet brukeren har lagt til, kan bli respektert av en eldre app, ignorert av en nåværende og eksplisitt betrodd av en app som har egne ankre. Hvis autoriteten ble installert for jobb-Wi-Fi, en privat webtjeneste eller et godkjent inspeksjonsoppsett, er det nyttige spørsmålet hvilke apper og profiler som avhenger av den. Veiledningen for nettverkssikkerhetskonfigurasjon er referansen for hvor langt en installert autoritet rekker i en gitt app, og det er delen de fleste sammendrag av dette varselet utelater.

Trinn 5: bestem, og registrer deretter eieren og utgangsplanen

Hvis autoriteten er forventet, dokumenter hvem som installerte den, hvilke tilkoblinger som avhenger av den, og hvordan den skal avvikles. Å stole på en autoritet er en betydningsfull beslutning selv når ingen avlytting skjer i dag, fordi tilliten er det som gjør avlytting mulig senere.

Hvis den er uventet, undersøk gjennom eieren av enheten eller tjenesten før du legger inn sensitive data på den telefonen. Hvis den er utdatert, fjern akkurat det elementet gjennom den som installerte det, etter å ha sjekket hva som avhenger av det, og begynn aldri med å slette all legitimasjon. Å skjule varselet endrer visningen og ingenting annet. En privat nøkkel eller en full profil bør aldri lastes opp til en offentlig sertifikatkontrolltjeneste for å avgjøre spørsmålet.

Før du forlater skjermen vil du ha tre svar: hvem som installerte den, hvilke tilkoblinger som avhenger av den, og hvordan den avvikles.