Hva er trustd på Mac? Den forklarer sertifikat-trustdæmonen

trustd er sertifikat-tillitsvurderingsdemonen som er innebygd i macOS. Det er en systemprosess som er levert og kode-signert av Apple, og oppgaven dens er å avgjøre om de digitale sertifikatene som servere Mac-en din kobler til, skal stoles på.

Hver gang noe på Mac-en din oppretter en HTTPS- eller TLS-tilkobling, presenterer serveren en sertifikatkjede: sitt eget sertifikat, vanligvis ett eller flere mellomsertifikater, og til slutt et rotssertifikat som skal være et systemet ditt allerede stoler på. Noen må sjekke den kjeden. Det er trustd. Den vurderer om sertifikatet er gyldig signert, om det har utløpt, om det er tilbakekalt, og om kjeden ender i en rot som Mac-en din virkelig stoler på.

Dette arbeidet gjøres ikke per app. I stedet for at hver nettleser, e-postklient, oppdateringsprogram og Electron-app implementerer sin egen sertifikatlogikk og gjør feil, sentraliserer macOS tillitsvurderingen i én systemtjeneste. Derfor ser du at trustd er opptatt: den jobber på vegne av nesten alle nettverksprosesser samtidig. En sideinnlasting i Safari, en e-postkontroll, en filsynkronisering og en bakgrunnsoppdatering kan alle utløse tillitsvurderinger i samme sekund.

Du vil vanligvis se at trustd kjører som en systemnivåprosess, noen ganger sammen med en per-bruker-instans. Begge er normale. Det er ikke noe du har installert, og det er ikke noe du kan fjerne på en meningsfull måte.

Dette er delen som skremmer folk, så det er verdt å forklare tydelig. Å sjekke om et sertifikat er gyldig signert kan gjøres offline, med bare matematikk. Å sjekke om et sertifikat fortsatt er gyldig akkurat nå kan ikke.

Sertifikater blir tilbakekalt. En servers private nøkkel blir stjålet, en sertifikatmyndighet utsteder noe feilaktig, et selskap mister kontrollen over et domene. I alle disse tilfellene er sertifikatet fortsatt kryptografisk godt utformet og innenfor sine angitte gyldighetsdatoer, men det bør ikke lenger stoles på. Den eneste måten Mac-en din kan vite det på, er å konsultere data publisert andre steder, og det betyr en nettverksforespørsel.

Derfor kontakter trustd Apple-infrastrukturen for sertifikattilbakekallings- og gyldighetsinformasjon, i den generelle familien av OCSP-aktige statuskontroller, sammen med Apples egne valideringstjenester og sertifikat-åpenhetsrelaterte data som brukes til å oppdage sertifikater som ble utstedt, men aldri burde ha vært det. Når du ser trustd koble til Apple-domener gjentatte ganger, er det det disse tilkoblingene er. Det er et sikkerhetssøk, ikke en rapport om deg.

Apple cacher også disse dataene, noe som er grunnen til at mønsteret er burstaktig i stedet for helt proporsjonalt med nettlesingen din. Forvent en gruppe tilkoblinger etter en omstart, etter en lang inaktiv periode, eller når du besøker nettsteder du ikke har sett nylig, og relativt få mellom dem. Den underliggende tillits- og valideringsstakken støtter også andre macOS-sjekker rundt signert og notarized programvare, selv om detaljene i hvordan disse delene samhandler er Apples å dokumentere.

Nei. trustd er en førsteparts Apple-systemdemon og en dokumentert del av macOS-sikkerheten. Det finnes ingen versjon av en sunn Mac som mangler den.

Det sagt, å ta en artikkels ord for god fisk er nøyaktig den typen vurdering skadelig programvare stoler på, så det er fornuftig å verifisere på din egen maskin. To ting er verdt å bekrefte, og ingen av dem krever spesialverktøy.

Det første er plassering. Apples systemdemoner ligger inne i beskyttede systemstier; trustd sin kjørbare fil ligger i systemets usr/libexec-område, som på moderne macOS er på det skrivebeskyttede signerte systemvolumet som skadelig programvare ikke kan skrive til. I Activity Monitor, velg prosessen og åpne inspektøren for å se dens rapporterte sti. Noe som heter trustd som kjører fra hjemmemappen din, en nedlastingsmappe eller en ukjent app-pakke vil være et ekte rødt flagg. Kjører den fra systemvolumet, er det den ekte.

