Let wel vertaler: vir die gerief van lesers word datums in Moskou-tyd gegee
Ons het onlangs die verstryking van een van die sertifikate wat gebruik is om byvoegings te onderteken, gemis. Dit het daartoe gelei dat byvoegings vir gebruikers gedeaktiveer is. Noudat die probleem meestal reggestel is, wil ek graag die besonderhede deel van wat gebeur het en die werk wat gedoen is.
Agtergrond: byvoegings en handtekeninge
Geïnstalleerde byvoegings moet hê Digitale handtekening, wat gebruikers teen kwaadwillige byvoegings beskerm en minimale hersiening van byvoegings deur Mozilla-personeel vereis. Ons het hierdie vereiste in 2015 ingestel omdat ons ervaar het ernstige probleme met kwaadwillige byvoegings.
Hoe dit werk: Elke kopie van Firefox bevat 'n "wortelsertifikaat". Die sleutel tot hierdie "wortel" word in gestoor Hardeware sekuriteitsmodule (HSM)sonder netwerktoegang. Elke paar jaar word 'n nuwe "tussentydse sertifikaat" met hierdie sleutel onderteken, wat gebruik word wanneer byvoegings onderteken word. Wanneer 'n ontwikkelaar 'n byvoeging indien, skep ons 'n tydelike "eindsertifikaat" en onderteken dit met 'n tussentydse sertifikaat. Die byvoeging self word dan met die finale sertifikaat onderteken. Skematies dit lyk so.
Neem asseblief kennis dat elke sertifikaat 'n "onderwerp" (aan wie die sertifikaat uitgereik is) en 'n "uitreiker" (wat die sertifikaat uitgereik het) het. In die geval van 'n wortelsertifikaat, "onderwerp" = "uitreiker", maar vir ander sertifikate, is die uitreiker van die sertifikaat die onderwerp van die ouersertifikaat waarmee dit onderteken is.
'n Belangrike punt: elke byvoeging word deur 'n unieke eindsertifikaat onderteken, maar byna altyd word hierdie eindsertifikate deur dieselfde tussensertifikaat onderteken.
Skrywer se nota: Die uitsondering is baie ou toevoegings. Destyds is verskeie tussentydse sertifikate gebruik.
Hierdie intermediêre sertifikaat het probleme veroorsaak: elke sertifikaat is geldig vir 'n sekere tydperk. Voor of na hierdie tydperk is die sertifikaat ongeldig en die blaaier sal nie byvoegings gebruik wat deur hierdie sertifikaat onderteken is nie. Ongelukkig het die intermediêre sertifikaat op 4 Mei om 4 vm. verval.
Die gevolge het nie dadelik verskyn nie. Firefox gaan nie die handtekeninge van geïnstalleerde byvoegings voortdurend na nie, maar ongeveer een keer elke 24 uur, en die verifikasietyd is individueel vir elke gebruiker. Gevolglik het sommige mense dadelik probleme ondervind, terwyl ander heelwat later probleme ondervind het. Ons het eers omtrent die tyd wat die sertifikaat verval het van die probleem bewus geword en het dadelik na 'n oplossing begin soek.
Verminder skade
Sodra ons besef het wat gebeur het, het ons probeer keer dat die situasie vererger.
Eerstens het hulle opgehou om nuwe toevoegings te aanvaar en te onderteken. Dit is geen sin om 'n verval sertifikaat hiervoor te gebruik nie. As ek terugdink, sou ek sê dat ons alles kon gelos het soos dit was. Ons het nou weer aanvullings aanvaar.
Tweedens het hulle dadelik 'n regstelling uitgestuur wat verhoed het dat handtekeninge daagliks nagegaan word. Ons het dus daardie gebruikers gered wie se blaaier nog nie tyd gehad het om die byvoegings in die afgelope XNUMX uur na te gaan nie. Hierdie regstelling is nou teruggetrek en is nie meer nodig nie.
Parallelle werking
In teorie lyk die oplossing vir die probleem eenvoudig: skep 'n nuwe geldige tussentydse sertifikaat en teken elke byvoeging weer. Ongelukkig sal dit nie werk nie:
- ons kan nie vinnig 15 duisend byvoegings op een slag herteken nie, die stelsel is nie ontwerp vir so 'n las nie
- Nadat ons die byvoegings onderteken het, moet die opgedateerde weergawes aan gebruikers gelewer word. Die meeste byvoegings word vanaf Mozilla-bedieners geïnstalleer, so Firefox sal opdaterings binne die volgende XNUMX uur vind, maar sommige ontwikkelaars versprei getekende byvoegings deur derdeparty-kanale, so gebruikers sal sulke byvoegings handmatig moet opdateer
In plaas daarvan het ons probeer om 'n oplossing te ontwikkel wat alle gebruikers sal bereik sonder om veel of geen aksie van hul kant te vereis nie.
Ons het redelik vinnig by twee hoofstrategieë uitgekom wat ons parallel gebruik het:
- Dateer Firefox op om die sertifikaatgeldigheidstydperk te verander. Dit sal bestaande byvoegings weer magies laat werk, maar sal vereis dat 'n nuwe weergawe van Firefox vrygestel en gestuur word
- Genereer 'n geldige sertifikaat en oortuig Firefox op een of ander manier om dit te aanvaar in plaas van die bestaande een wat verval het
Ons het besluit om eers die eerste opsie te gebruik, wat redelik werkbaar gelyk het. Aan die einde van die dag het hulle 'n tweede regstelling vrygestel ('n nuwe sertifikaat), waaroor ons later sal praat.
Vervanging van 'n sertifikaat
Soos ek hierbo genoem het, was dit vereis:
- skep 'n nuwe geldige sertifikaat
- installeer dit op afstand in Firefox
Om te verstaan hoekom dit werk, kom ons kyk na die byvoegingsverifikasieproses van naderby. Die byvoeging self kom as 'n stel lêers, insluitend 'n ketting sertifikate wat vir ondertekening gebruik word. Gevolglik kan die byvoeging geverifieer word as die blaaier die wortelsertifikaat ken, wat tydens boutyd in Firefox ingebou is. Soos ons reeds weet, het die tussentydse sertifikaat egter verval, so dit is onmoontlik om die byvoeging te verifieer.
Wanneer Firefox probeer om 'n byvoeging te verifieer, is dit nie beperk tot die gebruik van die sertifikate wat in die byvoeging self vervat is nie. In plaas daarvan probeer die blaaier om 'n geldige sertifikaatketting te skep, begin met die eindsertifikaat en gaan voort totdat dit by die wortel kom. Op die eerste vlak begin ons met die eindsertifikaat en vind dan die sertifikaat waarvan die onderwerp die uitreiker van die eindsertifikaat is (dit is die tussensertifikaat). Tipies word hierdie intermediêre sertifikaat saam met die byvoeging voorsien, maar enige sertifikaat van die blaaier se berging kan ook as hierdie intermediêre sertifikaat dien. As ons op 'n afstand 'n nuwe geldige sertifikaat by die sertifikaatwinkel kan voeg, sal Firefox probeer om dit te gebruik. Die situasie voor en na die installering van 'n nuwe sertifikaat.
Nadat die nuwe sertifikaat geïnstalleer is, sal Firefox twee opsies hê wanneer die sertifikaatketting bekragtig word: gebruik die ou ongeldige sertifikaat (wat nie sal werk nie) of die nuwe geldige sertifikaat (wat sal werk). Dit is belangrik dat die nuwe sertifikaat dieselfde vaknaam en publieke sleutel as die ou sertifikaat bevat, sodat die handtekening daarvan op die finale sertifikaat geldig sal wees. Firefox is slim genoeg om albei opsies te probeer totdat dit een vind wat werk, sodat die byvoegings weer getoets word. Let daarop dat dit dieselfde logika is wat ons gebruik om TLS-sertifikate te valideer.
Skrywer se nota: Lesers wat vertroud is met WebPKI sal daarop let dat kruissertifikate op presies dieselfde manier werk.
Die wonderlike ding van hierdie oplossing is dat dit nie vereis dat u bestaande byvoegings herteken nie. Sodra die blaaier die nuwe sertifikaat ontvang, sal alle byvoegings weer werk. Daar bly die uitdaging om die nuwe sertifikaat aan gebruikers te lewer (outomaties en op afstand) en ook om Firefox te kry om gedeaktiveerde byvoegings weer na te gaan.
Normandië en die navorsingstelsel
Ironies genoeg word hierdie probleem opgelos deur 'n spesiale byvoeging genaamd "stelsel". Om navorsing te doen, het ons 'n stelsel genaamd Normandië ontwikkel wat navorsing aan gebruikers lewer. Hierdie studies word outomaties in die blaaier uitgevoer en het verbeterde toegang tot Firefox se interne API's. Navorsing kan nuwe sertifikate by die sertifikaatwinkel voeg.
Skrywer se nota: Ons voeg nie 'n sertifikaat met enige spesiale voorregte by nie; dit word deur die wortelsertifikaat onderteken, so Firefox vertrou dit. Ons voeg dit eenvoudig by die poel sertifikate wat deur die blaaier gebruik kan word.
Die oplossing is dus om 'n studie te skep:
- die installering van die nuwe sertifikaat wat ons vir gebruikers geskep het
- wat die blaaier dwing om gedeaktiveerde byvoegings weer na te gaan sodat hulle weer werk
"Maar wag," sê jy, "byvoegings werk nie, hoe kan ek 'n stelselbyvoeging begin?" Kom ons teken dit met 'n nuwe sertifikaat!
Om alles bymekaar te sit... hoekom vat dit so lank?
Dus, die plan: reik 'n nuwe sertifikaat uit om die ou een te vervang, skep 'n stelselbyvoeging en installeer dit vir gebruikers via Normandië. Die probleme het, soos ek gesê het, op 4 Mei om 4:00 begin, en reeds om 12:44 van dieselfde dag, minder as 9 uur later, het ons 'n fix na Normandië gestuur. Dit het nog 6-12 uur geneem om alle gebruikers te bereik. Glad nie sleg nie, maar mense op Twitter vra hoekom ons nie vinniger kon opgetree het nie.
Eerstens het dit tyd geneem om 'n nuwe tussentydse sertifikaat uit te reik. Soos ek hierbo genoem het, word die sleutel tot die wortelsertifikaat vanlyn in die hardeware-sekuriteitsmodule gestoor. Dit is goed uit 'n sekuriteitsoogpunt, aangesien die wortel baie selde gebruik word en betroubaar beskerm moet word, maar dit is effens ongerieflik wanneer jy dringend 'n nuwe sertifikaat moet onderteken. Een van ons ingenieurs moes na die HSM-bergingsfasiliteit reis. Toe was daar onsuksesvolle pogings om die korrekte sertifikaat uit te reik, en elke poging het een of twee uur gekos om te toets.
Tweedens het die ontwikkeling van die stelselbyvoeging 'n geruime tyd geneem. Konseptueel is dit baie eenvoudig, maar selfs eenvoudige programme verg sorg. Ons wou seker maak dat ons nie die situasie vererger nie. Navorsing moet getoets word voordat dit aan gebruikers gestuur word. Boonop moet die byvoeging onderteken word, maar ons byvoegingstekenstelsel was gedeaktiveer, so ons moes 'n oplossing vind.
Uiteindelik, sodra ons die navorsing gereed gehad het vir indiening, het ontplooiing tyd geneem. Die blaaier kyk elke 6 uur vir Normandië-opdaterings. Nie alle rekenaars is altyd aan en aan die internet gekoppel nie, so dit sal tyd neem vir die regstelling om na gebruikers te versprei.
Finale stappe
Die navorsing behoort die probleem vir die meeste gebruikers reg te stel, maar is nie vir almal beskikbaar nie. Sommige gebruikers benodig 'n spesiale benadering:
- gebruikers wat navorsing of telemetrie gedeaktiveer het
- gebruikers van die Android-weergawe (Fennec), waar navorsing glad nie ondersteun word nie
- gebruikers van pasgemaakte weergawes van Firefox ESR in ondernemings waar telemetrie nie geaktiveer kan word nie
- gebruikers wat agter MitM gevolmagtigdes sit, aangesien ons byvoegingsinstallasiestelsel sleutelvaspen gebruik, wat nie met sulke gevolmagtigdes werk nie
- gebruikers van verouderde weergawes van Firefox wat nie navorsing ondersteun nie
Ons kan niks aan laasgenoemde kategorie gebruikers doen nie – hulle moet steeds opdateer na die nuwe weergawe van Firefox, want verouderde weergawes het ernstige ongelapte kwesbaarhede. Ons weet dat sommige mense op ouer weergawes van Firefox bly omdat hulle ou byvoegings wil laat loop, maar baie van die ou byvoegings is reeds na nuwer weergawes van die blaaier oorgedra. Vir ander gebruikers het ons 'n pleister ontwikkel wat 'n nuwe sertifikaat sal installeer. Dit is vrygestel as 'n bugfix-vrystelling (vertaler se nota: Firefox 66.0.5), sodat mense dit sal kry - heel waarskynlik reeds gekry - deur die gereelde opdateringskanaal. As jy 'n pasgemaakte weergawe van Firefox ESR gebruik, kontak asseblief jou onderhouer.
Ons verstaan dat dit nie ideaal is nie. In sommige gevalle het gebruikers byvoegingsdata verloor (byvoorbeeld byvoegingsdata Multirekeninghouers).
Hierdie newe-effek kon nie vermy word nie, maar ons glo dat ons op kort termyn die beste oplossing vir die meeste gebruikers gekies het. Op lang termyn sal ons ander, meer gevorderde argitektoniese benaderings soek.
Die lesse
Eerstens het ons span ongelooflike werk gedoen om 'n oplossing te skep en te stuur binne minder as 12 uur nadat die probleem ontdek is. As iemand wat die vergaderings bygewoon het, kan ek sê dat in hierdie moeilike situasie mense baie hard gewerk het en baie min tyd is gemors.
Uiteraard moes niks hiervan enigsins gebeur het nie. Dit is duidelik die moeite werd om ons prosesse aan te pas om die waarskynlikheid van sulke voorvalle te verminder en remediëring makliker te maak.
Volgende week publiseer ons 'n amptelike nadoodse ondersoek en 'n lys van veranderinge wat ons beoog om aan te bring. Vir eers deel ek my gedagtes. Eerstens moet daar 'n beter manier wees om die status te monitor van wat 'n potensiële tydbom is. Ons moet seker wees dat ons onsself nie in 'n situasie bevind waar een van hulle skielik werk nie. Ons werk nog die besonderhede uit, maar dit is ten minste nodig om al sulke dinge in ag te neem.
Tweedens het ons 'n meganisme nodig om vinnig opdaterings aan gebruikers te lewer, selfs wanneer - veral wanneer - alles anders misluk. Dit was wonderlik dat ons die "navorsing"-stelsel kon gebruik, maar dit is 'n onvolmaakte hulpmiddel en het 'n paar ongewenste newe-effekte. Ons weet veral dat baie gebruikers outomatiese opdaterings aangeskakel het, maar verkies om nie aan navorsing deel te neem nie (ek gee toe, ek het dit ook afgeskakel!). Terselfdertyd het ons 'n manier nodig om opdaterings aan gebruikers te stuur, maar wat ook al die interne tegniese implementering, gebruikers moet kan inteken op opdaterings (insluitend hot fixes) maar onttrek van alles anders. Daarbenewens moet die opdateringskanaal meer reageer as wat dit nou is. Selfs op 6 Mei was daar steeds gebruikers wat nie voordeel getrek het uit die oplossing of die nuwe weergawe nie. Daar is reeds aan hierdie probleem gewerk, maar wat gebeur het, het gewys hoe belangrik dit is.
Ten slotte, ons sal die byvoeging se sekuriteitsargitektuur van nader bekyk om seker te maak dat dit die regte vlak van sekuriteit bied met minimale risiko om enigiets te breek.
Volgende week sal ons kyk na die resultate van 'n meer deeglike ontleding van wat gebeur het, maar intussen sal ek graag vrae per e-pos beantwoord: [e-pos beskerm]
Bron: linux.org.ru