Notă traducător: pentru comoditatea cititorilor, datele sunt date în ora Moscovei
Am ratat recent expirarea unuia dintre certificatele folosite pentru a semna suplimente. Acest lucru a dus la dezactivarea suplimentelor pentru utilizatori. Acum că problema a fost rezolvată în mare parte, aș dori să vă împărtășesc detaliile despre ceea ce s-a întâmplat și despre munca care a fost făcută.
Context: completări și semnături
Suplimentele instalate trebuie să aibă semnatura digitala, care protejează utilizatorii de suplimentele rău intenționate și necesită o revizuire minimă a suplimentelor de către personalul Mozilla. Am introdus această cerință în 2015 pentru că ne confruntam probleme serioase cu suplimente rău intenționate.
Cum funcționează: Fiecare copie a Firefox conține un „certificat rădăcină”. Cheia acestei „rădăcini” este stocată în Modul de securitate hardware (HSM)fără acces la rețea. La fiecare câțiva ani, un nou „certificat intermediar” este semnat cu această cheie, care este utilizată la semnarea suplimentelor. Când un dezvoltator trimite un supliment, creăm un „certificat de final” temporar și îl semnăm folosind un certificat intermediar. Suplimentul în sine este apoi semnat cu certificatul final. Schematic arata asa.
Vă rugăm să rețineți că fiecare certificat are un „subiect” (căruia i-a fost eliberat certificatul) și un „emitent” (care a emis certificatul). În cazul unui certificat rădăcină, „subiect” = „emitent”, dar pentru alte certificate, emitentul certificatului este subiectul certificatului părinte prin care acesta este semnat.
Un punct important: fiecare add-on este semnat de un certificat final unic, dar aproape întotdeauna aceste certificate finale sunt semnate de același certificat intermediar.
Nota autorului: Excepția sunt completările foarte vechi. La acea vreme se foloseau diverse certificate intermediare.
Acest certificat intermediar a cauzat probleme: fiecare certificat este valabil pentru o anumită perioadă. Înainte sau după această perioadă, certificatul este invalid și browserul nu va folosi suplimente semnate de acest certificat. Din păcate, certificatul intermediar a expirat pe 4 mai la ora 4 dimineața.
Consecințele nu au apărut imediat. Firefox nu verifică constant semnăturile suplimentelor instalate, ci aproximativ o dată la 24 de ore, iar timpul de verificare este individual pentru fiecare utilizator. Drept urmare, unii oameni au avut probleme imediat, în timp ce alții au avut probleme mult mai târziu. Am aflat mai întâi problema în jurul datei de expirare a certificatului și am început imediat să căutăm o soluție.
Reducerea daunelor
Odată ce ne-am dat seama ce s-a întâmplat, am încercat să împiedicăm situația să se înrăutățească.
În primul rând, au încetat să accepte și să semneze noi completări. Nu are rost să folosiți un certificat expirat pentru asta. Privind în urmă, aș spune că am fi putut lăsa totul așa cum era. Acum am reluat acceptarea suplimentelor.
În al doilea rând, au trimis imediat o remediere care a împiedicat verificarea zilnică a semnăturilor. Astfel, am salvat acei utilizatori al căror browser nu avusese încă timp să verifice suplimentele în ultimele XNUMX de ore. Această remediere a fost acum retrasă și nu mai este necesară.
Funcționare în paralel
În teorie, soluția la problemă pare simplă: creați un nou certificat intermediar valid și resemnați fiecare supliment. Din păcate, acest lucru nu va funcționa:
- nu putem resemna rapid 15 mii de suplimente deodată, sistemul nu este proiectat pentru o astfel de încărcare
- După ce semnăm completările, versiunile actualizate trebuie să fie livrate utilizatorilor. Majoritatea suplimentelor sunt instalate de pe serverele Mozilla, așa că Firefox va găsi actualizări în următoarele XNUMX de ore, dar unii dezvoltatori distribuie suplimente semnate prin canale terțe, astfel încât utilizatorii ar trebui să actualizeze astfel de suplimente manual.
În schimb, am încercat să dezvoltăm o soluție care să ajungă la toți utilizatorii fără a necesita prea multe sau nicio acțiune din partea lor.
Destul de repede am ajuns la două strategii principale, pe care le-am folosit în paralel:
- Actualizați Firefox pentru a modifica perioada de valabilitate a certificatului. Acest lucru va face ca suplimentele existente să funcționeze din nou în mod magic, dar va necesita lansarea și livrarea unei noi versiuni a Firefox
- Generați un certificat valid și convingeți cumva Firefox să-l accepte în locul celui existent care a expirat
Am decis să folosim prima opțiune, care părea destul de funcțională. La sfârșitul zilei, au lansat o a doua remediere (un nou certificat), despre care vom vorbi mai târziu.
Înlocuirea unui certificat
După cum am menționat mai sus, era necesar:
- creați un nou certificat valabil
- instalați-l de la distanță în Firefox
Pentru a înțelege de ce funcționează, haideți să aruncăm o privire mai atentă asupra procesului de verificare a suplimentului. Suplimentul în sine vine ca un set de fișiere, inclusiv un lanț de certificate utilizate pentru semnare. Ca rezultat, suplimentul poate fi verificat dacă browserul cunoaște certificatul rădăcină, care este încorporat în Firefox la momentul construirii. Cu toate acestea, după cum știm deja, certificatul intermediar a expirat, așa că este imposibil să verificați add-on-ul.
Când Firefox încearcă să verifice un program de completare, acesta nu se limitează la utilizarea certificatelor conținute în suplimentul în sine. În schimb, browserul încearcă să creeze un lanț de certificate valid, începând cu certificatul final și continuând până când ajunge la rădăcină. La primul nivel, începem cu certificatul final și apoi găsim certificatul al cărui subiect este emitentul certificatului final (adică certificatul intermediar). De obicei, acest certificat intermediar este furnizat împreună cu suplimentul, dar orice certificat din stocarea browserului poate servi și ca acest certificat intermediar. Dacă putem adăuga de la distanță un nou certificat valid în depozitul de certificate, Firefox va încerca să-l folosească. Situația înainte și după instalarea unui nou certificat.
După instalarea noului certificat, Firefox va avea două opțiuni la validarea lanțului de certificate: utilizați vechiul certificat invalid (care nu va funcționa) sau noul certificat valabil (care va funcționa). Este important ca noul certificat să conțină același nume de subiect și cheie publică ca și certificatul vechi, astfel încât semnătura sa de pe certificatul final va fi valabilă. Firefox este suficient de inteligent pentru a încerca ambele opțiuni până când găsește una care funcționează, așa că suplimentele sunt testate din nou. Rețineți că aceasta este aceeași logică pe care o folosim pentru a valida certificatele TLS.
Nota autorului: Cititorii familiarizați cu WebPKI vor observa că certificatele încrucișate funcționează exact în același mod.
Lucrul grozav despre această remediere este că nu necesită să resemnați suplimentele existente. De îndată ce browserul primește noul certificat, toate suplimentele vor funcționa din nou. Provocarea rămasă este să livreze noul certificat utilizatorilor (automat și de la distanță), precum și să convingă Firefox să verifice din nou suplimentele dezactivate.
Normandia și sistemul de cercetare
În mod ironic, această problemă este rezolvată printr-un add-on special numit „sistem”. Pentru a efectua cercetări, am dezvoltat un sistem numit Normandia care oferă cercetări utilizatorilor. Aceste studii sunt efectuate automat în browser și au acces îmbunătățit la API-urile interne ale Firefox. Research poate adăuga certificate noi în depozitul de certificate.
Nota autorului: Nu adăugăm un certificat cu privilegii speciale; este semnat de certificatul rădăcină, așa că Firefox are încredere în el. Pur și simplu îl adăugăm la pool-ul de certificate care pot fi folosite de browser.
Deci soluția este crearea unui studiu:
- instalarea noului certificat pe care l-am creat pentru utilizatori
- forțând browserul să verifice din nou suplimentele dezactivate, astfel încât acestea să funcționeze din nou
„Dar stai”, spui tu, „suplimentele nu funcționează, cum pot lansa un supliment de sistem?” Să-l semnăm cu un nou certificat!
Punând totul cap la cap... de ce durează atât de mult?
Deci, planul: emiteți un nou certificat pentru a-l înlocui pe cel vechi, creați un add-on de sistem și instalați-l utilizatorilor prin Normandia. Problemele, așa cum am spus, au început pe 4 mai la 4:00 și deja la 12:44 din aceeași zi, mai puțin de 9 ore mai târziu, am trimis o remediere în Normandia. A durat încă 6-12 ore pentru ca acesta să ajungă la toți utilizatorii. Nu e rău deloc, dar oamenii de pe Twitter se întreabă de ce nu am fi putut acționa mai repede.
În primul rând, a durat timp pentru a elibera un nou certificat intermediar. După cum am menționat mai sus, cheia certificatului rădăcină este stocată offline în modulul de securitate hardware. Acest lucru este bun din punct de vedere al securității, deoarece rădăcina este folosită foarte rar și ar trebui protejată în mod fiabil, dar este ușor incomod atunci când trebuie să semnați urgent un nou certificat. Unul dintre inginerii noștri a trebuit să călătorească la depozitul HSM. Apoi au existat încercări nereușite de a elibera certificatul corect și fiecare încercare a costat una sau două ore petrecute testând.
În al doilea rând, dezvoltarea suplimentului de sistem a durat ceva timp. Conceptual este foarte simplu, dar chiar și programele simple necesită îngrijire. Am vrut să ne asigurăm că nu am înrăutățit situația. Cercetarea trebuie testată înainte de a fi trimisă utilizatorilor. În plus, suplimentul trebuie să fie semnat, dar sistemul nostru de semnare a suplimentului a fost dezactivat, așa că a trebuit să găsim o soluție.
În cele din urmă, odată ce am avut cercetarea pregătită pentru depunere, implementarea a durat. Browserul verifică actualizările Normandiei la fiecare 6 ore. Nu toate computerele sunt întotdeauna pornite și conectate la Internet, așa că va dura timp pentru ca remedierea să se răspândească la utilizatori.
Pasi finali
Cercetarea ar trebui să rezolve problema pentru majoritatea utilizatorilor, dar nu este disponibilă pentru toată lumea. Unii utilizatori necesită o abordare specială:
- utilizatorii care au dezactivat cercetarea sau telemetria
- utilizatorii versiunii Android (Fennec), unde cercetarea nu este acceptată deloc
- utilizatorii de versiuni personalizate ale Firefox ESR în întreprinderi în care telemetria nu poate fi activată
- utilizatorii care stau în spatele proxy-urilor MitM, deoarece sistemul nostru de instalare suplimentar folosește fixarea cheilor, care nu funcționează cu astfel de proxy
- utilizatorii versiunilor vechi de Firefox care nu acceptă cercetarea
Nu putem face nimic în privința acestei din urmă categorii de utilizatori - ar trebui să se actualizeze totuși la noua versiune de Firefox, deoarece cei învechiți au vulnerabilități serioase necorecte. Știm că unii oameni rămân pe versiuni mai vechi de Firefox pentru că doresc să ruleze suplimente vechi, dar multe dintre suplimentele vechi au fost deja portate la versiuni mai noi ale browserului. Pentru alți utilizatori, am dezvoltat un patch care va instala un nou certificat. A fost lansat ca lansare de remediere a erorilor (nota traducătorului: Firefox 66.0.5), astfel încât oamenii îl vor obține - cel mai probabil l-au primit deja - prin canalul obișnuit de actualizare. Dacă utilizați o versiune personalizată a Firefox ESR, vă rugăm să vă contactați întreținătorul.
Înțelegem că acest lucru nu este ideal. În unele cazuri, utilizatorii au pierdut date de supliment (de exemplu, date de supliment Containere cu mai multe conturi).
Acest efect secundar nu a putut fi evitat, dar credem că pe termen scurt am ales cea mai bună soluție pentru majoritatea utilizatorilor. Pe termen lung, vom căuta și alte abordări arhitecturale, mai avansate.
Lecțiile
În primul rând, echipa noastră a făcut o treabă uimitoare creând și expediând o remediere în mai puțin de 12 ore după ce problema a fost descoperită. Ca cineva care a participat la întâlniri, pot spune că în această situație dificilă oamenii au muncit foarte mult și s-a pierdut foarte puțin timp.
Evident, nimic din toate acestea nu ar fi trebuit să se întâmple. În mod clar, merită să ne adaptăm procesele pentru a reduce probabilitatea unor astfel de incidente și pentru a face remedierea mai ușoară.
Săptămâna viitoare vom publica un post-mortem oficial și o listă cu modificările pe care intenționăm să le facem. Deocamdată, îmi voi împărtăși gândurile. În primul rând, trebuie să existe o modalitate mai bună de a monitoriza starea a ceea ce este o potențială bombă cu ceas. Trebuie să fim siguri că nu ne aflăm într-o situație în care unul dintre ei funcționează brusc. Încă elaborăm detaliile, dar, cel puțin, este necesar să luăm în considerare toate astfel de lucruri.
În al doilea rând, avem nevoie de un mecanism care să furnizeze rapid actualizări utilizatorilor, chiar și atunci când — mai ales atunci când — totul eșuează. A fost grozav că am putut folosi sistemul de „cercetare”, dar este un instrument imperfect și are unele efecte secundare nedorite. În special, știm că mulți utilizatori au actualizările automate activate, dar ar prefera să nu participe la cercetare (recunosc, le am și dezactivate!). În același timp, avem nevoie de o modalitate de a trimite actualizări utilizatorilor, dar indiferent de implementarea tehnică internă, utilizatorii ar trebui să se poată abona la actualizări (inclusiv remedieri fierbinți), dar să renunțe la orice altceva. În plus, canalul de actualizare ar trebui să fie mai receptiv decât este acum. Chiar și pe 6 mai au existat totuși utilizatori care nu au profitat nici de remediere, nici de noua versiune. S-a lucrat deja la această problemă, dar ceea ce s-a întâmplat a arătat cât de importantă este.
În cele din urmă, vom arunca o privire mai atentă asupra arhitecturii de securitate a suplimentului pentru a ne asigura că oferă nivelul potrivit de securitate cu risc minim de a sparge ceva.
Săptămâna viitoare ne vom uita la rezultatele unei analize mai amănunțite a ceea ce s-a întâmplat, dar între timp voi fi bucuros să răspund la întrebări prin e-mail: [e-mail protejat]
Sursa: linux.org.ru