Det andre er signaturen. macOS kan fortelle deg hvem som har signert en kjørende binær, og Apples demoner er signert av Apple med systemrettigheter. Riktig sti pluss Apple-signatur betyr at du ser på operativsystemet. Det hjelper også å lese prosessnavnet nøye i stedet for å bare kaste et blikk, siden impostorer vanligvis velger navn som er nært, men ikke identiske.

En ekstra trygghet: høy CPU-bruk eller jevn nettverksaktivitet fra trustd er ikke bevis på kompromiss. Det betyr at mange TLS-tilkoblinger blir evaluert, noe som på en normal Mac er helt vanlig.

Du kan teknisk blokkere trustd med en brannmur. Du bør ikke gjøre det. Av alle bakgrunnsprosessene i macOS folk fristes til å dempe, er dette en av de få hvor blokkering aktivt gjør Mac-en din mindre trygg, heller enn mer privat.

Sertifikatvalidering er en kjerne sikkerhetskontroll. Det er mekanismen som hindrer at Mac-en din stilltiende godkjenner et tilbakekalt sertifikat eller en kjede som fører til ingenting pålitelig. Degraderer du den, degraderer du garantien for at den krypterte tilkoblingen du tror du har med en server, faktisk er med den serveren.

De praktiske konsekvensene kommer raskt: HTTPS-tilkoblinger som feiler direkte, tilkoblinger som henger mens systemet venter på en valideringssjekk som aldri kommer, vage sertifikatfeil i andre apper, innloggingsprosesser som slutter å fungere. Fordi trustd sitter under nesten alt, peker symptomene sjelden tilbake til årsaken. Du får en Mac som føles ødelagt på spredte måter, heller enn en åpenbar advarsel.

Den ærlige personvernsnyansen er dette: tilbakekallelse og gyldighetskontroll forteller i seg selv tjenesten som utfører sjekken at et sertifikat ble validert på et tidspunkt. Det er en reell egenskap ved hvordan denne mekanismen fungerer, ikke en skjult. Apple har publisert informasjon om hvordan den håndterer denne trafikken, og den dokumentasjonen er riktig kilde for detaljer, heller enn spekulasjoner. Det er også verdt å merke seg at sertifikat- og notariseringsrelatert sjekking på macOS fikk bred offentlig oppmerksomhet for noen år siden, da et Apple-tjenesteproblem forårsaket merkbare tregheter ved oppstart av apper, etterfulgt av at Apple endret aspekter av hvordan disse sjekkene opererer. Poenget er ikke at mekanismen er ondsinnet, men at den er lastbærende nok til at alle legger merke til når den strever.

Så overvåk trustd hvis du vil forstå maskinen din. Ikke blokkér den.

Den angsten trustd genererer har veldig lite å gjøre med trustd. Det er at en rå tilkoblingslogg er nesten uleselig. En prosess du ikke startet kontakter et domene du ikke gjenkjenner med en frekvens du ikke kan forklare, og den beskrivelsen passer like godt til sertifikatvalidering, krasjrapportering, oppdateringssjekker og analyse-SDK-er.

Så folk enten ignorerer alt, noe som betyr at ekte sporing går ubemerket hen, eller blokkerer på instinkt, noe som er hvordan maskiner ender opp med mystiske HTTPS-feil. Begge kommer fra det samme manglende brikken: kontekst om hvilken prosess som snakker, hvor den snakker til, og om den destinasjonen er kjent infrastruktur eller en kjent tracker.

Den konteksten er det NetMute tilbyr. Det viser sanntids trafikk per app og prosess, slik at en tilkobling kan tilskrives trustd i stedet for anonym. Loggføring på domenenivå registrerer hvilke domener en prosess kontaktet, når, og hvor mye data som ble overført, og gjør "noe snakker med Apple" til en sjekkerbar oppføring. Tracker Shield opprettholder en kategorisert liste over over 1 100 kjente tracker-domener, slik at ekte sporing kan skilles ut fra vanlig systemtrafikk i stedet for å være begravet i den. Og når du finner noe som ikke burde snakke, tilbyr den per-app-brannmuren ett-klikk-blokkering pluss selvutløpende midlertidige regler, slik at du kan teste om blokkering bryter noe før du forplikter deg.

Anvendt her er arbeidsflyten kort. Se på trustd, se den kontakte Apples valideringsinfrastruktur, bekreft at den ikke er på noen tracker-liste, la den være i fred. Deretter peker du samme visning mot appen du faktisk hadde et spørsmål om, fordi det sjelden er systemdæmonen.