Merk oversetter: for lesernes bekvemmelighet er datoer gitt i Moskva-tid
Vi gikk nylig glipp av utløpet av et av sertifikatene som ble brukt til å signere tillegg. Dette resulterte i at tillegg ble deaktivert for brukere. Nå som problemet stort sett er løst, vil jeg gjerne dele detaljene om hva som skjedde og arbeidet som ble gjort.
Bakgrunn: tillegg og signaturer
Installerte tillegg må ha digital signatur, som beskytter brukere mot ondsinnede tillegg og krever minimal gjennomgang av tillegg av Mozilla-ansatte. Vi introduserte dette kravet i 2015 fordi vi opplevde alvorlige problemer med ondsinnede tillegg.
Slik fungerer det: Hver kopi av Firefox inneholder et "rotsertifikat". Nøkkelen til denne "roten" er lagret i Maskinvaresikkerhetsmodul (HSM)uten nettverkstilgang. Med noen års mellomrom signeres et nytt «mellomsertifikat» med denne nøkkelen, som brukes ved signering av tillegg. Når en utvikler sender inn et tillegg, lager vi et midlertidig "sluttsertifikat" og signerer det ved hjelp av et mellomsertifikat. Selve tillegget signeres deretter med det endelige sertifikatet. Skjematisk det ser slik ut.
Vær oppmerksom på at hvert sertifikat har et "emne" (som sertifikatet ble utstedt til) og en "utsteder" (som utstedte sertifikatet). Når det gjelder et rotsertifikat, er "emne" = "utsteder", men for andre sertifikater er utstederen av sertifikatet gjenstand for det overordnede sertifikatet som det er signert med.
Et viktig poeng: hvert tillegg er signert av et unikt sluttsertifikat, men nesten alltid er disse sluttsertifikatene signert av det samme mellomsertifikatet.
Forfatterens notat: Unntaket er svært gamle tillegg. Den gang ble det brukt ulike mellomsertifikater.
Dette mellomsertifikatet skapte problemer: hvert sertifikat er gyldig i en viss periode. Før eller etter denne perioden er sertifikatet ugyldig og nettleseren vil ikke bruke tillegg signert av dette sertifikatet. Dessverre gikk mellombeviset ut 4. mai klokken 4.
Konsekvensene viste seg ikke umiddelbart. Firefox sjekker ikke signaturene til installerte tillegg konstant, men omtrent en gang hver 24. time, og bekreftelsestiden er individuell for hver bruker. Som et resultat fikk noen problemer umiddelbart, mens andre fikk problemer mye senere. Vi ble først klar over problemet da sertifikatet utløp og begynte umiddelbart å lete etter en løsning.
Redusere skade
Da vi skjønte hva som hadde skjedd, prøvde vi å forhindre at situasjonen ble verre.
For det første sluttet de å akseptere og signere nye tillegg. Det er ingen vits i å bruke et utløpt sertifikat for dette. Når jeg ser tilbake, vil jeg si at vi kunne ha latt alt være som det var. Vi har nå gjenopptatt å ta i mot tillegg.
For det andre sendte de umiddelbart ut en rettelse som forhindret at signaturer ble sjekket på daglig basis. Dermed reddet vi de brukerne hvis nettleser ennå ikke hadde hatt tid til å sjekke tilleggene de siste XNUMX timene. Denne rettelsen er nå trukket tilbake og er ikke lenger nødvendig.
Parallell drift
I teorien ser løsningen på problemet enkel ut: lag et nytt gyldig mellomsertifikat og signer hvert tillegg på nytt. Dette vil dessverre ikke fungere:
- vi kan ikke raskt signere 15 tusen tillegg på en gang, systemet er ikke designet for en slik belastning
- Etter at vi har signert tilleggene, må de oppdaterte versjonene leveres til brukerne. De fleste tilleggene er installert fra Mozilla-servere, så Firefox vil finne oppdateringer i løpet av de neste XNUMX timene, men noen utviklere distribuerer signerte tillegg via tredjepartskanaler, så brukere må oppdatere slike tillegg manuelt
I stedet prøvde vi å utvikle en løsning som ville nå alle brukere uten å kreve mye eller ingen handling fra deres side.
Ganske raskt kom vi til to hovedstrategier, som vi brukte parallelt:
- Oppdater Firefox for å endre sertifikatets gyldighetsperiode. Dette vil få eksisterende tillegg til å virke magisk igjen, men vil kreve utgivelse og sending av en ny versjon av Firefox
- Generer et gyldig sertifikat og overbevis Firefox om å godta det i stedet for det eksisterende som har utløpt
Vi bestemte oss for å bruke det første alternativet først, som så ganske gjennomførbart ut. På slutten av dagen ga de ut en ny reparasjon (et nytt sertifikat), som vi skal snakke om senere.
Erstatter et sertifikat
Som jeg nevnte ovenfor, var det nødvendig:
- opprette et nytt gyldig sertifikat
- installer den eksternt i Firefox
For å forstå hvorfor dette fungerer, la oss se nærmere på tilleggsbekreftelsesprosessen. Selve tillegget kommer som et sett med filer, inkludert en kjede med sertifikater som brukes til signering. Som et resultat kan tillegget verifiseres hvis nettleseren kjenner til rotsertifikatet, som er innebygd i Firefox på byggetidspunktet. Imidlertid, som vi allerede vet, har mellomsertifikatet utløpt, så det er umulig å verifisere tillegget.
Når Firefox forsøker å bekrefte et tillegg, er det ikke begrenset til å bruke sertifikatene i selve tillegget. I stedet prøver nettleseren å opprette en gyldig sertifikatkjede, starter med sluttsertifikatet og fortsetter til det kommer til roten. På første nivå starter vi med sluttsertifikatet og finner deretter sertifikatet hvis emne er utstederen av sluttbeviset (det vil si mellomsertifikatet). Vanligvis følger dette mellomsertifikatet med tillegget, men ethvert sertifikat fra nettleserens lagring kan også fungere som dette mellomsertifikatet. Hvis vi eksternt kan legge til et nytt gyldig sertifikat til sertifikatlageret, vil Firefox prøve å bruke det. Situasjonen før og etter installasjon av et nytt sertifikat.
Etter å ha installert det nye sertifikatet, vil Firefox ha to alternativer ved validering av sertifikatkjeden: bruk det gamle ugyldige sertifikatet (som ikke vil fungere) eller det nye gyldige sertifikatet (som vil fungere). Det er viktig at det nye sertifikatet inneholder samme emnenavn og offentlige nøkkel som det gamle sertifikatet, slik at signaturen på det endelige sertifikatet vil være gyldig. Firefox er smart nok til å prøve begge alternativene til den finner en som fungerer, så tilleggene blir testet igjen. Merk at dette er den samme logikken vi bruker for å validere TLS-sertifikater.
Forfatterens merknad: Lesere som er kjent med WebPKI vil merke seg at krysssertifikater fungerer på nøyaktig samme måte.
Det fine med denne løsningen er at den ikke krever at du signerer eksisterende tillegg på nytt. Så snart nettleseren mottar det nye sertifikatet, vil alle tillegg fungere igjen. Den gjenstående utfordringen er å levere det nye sertifikatet til brukere (automatisk og eksternt), samt få Firefox til å sjekke deaktiverte tillegg på nytt.
Normandie og forskningssystemet
Ironisk nok er dette problemet løst av et spesielt tillegg kalt "system". For å utføre forskning utviklet vi et system kalt Normandie som leverer forskning til brukerne. Disse studiene utføres automatisk i nettleseren, og har forbedret tilgang til Firefoxs interne APIer. Forskning kan legge til nye sertifikater til sertifikatlageret.
Forfatterens merknad: Vi legger ikke til et sertifikat med noen spesielle privilegier; det er signert av rotsertifikatet, så Firefox stoler på det. Vi legger den ganske enkelt til i utvalget av sertifikater som kan brukes av nettleseren.
Så løsningen er å lage en studie:
- installere det nye sertifikatet vi opprettet for brukere
- tvinger nettleseren til å sjekke deaktiverte tilleggsprogrammer på nytt slik at de fungerer igjen
"Men vent," sier du, "tillegg fungerer ikke, hvordan kan jeg starte et systemtillegg?" La oss signere det med et nytt sertifikat!
Å sette alt sammen... hvorfor tar det så lang tid?
Så planen: utsted et nytt sertifikat for å erstatte det gamle, lag et systemtillegg og installer det til brukere via Normandie. Problemene begynte som sagt 4. mai klokken 4, og allerede klokken 00 samme dag, mindre enn 12 timer senere, sendte vi en løsning til Normandie. Det tok ytterligere 44-9 timer før den nådde alle brukere. Ikke verst i det hele tatt, men folk på Twitter spør hvorfor vi ikke kunne ha handlet raskere.
For det første tok det tid å utstede et nytt mellomsertifikat. Som jeg nevnte ovenfor, er nøkkelen til rotsertifikatet lagret offline i maskinvaresikkerhetsmodulen. Dette er bra fra et sikkerhetssynspunkt, siden roten brukes svært sjelden og bør være pålitelig beskyttet, men det er litt upraktisk når du raskt trenger å signere et nytt sertifikat. En av våre ingeniører måtte reise til HSM-lageret. Så var det mislykkede forsøk på å utstede riktig sertifikat, og hvert forsøk kostet en eller to timer brukt på testing.
For det andre tok utviklingen av systemtillegget litt tid. Konseptuelt er det veldig enkelt, men selv enkle programmer krever omsorg. Vi ville sørge for at vi ikke gjorde situasjonen verre. Forskning må testes før den sendes til brukere. I tillegg må tillegget signeres, men tilleggssigneringssystemet vårt ble deaktivert, så vi måtte finne en løsning.
Til slutt, når vi hadde forskningen klar for innsending, tok utplasseringen tid. Nettleseren ser etter Normandie-oppdateringer hver 6. time. Ikke alle datamaskiner er alltid på og koblet til Internett, så det vil ta tid før løsningen sprer seg til brukerne.
Siste trinn
Forskningen skal løse problemet for de fleste brukere, men er ikke tilgjengelig for alle. Noen brukere krever en spesiell tilnærming:
- brukere som har deaktivert forskning eller telemetri
- brukere av Android-versjonen (Fennec), hvor forskning ikke støttes i det hele tatt
- brukere av tilpassede versjoner av Firefox ESR i bedrifter der telemetri ikke kan aktiveres
- brukere som sitter bak MitM proxyer, siden vårt tilleggsinstallasjonssystem bruker nøkkelpinning, noe som ikke fungerer med slike proxyer
- brukere av eldre versjoner av Firefox som ikke støtter forskning
Vi kan ikke gjøre noe med den sistnevnte kategorien brukere – de bør fortsatt oppdatere til den nye versjonen av Firefox, fordi utdaterte har alvorlige uopprettede sårbarheter. Vi vet at noen bruker eldre versjoner av Firefox fordi de ønsker å kjøre gamle tillegg, men mange av de gamle tilleggene har allerede blitt overført til nyere versjoner av nettleseren. For andre brukere har vi utviklet en patch som vil installere et nytt sertifikat. Den ble utgitt som en feilrettingsutgivelse (oversetterens notat: Firefox 66.0.5), så folk vil få det - mest sannsynlig allerede fått det - gjennom den vanlige oppdateringskanalen. Hvis du bruker en tilpasset versjon av Firefox ESR, vennligst kontakt din vedlikeholder.
Vi forstår at dette ikke er ideelt. I noen tilfeller mistet brukere tilleggsdata (for eksempel tilleggsdata Flerkontokontainere).
Denne bivirkningen kunne ikke unngås, men vi tror at vi på kort sikt har valgt den beste løsningen for de fleste brukere. På sikt vil vi se etter andre, mer avanserte arkitektoniske tilnærminger.
Leksjoner
For det første gjorde teamet vårt en fantastisk jobb med å lage og sende en løsning på mindre enn 12 timer etter at problemet ble oppdaget. Som en som deltok på møtene, kan jeg si at i denne vanskelige situasjonen jobbet folk veldig hardt og veldig lite tid ble kastet bort.
Det er klart at ingenting av dette skulle ha skjedd i det hele tatt. Det er helt klart verdt å justere prosessene våre for å redusere sannsynligheten for slike hendelser og gjøre utbedring enklere.
Neste uke vil vi publisere en offisiell post mortem og en liste over endringer vi har tenkt å gjøre. Foreløpig vil jeg dele tankene mine. For det første må det være en bedre måte å overvåke statusen til det som er en potensiell tidsinnstilt bombe. Vi må være sikre på at vi ikke kommer i en situasjon der en av dem plutselig jobber. Vi jobber fortsatt med detaljene, men som et minimum er det nødvendig å ta hensyn til alle slike ting.
For det andre trenger vi en mekanisme for raskt å levere oppdateringer til brukere, selv når – spesielt når – alt annet feiler. Det var flott at vi kunne bruke "forsknings"-systemet, men det er et ufullkomment verktøy og har noen uønskede bivirkninger. Spesielt vet vi at mange brukere har automatiske oppdateringer slått på, men foretrekker å ikke delta i forskning (jeg innrømmer, jeg har dem slått av også!). Samtidig trenger vi en måte å sende oppdateringer til brukere på, men uansett den interne tekniske implementeringen, bør brukere kunne abonnere på oppdateringer (inkludert hurtigreparasjoner), men velge bort alt annet. I tillegg bør oppdateringskanalen være mer responsiv enn den er for øyeblikket. Selv den 6. mai var det fortsatt brukere som ikke benyttet seg av verken rettelsen eller den nye versjonen. Dette problemet er allerede jobbet med, men det som skjedde viste hvor viktig det er.
Til slutt skal vi se nærmere på tilleggets sikkerhetsarkitektur for å sikre at det gir riktig sikkerhetsnivå med minimal risiko for å ødelegge noe.
Neste uke skal vi se på resultatene av en grundigere analyse av hva som skjedde, men i mellomtiden svarer jeg gjerne på spørsmål på e-post: [e-postbeskyttet]
Kilde: linux.org.ru