Nota translatorului: pentru comoditatea cititorilor, datele sunt prezentate pe ora Moscovei
Recent, am ratat momentul expirării uneia dintre certificările utilizate pentru semnarea extensiilor. Acest lucru a dus la dezactivarea extensiilor pentru utilizatori. Acum, când problema a fost în mare parte remediată, aș dori să vorbesc despre detaliile întâmplate și despre munca depusă.
Subiect: extensii și semnături
Extensiile instalate trebuie să aibă semnătură digitală, care protejează utilizatorii de extensiile dăunătoare, și necesită o verificare minimă a extensiilor din partea angajaților Mozilla. Am introdus această cerință în 2015, deoarece ne confruntam cu probleme serioase cu extensiile dăunătoare.
Cum funcționează: fiecare copie de Firefox conține un 'certificat rădăcină'. Cheia acestui 'rădăcină' este stocată în un modul de securitate hardware (HSM), care nu are acces la rețea. La fiecare câțiva ani, această cheie semnează un nou 'certificat intermediar', care este folosit la semnarea extensiilor. Atunci când un dezvoltator trimite o extensie, creăm un 'certificat final' temporar și îl semnăm folosind certificatul intermediar. Apoi, extensia este semnată cu certificatul final. Schema arată astfel.
Rețineți: fiecare certificat are un 'subiect' (cine a primit certificatul) și un 'emis' (cine a emis certificatul). În cazul certificatului rădăcină, 'subiect' = 'emis', dar pentru alte certificate, emițătorul certificatului este subiectul certificatului superior care l-a semnat.
Un aspect important: fiecare extensie este semnată cu un certificat final unic, dar aproape întotdeauna aceste certificate finale sunt semnate de același certificat intermediar.
Nota autorului: excepție fac extensiile foarte vechi. La acea vreme, erau utilizate diferite certificate intermediare.
Acest certificat intermediar a generat probleme: fiecare certificat este valabil pentru o anumită perioadă. Înainte sau după această perioadă, certificatul devine invalid și browserul nu va utiliza extensiile semnate cu acest certificat. Din păcate, termenul de valabilitate al certificatului intermediar a expirat pe 4 mai la ora 4 dimineața.
Consecințele nu s-au manifestat imediat. Firefox verifică semnăturile extensiilor instalate nu constant, ci aproximativ la fiecare 24 de ore, timpul de verificare fiind individual pentru fiecare utilizator. Ca urmare, unii utilizatori au avut probleme imediat, iar alții mult mai târziu. Am aflat pentru prima dată despre problemă aproximativ în momentul în care a expirat termenul de valabilitate al certificatului și am început imediat să căutăm o soluție.
Reducem daunele
Odată ce am înțeles ce s-a întâmplat, am încercat să nu lăsăm situația să se degradeze.
În primul rând, am încetat să acceptăm și să semnăm extensii noi. Nu are sens să folosim un certificat expirat pentru asta. Privind în urmă, aș spune că am fi putut lăsa totul așa cum era. În prezent, acceptarea extensiilor a fost reluată.
În al doilea rând, am trimis imediat o corectare care a împiedicat verificarea zilnică a semnăturilor. Astfel, am salvat utilizatorii care nu avuseseră timp să verifice extensiile în ultimele 24 de ore. Acum, această corectare a fost retrasă, deoarece nu mai este nevoie de ea.
Lucrări paralele
Teoretic, soluția problemei pare simplă: creăm un nou certificat intermediar valid și semnăm din nou fiecare extensie. Din păcate, aceasta nu va funcționa:
- nu putem semna rapid 15.000 de extensii simultan, sistemul nu este conceput pentru o astfel de încărcătură
- după ce semnăm extensiile, versiunile actualizate trebuie livrate utilizatorilor. Majoritatea extensiilor sunt instalate de pe serverele Mozilla, așa că în următoarele 24 de ore Firefox va găsi actualizări, dar unii dezvoltatori distribuie extensii semnate prin canale externe, deci utilizatorii ar trebui să actualizeze manual aceste extensii.
În loc de aceasta, am încercat să dezvoltăm o corectare care să ajungă la toți utilizatorii, fără a necesita (sau aproape fără a necesita) acțiuni din partea acestora.
Am ajuns destul de repede la două strategii principale, pe care le-am folosit în paralel:
- Actualizează Firefox pentru a schimba perioada de valabilitate a certificatului. Acest lucru va face ca extensiile existente să funcționeze din nou, dar va necesita eliberarea și livrarea unei noi versiuni de Firefox.
- Creează un certificat valid și convinge cumva Firefox să-l accepte în locul celui existent, al cărui termen de valabilitate a expirat.
Am decis să folosim mai întâi prima opțiune, care părea destul de funcțională. La sfârșitul zilei, am eliberat și a doua corectare (certificat nou), despre care vom vorbi mai departe.
Înlocuirea certificatului
Așa cum am menționat mai sus, a fost necesar să:
- creăm un nou certificat valid
- să-l instalăm la distanță în Firefox
Pentru a înțelege de ce funcționează asta, să analizăm mai în detaliu procesul de verificare a extensiilor. Extensia este livrată sub formă de set de fișiere, inclusiv lanțul de certificate folosit pentru semnare. Drept urmare, extensia poate fi verificată dacă browserul cunoaște certificatul rădăcină, care este încorporat în Firefox în timpul construirii. Totuși, așa cum știm deja, certificatul intermediar este expirat, așa că extensia nu poate fi verificată.
Când Firefox încearcă să verifice extensia, nu se limitează la utilizarea certificatelor conținute în extensia însăși. În schimb, browserul încearcă să creeze un lanț valid de certificate, începând cu certificatul final și continuând până ajunge la rădăcină. La primul nivel începem cu certificatul final, apoi găsim certificatul al cărui subiect este editorul certificatului final (adică, certificatul intermediar). De obicei, acest certificat intermediar este livrat împreună cu extensia, dar oricare certificat din depozitul browserului poate să îndeplinească și această funcție. Dacă putem adăuga la distanță un nou certificat valid în depozitul de certificate, Firefox va încerca să-l folosească. Situația înainte și după instalarea noului certificat.
După instalarea unui nou certificat, Firefox va avea două opțiuni la verificarea lanțului de certificare: să folosească vechiul certificat invalid (care nu va funcționa) sau noul certificat valid (care va funcționa). Este important ca noul certificat să conțină același nume al subiectului și aceeași cheie publică ca și vechiul certificat, astfel încât semnătura sa pe certificat să fie validă. Firefox este suficient de inteligent pentru a încerca ambele opțiuni până găsește una funcțională, astfel încât extensiile vor deveni din nou verificate. Rețineți, aceasta este aceeași logică pe care o folosim pentru a verifica certificatele TLS.
Notă a autorului: cititorii familiarizați cu WebPKI vor observa că certificarile încrucișate funcționează exact la fel.
Ceea ce este remarcabil în această corectare este că nu necesită resemnarea extensiilor existente. Odată ce browserul primește noul certificat, toate extensiile vor funcționa din nou. Rămâne complexitatea de a livra noul certificat utilizatorilor (automatic și de la distanță), precum și de a determina Firefox să revizuiască extensiile dezactivate.
Normandy și sistemul de cercetare
Din ironie, această problemă este rezolvată de o extensie specială numită „sistemică”. Pentru a desfășura cercetări, am dezvoltat un sistem numit Normandy, care livrează sondaje utilizatorilor. Aceste sondaje sunt executate automat în browser și au acces extins la API-urile interioare ale Firefox. Sondajele pot adăuga noi certificate în magazinul de certificate.
Notă a autorului: nu adăugăm un certificat cu privilegii speciale; este semnat de un certificat rădăcină, de aceea Firefox are încredere în el. Pur și simplu, îl adăugăm în pool-ul de certificate care pot fi utilizate de browser.
Astfel, soluția constă în a crea un sondaj:
- care instalează utilizatorilor noul certificat creat de noi
- care forțează browserul să revizuiască extensiile dezactivate, pentru a funcționa din nou
„Dar așteaptă”, veți spune, „extensiile nu funcționează, cum să lansez o extensie sistemică?”. O vom semna cu noul certificat!
Să adunăm totul împreună… de ce a durat atât de mult?
Așadar, planul este: să lansăm un nou certificat pentru a înlocui pe cel vechi, să creăm un addon de sistem și să-l instalăm utilizatorilor prin Normandy. Problemele, așa cum am menționat, au început pe 4 mai la ora 4:00, iar deja la 12:44 în aceeași zi, în mai puțin de 9 ore, am trimis o soluție în Normandy. A mai durat între 6 și 12 ore ca aceasta să ajungă la toți utilizatorii. Este un început bun, dar utilizatorii de pe Twitter întreabă de ce nu am putut acționa mai repede.
În primul rând, a fost nevoie de timp pentru a emite un nou certificat intermediar. Așa cum am menționat anterior, cheia certificatului rădăcină este stocată în mod autonom în module hardware de securitate. Acest lucru este bine din punct de vedere al securității, deoarece rădăcina este utilizată foarte rar și trebuie să fie protejată corespunzător, dar este puțin inconfortabil atunci când trebuie să semnăm de urgență un nou certificat. Unul dintre inginerii noștri a trebuit să meargă la magazinul HSM. Apoi au existat încercări nereușite de a emite certificatul corect, fiecare încercare costând una sau două ore dedicate testării.
În al doilea rând, dezvoltarea addonului de sistem a durat ceva timp. Conceptual, este foarte simplu, dar chiar și programele simple necesită atenție. Am dorit să ne asigurăm că nu vom face situația și mai dificilă. Studiul trebuie testat înainte de a fi trimis utilizatorilor. În plus, addonul trebuie să fie semnat, dar sistemul nostru de semnare a addonurilor era oprit, trebuind să căutăm o soluție alternativă.
În cele din urmă, după ce am pregătit studiul pentru trimitere, a fost nevoie de timp pentru desfășurare. Browserul verifică actualizările Normandy la fiecare 6 ore. Nu toate computerele sunt mereu pornite și conectate la internet, așa că este nevoie de timp pentru ca soluția să se răspândească printre utilizatori.
Pașii finali
Studiul ar trebui să rezolve problema majorității utilizatorilor, dar nu este disponibil pentru toți. Uneori, este necesară o abordare specială pentru anumite categorii de utilizatori:
- utilizatorii care au dezactivat studiile sau telemetria
- utilizatorii versiunii Android (Fennec), unde studiile nu sunt deloc acceptate
- utilizatorii compunilor personalizate Firefox ESR în medii unde nu este posibil să activăm telemetria
- utilizatorii care se află în spatele unui proxy MitM, deoarece sistemul nostru de instalare a extensiilor folosește legarea cheilor (key pinning), care nu funcționează cu astfel de proxy-uri.
- utilizatorii versiunilor mai vechi de Firefox, care nu suportă cercetările.
Nu putem face nimic în legătură cu ultima categorie de utilizatori — ar trebui totuși să se actualizeze la o versiune nouă de Firefox, deoarece versiunile vechi au vulnerabilități grave nerezolvate. Știm că unii oameni rămân cu versiuni vechi de Firefox pentru a rula extensii mai vechi, dar multe dintre extensiile vechi au fost deja portate pentru versiunile noi ale browserului. Pentru ceilalți utilizatori, am dezvoltat un patch care va instala un nou certificat. Acesta a fost lansat ca un fix de erori (nota translatorului: Firefox 66.0.5), așa că oamenii îl vor obține — foarte probabil, l-au obținut deja — prin canalele obișnuite de actualizare. Dacă utilizați o versiune personalizată a Firefox ESR, vă rugăm să contactați mentinatorul dumneavoastră.
Înțelegem că toate acestea nu sunt perfecte. În unele cazuri, utilizatorii au pierdut datele extensiilor (de exemplu, datele extensiei Multi-Account Containers).
Acest efect secundar nu a putut fi evitat, dar considerăm că pe termen scurt am ales cea mai bună soluție pentru majoritatea utilizatorilor. Pe termen lung, vom căuta alte abordări arhitecturale mai avansate.
Lecții
În primul rând, echipa noastră a făcut o treabă uimitoare, creând și trimiind un fix în mai puțin de 12 ore după descoperirea problemei. Ca persoană care a fost prezent la întâlniri, pot spune că în această situație complicată, oamenii au muncit din greu și foarte puțin timp a fost pierdut în zadar.
Este evident că toate acestea nu ar fi trebuit să se întâmple. Cu siguranță trebuie să corectăm procesele noastre pentru a reduce probabilitatea unor astfel de incidente și pentru a facilita corectarea consecințelor.
Săptămâna viitoare vom publica un raport oficial post-mortem și lista modificărilor pe care ne propunem să le facem. Până atunci, voi împărtăși gândurile mele. În primul rând, trebuie să existe o modalitate mai bună de a urmări starea lucrurilor care sunt o bombă cu ceas potențială. Trebuie să fim siguri că nu ne vom afla într-o situație în care una dintre ele să explodeze brusc. Lucrăm la detalii, dar, cel puțin, trebuie să avem o evidență a tuturor acestor lucruri.
În al doilea rând, avem nevoie de un mecanism pentru livrarea rapidă a actualizărilor utilizatorilor, chiar și atunci când — mai ales atunci când — tot restul nu funcționează. A fost grozav că am reușit să folosim sistemul de „cercetări”, dar acesta este un instrument imperfect și are unele efecte secundare nedorite. În special, știm că mulți utilizatori au activat actualizările automate, dar ar prefera să nu participe la cercetări (recunosc, și eu le-am dezactivat!). În același timp, avem nevoie de o modalitate de a trimite actualizări utilizatorilor, dar, indiferent de realizarea tehnică internă, utilizatorii trebuie să aibă posibilitatea să se aboneze la actualizări (inclusiv remedieri rapide), dar să renunțe la tot restul. În plus, canalul de actualizare trebuie să fie mai receptiv decât acum. Chiar și pe 6 mai, erau utilizatori care nu beneficiaseră de nicio remediere sau versiune nouă. Am lucrat deja la această problemă, dar ceea ce s-a întâmplat a arătat cât de importantă este.
În final, vom analiza arhitectura de securitate a extensiilor pentru a ne asigura că aceasta oferă un nivel adecvat de securitate, cu un risc minim de a rupere ceva.
Săptămâna viitoare vom examina rezultatele unei analize mai atente a celor întâmplate, iar între timp, voi fi bucuros să răspund la întrebările trimise pe email: ekr-blog@mozilla.com
Sursa: linux.org.ru
