Huomautus kääntäjä: lukijoiden mukavuuden vuoksi päivämäärät on annettu Moskovan aikaa
Äskettäin yksi lisäosien allekirjoittamiseen käytetyistä varmenteista ei vanhentunut. Tämä johti siihen, että lisäosat poistettiin käytöstä käyttäjiltä. Nyt kun ongelma on pääosin korjattu, haluaisin jakaa yksityiskohdat tapahtuneesta ja tehdystä työstä.
Taustaa: lisäyksiä ja allekirjoituksia
Asennetuissa lisäosissa tulee olla digitaalinen allekirjoitus, joka suojaa käyttäjiä haitallisilta lisäosilta ja vaatii vain vähän Mozillan henkilökunnan lisäosien tarkistamista. Otimme tämän vaatimuksen käyttöön vuonna 2015, koska koimme vakavia ongelmia haitallisilla lisäosilla.
Kuinka se toimii: Jokainen Firefoxin kopio sisältää "juurivarmenteen". Tämän "juuren" avain on tallennettu Hardware Security Module (HSM)ilman verkkoyhteyttä. Tällä avaimella allekirjoitetaan muutaman vuoden välein uusi ”välivarmenne”, jota käytetään lisäosien allekirjoittamiseen. Kun kehittäjä lähettää lisäosan, luomme väliaikaisen "loppuvarmenteen" ja allekirjoitamme sen käyttämällä välisertifikaattia. Itse lisäosa allekirjoitetaan sitten lopullisella varmenteella. Kaavamaisesti se näyttää tältä.
Huomaa, että jokaisella varmenteella on "subjekti" (jolle varmenne on myönnetty) ja "myöntäjä" (joka on myöntänyt varmenteen). Juurivarmenteen tapauksessa "subject" = "myöntäjä", mutta muissa varmenteissa varmenteen myöntäjä on päävarmenteen, jolla se on allekirjoitettu, kohteena.
Tärkeä seikka: jokainen lisäosa allekirjoitetaan ainutlaatuisella loppuvarmenteella, mutta lähes aina nämä loppuvarmenteet allekirjoitetaan samalla välivarmenteella.
Tekijän huomautus: Poikkeuksena ovat hyvin vanhat lisäykset. Tuolloin käytettiin erilaisia välisertifikaatteja.
Tämä välisertifikaatti aiheutti ongelmia: jokainen varmenne on voimassa tietyn ajan. Ennen tätä tai sen jälkeen varmenne on virheellinen, eikä selain käytä tällä varmenteella allekirjoitettuja lisäosia. Valitettavasti välitodistus päättyi 4. klo 4.
Seuraukset eivät näkyneet heti. Firefox ei tarkista asennettujen lisäosien allekirjoituksia jatkuvasti, vaan noin kerran 24 tunnin välein, ja vahvistusaika on jokaiselle käyttäjälle yksilöllinen. Tämän seurauksena jotkut ihmiset kokivat ongelmia välittömästi, kun taas toiset kokivat ongelmia paljon myöhemmin. Huomasimme ongelman ensimmäisen kerran varmenteen voimassaolon päättyessä ja aloimme heti etsiä ratkaisua.
Vähentää vahinkoa
Kun tajusimme, mitä oli tapahtunut, yritimme estää tilanteen pahenemisen.
Ensinnäkin he lopettivat uusien lisäysten hyväksymisen ja allekirjoittamisen. Ei ole mitään järkeä käyttää vanhentunutta varmennetta tähän. Jälkeenpäin katsoessani sanoisin, että olisimme voineet jättää kaiken ennalleen. Olemme nyt jatkaneet lisäravinteiden vastaanottamista.
Toiseksi he lähettivät välittömästi korjauksen, joka esti allekirjoitusten päivittäisen tarkistamisen. Näin ollen säästimme käyttäjät, joiden selain ei ollut vielä ehtinyt tarkistaa lisäosia viimeisen XNUMX tunnin aikana. Tämä korjaus on nyt peruttu, eikä sitä enää tarvita.
Rinnakkaistoiminta
Teoriassa ratkaisu ongelmaan näyttää yksinkertaiselta: luo uusi kelvollinen välisertifikaatti ja allekirjoita jokainen lisäosa uudelleen. Valitettavasti tämä ei toimi:
- emme voi allekirjoittaa nopeasti uudelleen 15 tuhatta lisäosaa kerralla, järjestelmää ei ole suunniteltu sellaiselle kuormitukselle
- Kun olemme allekirjoittaneet lisäykset, päivitetyt versiot on toimitettava käyttäjille. Useimmat lisäosat asennetaan Mozillan palvelimilta, joten Firefox löytää päivitykset seuraavan XNUMX tunnin sisällä, mutta jotkut kehittäjät jakavat allekirjoitettuja lisäosia kolmannen osapuolen kanavien kautta, joten käyttäjien on päivitettävä lisäosat manuaalisesti.
Sen sijaan yritimme kehittää korjauksen, joka tavoittaisi kaikki käyttäjät ilman, että heiltä vaadittaisiin paljon tai ei yhtään mitään.
Melko nopeasti päädyimme kahteen päästrategiaan, joita käytimme rinnakkain:
- Päivitä Firefox muuttaaksesi varmenteen voimassaoloaikaa. Tämä saa nykyiset lisäosat toimimaan jälleen taianomaisesti, mutta vaatii uuden Firefoxin julkaisun ja toimituksen.
- Luo kelvollinen varmenne ja vakuuta Firefox jollakin tavalla hyväksymään se olemassa olevan vanhentuneen sertifikaatin sijaan
Päätimme käyttää ensin ensimmäistä vaihtoehtoa, joka näytti varsin toimivalta. Päivän päätteeksi he julkaisivat toisen korjauksen (uuden varmenteen), josta puhumme myöhemmin.
Varmenteen vaihtaminen
Kuten edellä mainitsin, vaadittiin:
- luo uusi kelvollinen varmenne
- asenna se etänä Firefoxiin
Ymmärtääksemme, miksi tämä toimii, katsotaanpa tarkemmin lisäosien vahvistusprosessia. Itse lisäosa tulee joukkona tiedostoja, mukaan lukien allekirjoittamiseen käytettyjen varmenteiden ketju. Tämän seurauksena lisäosa voidaan tarkistaa, jos selain tuntee juurivarmenteen, joka on sisäänrakennettu Firefoxiin rakennusvaiheessa. Kuten jo tiedämme, välivarmenne on kuitenkin vanhentunut, joten lisäosan tarkistaminen on mahdotonta.
Kun Firefox yrittää vahvistaa lisäosan, se ei rajoitu itse lisäosan sisältämien sertifikaattien käyttöön. Sen sijaan selain yrittää luoda kelvollisen varmenneketjun aloittaen loppuvarmenteesta ja jatkaen, kunnes se pääsee juureen. Ensimmäisellä tasolla aloitamme loppuvarmenteesta ja etsimme sitten varmenteen, jonka aihe on loppuvarmenteen (eli välivarmenteen) myöntäjä. Tyypillisesti tämä välisertifikaatti toimitetaan lisäosan mukana, mutta mikä tahansa sertifikaatti selaimen tallennustilasta voi toimia myös välivarmenteena. Jos voimme etänä lisätä uuden voimassa olevan varmenteen varmennevarastoon, Firefox yrittää käyttää sitä. Tilanne ennen ja jälkeen uuden varmenteen asentamisen.
Uuden varmenteen asennuksen jälkeen Firefoxilla on kaksi vaihtoehtoa varmenneketjun vahvistamisessa: käytä vanhaa virheellistä varmennetta (joka ei toimi) tai uutta voimassa olevaa varmennetta (joka toimii). On tärkeää, että uusi varmenne sisältää saman aiheen nimen ja julkisen avaimen kuin vanhassa varmenteessa, jotta sen allekirjoitus lopullisessa varmenteessa on voimassa. Firefox on tarpeeksi älykäs kokeillakseen molempia vaihtoehtoja, kunnes se löytää toimivan, joten lisäosat testataan uudelleen. Huomaa, että tämä on sama logiikka, jota käytämme TLS-varmenteiden vahvistamiseen.
Tekijän huomautus: WebPKI:n tuntevat lukijat huomaavat, että ristiinsertifikaatit toimivat täsmälleen samalla tavalla.
Hienoa tässä korjauksessa on, että se ei vaadi sinua allekirjoittamaan uudelleen olemassa olevia lisäosia. Heti kun selain vastaanottaa uuden varmenteen, kaikki lisäosat toimivat taas. Jäljellä oleva haaste on toimittaa uusi varmenne käyttäjille (automaattisesti ja etänä) sekä saada Firefox tarkistamaan käytöstä poistetut lisäosat.
Normandia ja tutkimusjärjestelmä
Ironista kyllä, tämä ongelma ratkaistaan erityisellä "järjestelmä" -lisäosalla. Tutkimuksen suorittamiseksi kehitimme Normandy-nimisen järjestelmän, joka toimittaa tutkimusta käyttäjille. Nämä tutkimukset suoritetaan automaattisesti selaimessa, ja niillä on parannettu pääsy Firefoxin sisäisiin sovellusliittymiin. Tutkimus voi lisätä uusia varmenteita varmennevarastoon.
Tekijän huomautus: Emme lisää varmennetta, jolla on erityisoikeuksia; se on allekirjoitettu juurivarmenneella, joten Firefox luottaa siihen. Lisäämme sen sertifikaattien joukkoon, jota selain voi käyttää.
Joten ratkaisu on luoda tutkimus:
- asentamalla käyttäjille luomamme uuden varmenteen
- pakottaa selaimen tarkistamaan käytöstä poistetut lisäosat, jotta ne toimivat uudelleen
"Mutta odota", sanot, "lisäosat eivät toimi, kuinka voin käynnistää järjestelmälisäosan?" Allekirjoitetaan se uudella todistuksella!
Kun kaikki yhdistetään... miksi se kestää niin kauan?
Suunnitelma siis: myönnä uusi varmenne vanhan tilalle, luo järjestelmälisäosa ja asenna se käyttäjille Normandian kautta. Ongelmat, kuten sanoin, alkoivat 4. toukokuuta klo 4:00 ja jo samana päivänä klo 12:44, alle 9 tuntia myöhemmin, lähetimme korjauksen Normandiaan. Kesti vielä 6–12 tuntia, ennen kuin se tavoitti kaikki käyttäjät. Ei ollenkaan paha, mutta ihmiset Twitterissä kysyvät, miksi emme olisi voineet toimia nopeammin.
Ensinnäkin uuden välitodistuksen myöntäminen kesti. Kuten edellä mainitsin, juurivarmenteen avain tallennetaan offline-tilaan laitteiston suojausmoduuliin. Tämä on hyvä turvallisuusnäkökulmasta, koska juuria käytetään erittäin harvoin ja se tulisi suojata luotettavasti, mutta se on hieman hankalaa, kun sinun on kiireesti allekirjoitettava uusi varmenne. Yksi insinööreistämme joutui matkustamaan HSM:n varastoon. Sitten oli epäonnistuneita yrityksiä antaa oikea varmenne, ja jokainen yritys maksoi tunnin tai kaksi testaukseen käytettyä tuntia.
Toiseksi järjestelmälisäosan kehittäminen kesti jonkin aikaa. Käsitteellisesti se on hyvin yksinkertainen, mutta yksinkertaisetkin ohjelmat vaativat huolellisuutta. Halusimme varmistaa, ettemme pahenta tilannetta. Tutkimus on testattava ennen kuin se lähetetään käyttäjille. Lisäksi lisäosa on allekirjoitettava, mutta lisäosan allekirjoitusjärjestelmämme oli poistettu käytöstä, joten meidän piti löytää ratkaisu.
Lopulta, kun tutkimus oli valmis toimitettaviksi, käyttöönotto vei aikaa. Selain tarkistaa Normandian päivitykset 6 tunnin välein. Kaikki tietokoneet eivät ole aina päällä ja yhteydessä Internetiin, joten kestää jonkin aikaa, ennen kuin korjaus leviää käyttäjille.
Viimeiset vaiheet
Tutkimuksen pitäisi korjata ongelma useimmille käyttäjille, mutta se ei ole kaikkien saatavilla. Jotkut käyttäjät vaativat erityistä lähestymistapaa:
- käyttäjät, jotka ovat poistaneet tutkimuksen tai telemetrian käytöstä
- Android-version (Fennec) käyttäjät, joiden tutkimusta ei tueta ollenkaan
- Firefox ESR:n mukautettujen koontiversioiden käyttäjät yrityksissä, joissa telemetriaa ei voi ottaa käyttöön
- käyttäjät istuvat MitM-välityspalvelinten takana, koska lisäosien asennusjärjestelmämme käyttää avainten kiinnitystä, mikä ei toimi tällaisten välityspalvelinten kanssa
- Firefoxin vanhojen versioiden käyttäjät, jotka eivät tue tutkimusta
Jälkimmäiselle käyttäjäryhmälle emme voi tehdä mitään – heidän pitäisi silti päivittää Firefoxin uuteen versioon, koska vanhentuneissa on vakavia korjaamattomia haavoittuvuuksia. Tiedämme, että jotkut ihmiset käyttävät vanhoja Firefox-versioita, koska he haluavat käyttää vanhoja lisäosia, mutta monet vanhoista lisäosista on jo siirretty uudempiin selaimen versioihin. Muita käyttäjiä varten olemme kehittäneet korjaustiedoston, joka asentaa uuden varmenteen. Se julkaistiin bugikorjauksena (kääntäjän huomautus: Firefox 66.0.5), joten ihmiset saavat sen - todennäköisesti jo saivat sen - tavallisen päivityskanavan kautta. Jos käytät mukautettua Firefox ESR:n koontiversiota, ota yhteyttä ylläpitäjään.
Ymmärrämme, että tämä ei ole ihanteellinen. Joissakin tapauksissa käyttäjät menettivät lisätiedot (esimerkiksi lisäosatiedot Usean tilin kontit).
Tätä sivuvaikutusta ei voitu välttää, mutta uskomme, että lyhyellä aikavälillä olemme valinneet parhaan ratkaisun useimmille käyttäjille. Pitkällä aikavälillä etsimme muita, edistyneempiä arkkitehtonisia lähestymistapoja.
Oppitunnit
Ensinnäkin tiimimme teki hämmästyttävää työtä luoden ja toimittaen korjauksen alle 12 tunnissa ongelman havaitsemisen jälkeen. Kokouksiin osallistuneena voin sanoa, että tässä vaikeassa tilanteessa ihmiset työskentelivät kovasti ja aikaa meni hukkaan hyvin vähän.
Ilmeisesti tämän ei olisi pitänyt tapahtua ollenkaan. On selvää, että prosessejamme kannattaa muuttaa tällaisten tapausten todennäköisyyden vähentämiseksi ja korjaamisen helpottamiseksi.
Ensi viikolla julkaisemme virallisen post mortemin ja listan muutoksista, joita aiomme tehdä. Toistaiseksi jaan ajatukseni. Ensinnäkin on oltava parempi tapa seurata mahdollisen aikapommin tilaa. Meidän on oltava varmoja, ettemme joudu tilanteeseen, jossa jokin niistä yhtäkkiä toimii. Selvitämme vielä yksityiskohtia, mutta ainakin kaikki tällaiset asiat on otettava huomioon.
Toiseksi tarvitsemme mekanismin, jolla päivitykset toimitetaan nopeasti käyttäjille, vaikka – varsinkin kun – kaikki muu epäonnistuu. Oli hienoa, että pystyimme käyttämään "tutkimusjärjestelmää", mutta se on epätäydellinen työkalu ja sillä on joitain ei-toivottuja sivuvaikutuksia. Tiedämme erityisesti, että monilla käyttäjillä on automaattiset päivitykset päällä, mutta he eivät haluaisi osallistua tutkimukseen (myönnän, minullakin on ne pois päältä!). Samaan aikaan tarvitsemme tavan lähettää päivityksiä käyttäjille, mutta sisäisestä teknisestä toteutuksesta riippumatta käyttäjien pitäisi voida tilata päivityksiä (mukaan lukien hot-fix-korjaukset), mutta kieltäytyä kaikesta muusta. Lisäksi päivityskanavan pitäisi olla reagoivampi kuin tällä hetkellä. Vielä 6. toukokuutakin oli käyttäjiä, jotka eivät hyödyntäneet korjausta tai uutta versiota. Tätä ongelmaa on jo käsitelty, mutta se, mitä tapahtui, osoitti, kuinka tärkeä se on.
Lopuksi tarkastelemme tarkemmin lisäosan suojausarkkitehtuuria varmistaaksemme, että se tarjoaa oikean suojatason minimaalisella rikkoutumisriskillä.
Ensi viikolla katsomme tapahtuneen perusteellisemman analyysin tuloksia, mutta sillä välin vastaan mielelläni kysymyksiin sähköpostitse: [sähköposti suojattu]
Lähde: linux.org.ru