Opmerking vertaler: voor het gemak van de lezers worden de data in Moskou-tijd gegeven
We hebben onlangs de vervaldatum gemist van een van de certificaten die worden gebruikt om add-ons te ondertekenen. Dit had tot gevolg dat add-ons voor gebruikers werden uitgeschakeld. Nu het probleem grotendeels is opgelost, wil ik graag de details delen van wat er is gebeurd en het werk dat is verricht.
Achtergrond: aanvullingen en handtekeningen
Geïnstalleerde add-ons moeten dit hebben digitale handtekening, dat gebruikers beschermt tegen kwaadaardige add-ons en een minimale beoordeling van add-ons door Mozilla-personeel vereist. Deze eis hebben wij in 2015 ingevoerd omdat wij dit meemaakten serieuze problemen met kwaadaardige add-ons.
Hoe het werkt: Elk exemplaar van Firefox bevat een "rootcertificaat". De sleutel tot deze “root” wordt opgeslagen in Hardware-beveiligingsmodule (HSM)zonder netwerktoegang. Met deze sleutel wordt elke paar jaar een nieuw ‘tussencertificaat’ ondertekend, dat wordt gebruikt bij het ondertekenen van add-ons. Wanneer een ontwikkelaar een add-on indient, maken we een tijdelijk ‘eindcertificaat’ en ondertekenen we dit met een tussencertificaat. De add-on zelf wordt vervolgens ondertekend met het definitieve certificaat. Schematisch het ziet er zo uit.
Houd er rekening mee dat elk certificaat een "onderwerp" (aan wie het certificaat is uitgegeven) en een "uitgever" (die het certificaat heeft uitgegeven) heeft. In het geval van een basiscertificaat is "onderwerp" = "uitgever", maar voor andere certificaten is de uitgever van het certificaat het onderwerp van het bovenliggende certificaat waarmee het is ondertekend.
Een belangrijk punt: elke add-on wordt ondertekend door een uniek eindcertificaat, maar vrijwel altijd worden deze eindcertificaten ondertekend door hetzelfde tussencertificaat.
Noot van de auteur: De uitzondering vormen zeer oude toevoegingen. Er werd destijds gebruik gemaakt van diverse tussencertificaten.
Dit tussencertificaat zorgde voor problemen: elk certificaat is een bepaalde periode geldig. Voor of na deze periode is het certificaat ongeldig en gebruikt de browser geen add-ons die door dit certificaat zijn ondertekend. Helaas is het tussencertificaat op 4 mei om 4 uur verlopen.
De gevolgen waren niet onmiddellijk zichtbaar. Firefox controleert de handtekeningen van geïnstalleerde add-ons niet voortdurend, maar ongeveer één keer per 24 uur, en de verificatietijd is voor elke gebruiker individueel. Hierdoor ondervonden sommige mensen direct problemen, terwijl anderen pas veel later problemen ondervonden. We werden ons voor het eerst bewust van het probleem rond de tijd dat het certificaat verliep en gingen meteen op zoek naar een oplossing.
Schade beperken
Toen we eenmaal beseften wat er was gebeurd, probeerden we te voorkomen dat de situatie erger werd.
Ten eerste stopten ze met het accepteren en ondertekenen van nieuwe toevoegingen. Het heeft geen zin om hiervoor een verlopen certificaat te gebruiken. Terugkijkend zou ik zeggen dat we alles hadden kunnen laten zoals het was. We zijn nu weer begonnen met het accepteren van supplementen.
Ten tweede stuurden ze onmiddellijk een oplossing die verhinderde dat handtekeningen dagelijks werden gecontroleerd. Zo hebben we de gebruikers gered wier browser de afgelopen XNUMX uur nog geen tijd had gehad om de add-ons te controleren. Deze oplossing is nu ingetrokken en is niet langer nodig.
Parallelle werking
In theorie lijkt de oplossing voor het probleem eenvoudig: maak een nieuw geldig tussencertificaat en onderteken elke add-on opnieuw. Helaas zal dit niet werken:
- we kunnen niet snel 15 add-ons in één keer opnieuw ondertekenen, het systeem is niet ontworpen voor een dergelijke belasting
- Nadat we de toevoegingen hebben ondertekend, moeten de bijgewerkte versies aan gebruikers worden geleverd. De meeste add-ons worden geïnstalleerd vanaf Mozilla-servers, dus Firefox zal binnen de komende XNUMX uur updates vinden, maar sommige ontwikkelaars distribueren ondertekende add-ons via kanalen van derden, zodat gebruikers dergelijke add-ons handmatig moeten bijwerken
In plaats daarvan probeerden we een oplossing te ontwikkelen die alle gebruikers zou bereiken zonder dat er veel of geen actie van hun kant nodig was.
Al snel kwamen we tot twee hoofdstrategieën, die we parallel gebruikten:
- Update Firefox om de geldigheidsduur van het certificaat te wijzigen. Hierdoor zullen bestaande add-ons weer op magische wijze werken, maar hiervoor is het uitbrengen en verzenden van een nieuwe versie van Firefox vereist
- Genereer een geldig certificaat en overtuig Firefox op de een of andere manier om het te accepteren in plaats van het bestaande certificaat dat is verlopen
We besloten eerst de eerste optie te gebruiken, die er redelijk werkbaar uitzag. Aan het eind van de dag brachten ze een tweede oplossing uit (een nieuw certificaat), waar we het later over zullen hebben.
Een certificaat vervangen
Zoals ik hierboven al zei, was het vereist:
- maak een nieuw geldig certificaat aan
- installeer het op afstand in Firefox
Om te begrijpen waarom dit werkt, gaan we het verificatieproces van de add-on eens nader bekijken. De add-on zelf wordt geleverd als een reeks bestanden, inclusief een reeks certificaten die worden gebruikt voor ondertekening. Als gevolg hiervan kan de add-on worden geverifieerd als de browser het rootcertificaat kent, dat tijdens de build in Firefox is ingebouwd. Zoals we echter al weten, is het tussenliggende certificaat verlopen, dus het is onmogelijk om de add-on te verifiëren.
Wanneer Firefox een add-on probeert te verifiëren, is dit niet beperkt tot het gebruik van de certificaten die zich in de add-on zelf bevinden. In plaats daarvan probeert de browser een geldige certificaatketen te creëren, te beginnen met het eindcertificaat en door te gaan totdat deze de root bereikt. Op het eerste niveau beginnen we met het eindcertificaat en zoeken vervolgens het certificaat waarvan het onderwerp de uitgever van het eindcertificaat is (dat wil zeggen het tussencertificaat). Normaal gesproken wordt dit tussencertificaat meegeleverd met de add-on, maar elk certificaat uit de opslag van de browser kan ook als dit tussencertificaat dienen. Als we op afstand een nieuw geldig certificaat aan het certificaatarchief kunnen toevoegen, zal Firefox proberen dit te gebruiken. De situatie voor en na het installeren van een nieuw certificaat.
Na installatie van het nieuwe certificaat heeft Firefox twee opties bij het valideren van de certificaatketen: gebruik het oude ongeldige certificaat (wat niet zal werken) of het nieuwe geldige certificaat (wat zal werken). Het is belangrijk dat het nieuwe certificaat dezelfde onderwerpnaam en publieke sleutel bevat als het oude certificaat, zodat de handtekening op het definitieve certificaat geldig is. Firefox is slim genoeg om beide opties uit te proberen totdat er een wordt gevonden die werkt, zodat de add-ons opnieuw worden getest. Houd er rekening mee dat dit dezelfde logica is die we gebruiken om TLS-certificaten te valideren.
Noot van de auteur: Lezers die bekend zijn met WebPKI zullen merken dat kruiscertificaten op precies dezelfde manier werken.
Het mooie van deze oplossing is dat u bestaande add-ons niet opnieuw hoeft te ondertekenen. Zodra de browser het nieuwe certificaat ontvangt, werken alle add-ons weer. De resterende uitdaging is om het nieuwe certificaat aan gebruikers te leveren (automatisch en op afstand), en om Firefox uitgeschakelde add-ons opnieuw te laten controleren.
Normandië en het onderzoekssysteem
Ironisch genoeg wordt dit probleem opgelost door een speciale add-on genaamd “systeem”. Om onderzoek te doen, hebben we een systeem ontwikkeld met de naam Normandy, dat onderzoek levert aan gebruikers. Deze onderzoeken worden automatisch uitgevoerd in de browser en hebben verbeterde toegang tot de interne API's van Firefox. Onderzoek kan nieuwe certificaten toevoegen aan het certificaatarchief.
Noot van de auteur: we voegen geen certificaat toe met speciale rechten; het is ondertekend door het rootcertificaat, dus Firefox vertrouwt het. We voegen het eenvoudigweg toe aan de verzameling certificaten die door de browser kunnen worden gebruikt.
De oplossing is dus om een onderzoek te maken:
- het installeren van het nieuwe certificaat dat we voor gebruikers hebben gemaakt
- waardoor de browser wordt gedwongen uitgeschakelde add-ons opnieuw te controleren, zodat ze weer werken
"Maar wacht", zegt u, "add-ons werken niet, hoe kan ik een systeemadd-on starten?" Laten we het ondertekenen met een nieuw certificaat!
Alles bij elkaar opgeteld... waarom duurt het zo lang?
Dus het plan: geef een nieuw certificaat uit om het oude te vervangen, maak een systeemadd-on en installeer deze voor gebruikers via Normandië. De problemen begonnen, zoals ik al zei, op 4 mei om 4 uur, en al om 00 uur op dezelfde dag, minder dan 12 uur later, stuurden we een oplossing naar Normandië. Het duurde nog eens 44-9 uur voordat het alle gebruikers bereikte. Helemaal niet slecht, maar mensen op Twitter vragen zich af waarom we niet sneller hadden kunnen handelen.
Ten eerste kostte het tijd om een nieuw tussencertificaat af te geven. Zoals ik hierboven al zei, wordt de sleutel tot het rootcertificaat offline opgeslagen in de hardwarebeveiligingsmodule. Dit is goed vanuit veiligheidsoogpunt, aangezien de root zeer zelden wordt gebruikt en op betrouwbare wijze moet worden beschermd, maar het is enigszins lastig als u dringend een nieuw certificaat moet ondertekenen. Eén van onze monteurs moest naar de opslagplaats van HSM reizen. Vervolgens waren er mislukte pogingen om het juiste certificaat af te geven, en elke poging kostte een of twee uur aan testen.
Ten tweede heeft de ontwikkeling van de systeemadd-on enige tijd in beslag genomen. Conceptueel is het heel eenvoudig, maar zelfs eenvoudige programma's vereisen zorg. We wilden er zeker van zijn dat we de situatie niet verergerden. Onderzoek moet worden getest voordat het naar gebruikers wordt verzonden. Bovendien moet de add-on worden ondertekend, maar ons add-on-ondertekeningssysteem was uitgeschakeld, dus moesten we een oplossing vinden.
Toen we het onderzoek eenmaal klaar hadden voor indiening, kostte de implementatie enige tijd. De browser controleert elke 6 uur op Normandië-updates. Niet alle computers zijn altijd ingeschakeld en verbonden met internet, dus het zal enige tijd duren voordat de oplossing zich onder gebruikers verspreidt.
Laatste stappen
Het onderzoek zou het probleem voor de meeste gebruikers moeten oplossen, maar is niet voor iedereen beschikbaar. Sommige gebruikers vereisen een speciale aanpak:
- gebruikers die onderzoek of telemetrie hebben uitgeschakeld
- gebruikers van de Android-versie (Fennec), waar onderzoek helemaal niet wordt ondersteund
- gebruikers van aangepaste versies van Firefox ESR in ondernemingen waar telemetrie niet kan worden ingeschakeld
- gebruikers die achter MitM-proxy's zitten, omdat ons add-on-installatiesysteem gebruik maakt van sleutelpinning, wat niet werkt met dergelijke proxy's
- gebruikers van oudere versies van Firefox die geen onderzoek ondersteunen
Aan deze laatste categorie gebruikers kunnen we niets doen. Zij moeten nog steeds updaten naar de nieuwe versie van Firefox, omdat verouderde versies ernstige, niet-gepatchte kwetsbaarheden bevatten. We weten dat sommige mensen oudere versies van Firefox blijven gebruiken omdat ze oude add-ons willen gebruiken, maar veel van de oude add-ons zijn al overgezet naar nieuwere versies van de browser. Voor andere gebruikers hebben we een patch ontwikkeld waarmee een nieuw certificaat wordt geïnstalleerd. Het werd uitgebracht als een bugfix-release (Noot van de vertaler: Firefox 66.0.5), zodat mensen het krijgen (waarschijnlijk al hebben) via het reguliere updatekanaal. Als u een aangepaste versie van Firefox ESR gebruikt, neem dan contact op met uw beheerder.
Wij begrijpen dat dit niet ideaal is. In sommige gevallen verloren gebruikers aanvullende gegevens (bijvoorbeeld aanvullende gegevens). Containers voor meerdere accounts).
Deze bijwerking kon niet worden vermeden, maar wij zijn van mening dat we op de korte termijn voor de meeste gebruikers de beste oplossing hebben gekozen. Op de lange termijn zullen we zoeken naar andere, meer geavanceerde architecturale benaderingen.
ervaring
Ten eerste heeft ons team geweldig werk geleverd door een oplossing te creëren en te verzenden in minder dan 12 uur nadat het probleem was ontdekt. Als iemand die de bijeenkomsten bijwoonde, kan ik zeggen dat er in deze moeilijke situatie heel hard werd gewerkt en dat er heel weinig tijd werd verspild.
Het is duidelijk dat dit allemaal helemaal niet had mogen gebeuren. Het loont duidelijk de moeite om onze processen aan te passen om de kans op dergelijke incidenten te verkleinen en het herstel makkelijker te maken.
Volgende week publiceren we een officieel autopsierapport en een lijst met wijzigingen die we willen doorvoeren. Voor nu deel ik mijn gedachten. Ten eerste moet er een betere manier zijn om de status te monitoren van wat een potentiële tijdbom is. We moeten er zeker van zijn dat we niet in een situatie terechtkomen waarin een van hen plotseling werkt. We zijn nog bezig met het uitwerken van de details, maar het is op zijn minst noodzakelijk om met al deze zaken rekening te houden.
Ten tweede hebben we een mechanisme nodig om snel updates aan gebruikers te leveren, zelfs wanneer (vooral wanneer) al het andere faalt. Het was geweldig dat we het 'onderzoek'-systeem konden gebruiken, maar het is een onvolmaakt instrument en heeft een aantal ongewenste bijwerkingen. We weten vooral dat veel gebruikers automatische updates hebben ingeschakeld, maar liever niet aan onderzoek willen deelnemen (ik geef toe: ik heb ze ook uitgeschakeld!). Tegelijkertijd hebben we een manier nodig om updates naar gebruikers te sturen, maar wat de interne technische implementatie ook is, gebruikers moeten zich kunnen abonneren op updates (inclusief hotfixes), maar zich afmelden voor al het andere. Bovendien zou het updatekanaal sneller moeten reageren dan het nu is. Zelfs op 6 mei waren er nog steeds gebruikers die geen gebruik maakten van de oplossing of de nieuwe versie. Er is al aan dit probleem gewerkt, maar wat er is gebeurd, heeft aangetoond hoe belangrijk het is.
Ten slotte zullen we de beveiligingsarchitectuur van de add-on nader bekijken om er zeker van te zijn dat deze het juiste beveiligingsniveau biedt met een minimaal risico dat er iets kapot gaat.
Volgende week zullen we kijken naar de resultaten van een grondigere analyse van wat er is gebeurd, maar in de tussentijd beantwoord ik graag vragen per e-mail: [e-mail beveiligd]
Bron: linux.org.ru