Opmerking van de vertaler: voor het gemak van de lezers zijn de datums in Moskou tijd weergegeven.
Onlangs hebben we het moment gemist waarop een van de certificaten die gebruikt worden voor het ondertekenen van extensies is verlopen. Dit leidde tot het uitschakelen van extensies voor gebruikers. Nu het probleem grotendeels is opgelost, wil ik graag de details van wat er is gebeurd en het werk dat is verricht, toelichten.
Achtergrond: extensies en handtekeningen
GeĆÆnstalleerde extensies moeten een digitale handtekening, die gebruikers beschermt tegen kwaadaardige extensies, en minimale controle van extensies door medewerkers van Mozilla vereist. We hebben deze eis in 2015 ingevoerd, omdat we ernstige problemen ondervonden met kwaadaardige extensies. Hoe het werkt: elke kopie van Firefox bevat een 'root-certificaat'. De sleutel van deze 'root' wordt opgeslagen in
een hardwarebeveiligingsmodule (HSM) , die geen toegang tot het netwerk heeft. Om de paar jaar wordt er met deze sleutel een nieuw 'intermediair certificaat' ondertekend, dat wordt gebruikt voor het ondertekenen van extensies. Wanneer een ontwikkelaar een extensie indient, creƫren we een tijdelijk 'eindcertificaat' en ondertekenen dit met het intermediaire certificaat. Vervolgens wordt de extensie ondertekend met het eindcertificaat. Schema gewijsziet dit er als volgt uit Let op: elk certificaat heeft een 'onderwerp' (aan wie het certificaat is uitgegeven) en een 'uitgever' (wie het certificaat heeft uitgegeven). In het geval van een root-certificaat is 'onderwerp' = 'uitgever', maar voor andere certificaten is de uitgever van het certificaat het onderwerp van het bovenliggende certificaat waarmee dit is ondertekend..
Belangrijke opmerking: elke extensie is ondertekend met een uniek eindcertificaat, maar bijna altijd zijn deze eindcertificaten ondertekend met hetzelfde intermediaire certificaat.
Opmerking van de auteur: een uitzondering zijn zeer oude extensies. Toen werden verschillende intermediaire certificaten gebruikt.
Opmerking van de auteur: uitzondering zijn zeer oude aanvullingen. In die tijd werden verschillende tussenliggende certificaten gebruikt.
Het tussenliggende certificaat veroorzaakte problemen: elk certificaat is geldig voor een bepaalde periode. Voor of na deze periode is het certificaat ongeldig, en de browser zal geen extensies gebruiken die met dit certificaat zijn ondertekend. Helaas is de geldigheidsduur van het tussenliggende certificaat verlopen op 4 mei om 04:00 uur.
De gevolgen deden zich niet onmiddellijk voor. Firefox controleert de handtekeningen van geĆÆnstalleerde extensies niet continu, maar ongeveer om de 24 uur, waarbij de controle tijdspecifiek is voor elke gebruiker. Als gevolg hiervan ondervonden sommige mensen onmiddellijk problemen, terwijl anderen veel later tegen problemen aanliepen. We hoorden voor het eerst over het probleem ongeveer op het moment dat de geldigheid van het certificaat afliep, en we begonnen onmiddellijk met het zoeken naar een oplossing.
Schade verminderen
Zodra we begrepen wat er aan de hand was, probeerden we te voorkomen dat de situatie erger werd.
Ten eerste stopten we met het aannemen en ondertekenen van nieuwe extensies. Het heeft geen zin om dit te doen met een verlopen certificaat. Achteraf zou ik zeggen dat we alles hadden kunnen laten zoals het was. Nu is de acceptatie van extensies hervat.
Ten tweede verstuurden we onmiddellijk een fix die de dagelijkse handtekeningcontroles voorkwam. Op deze manier hebben we de gebruikers gered wiens browser in de afgelopen 24 uur nog niet had gecontroleerd op extensies. Deze fix is nu ingetrokken, omdat deze niet meer nodig is.
Parallelle werking
Theoretisch gezien lijkt de oplossing simpel: we creƫren een nieuw geldig tussenliggend certificaat en ondertekenen elke extensie opnieuw. Helaas werkt dit niet:
- We kunnen 15.000 extensies niet snel allemaal opnieuw ondertekenen; het systeem is daar niet op ingericht.
- Nadat we de extensies hebben ondertekend, moeten de bijgewerkte versies naar de gebruikers worden gebracht. De meeste extensies worden vanaf de servers van Mozilla geĆÆnstalleerd, dus binnen de komende 24 uur zal Firefox de updates vinden, maar sommige ontwikkelaars verspreiden ondertekende extensies via externe kanalen, dus gebruikers zouden dergelijke extensies handmatig moeten bijwerken.
In plaats daarvan hebben we geprobeerd een fix te ontwikkelen die alle gebruikers zou bereiken, zonder dat (of bijna zonder dat) zij actie hoefden te ondernemen.
Al snel kwamen we tot twee belangrijke strategieƫn die we parallel hebben toegepast:
- Update Firefox om de geldigheidsperiode van het certificaat te wijzigen. Dit zal ervoor zorgen dat bestaande extensies weer op mysterieuze wijze werken, maar vereist de uitgifte en levering van een nieuwe versie van Firefox.
- Maak een geldig certificaat en overtuig Firefox op de een of andere manier om het te accepteren in plaats van het bestaande, waarvan de geldigheid is verlopen.
We besloten eerst de eerste optie te gebruiken, die behoorlijk haalbaar leek. Aan het eind van de dag hebben we ook de tweede patch (nieuw certificaat) uitgebracht, waar we verder op ingaan.
Vervangen van het certificaat
Zoals ik eerder heb genoemd, was het nodig om:
- een nieuw geldig certificaat te maken
- het op afstand in Firefox te installeren
Om te begrijpen waarom dit zou werken, laten we het proces van de extensiebeoordeling nader bekijken. De extensie zelf wordt geleverd als een set bestanden, inclusief de keten van certificaten die worden gebruikt voor ondertekening. Een extensie kan worden gecontroleerd als de browser het rootcertificaat kent, dat tijdens de bouw in Firefox wordt ingebouwd. Echter, zoals we al weten, is het tussenliggende certificaat verlopen, waardoor de extensie niet kan worden gecontroleerd.
Wanneer Firefox probeert de extensie te verifiƫren, beperkt het zich niet tot het gebruik van de certificaten die in de extensie zelf zijn inbegrepen. In plaats daarvan probeert de browser een geldige keten van certificaten te creƫren, beginnend met het eindcertificaat en gaande tot het rootcertificaat. Op het eerste niveau beginnen we met het eindcertificaat en zoeken we het certificaat waarvan de subject het uitgever van het eindcertificaat is (d.w.z. het tussenliggende certificaat). Dit tussenliggende certificaat wordt meestal bij de extensie meegeleverd, maar kan ook elk certificaat uit de opslag van de browser zijn. Als we in staat zijn om op afstand een nieuw geldig certificaat aan de certificaatopslag toe te voegen, zal Firefox proberen dit te gebruiken. De situatie voor en na de installatie van het nieuwe certificaat.
Na het installeren van het nieuwe certificaat zal Firefox twee opties hebben bij het controleren van de certificaatchain: het oude ongeldige certificaat (dat niet zal werken) gebruiken, of het nieuwe geldige certificaat (dat wel zal werken). Het is belangrijk dat het nieuwe certificaat dezelfde naam van de houder en de publieke sleutel bevat als het oude certificaat, zodat de handtekening op het eindcertificaat geldig zal zijn. Firefox is slim genoeg om beide opties te proberen totdat het een werkende vindt, zodat de extensies opnieuw gevalideerd zullen zijn. Let op, dit is dezelfde logica die wij gebruiken voor het controleren van TLS-certificaten.
Opmerking van de auteur: lezers die bekend zijn met WebPKI zullen opmerken dat kruiscertificaten op precies dezelfde manier werken.
Het meest opmerkelijke aan deze oplossing is dat het niet nodig is om bestaande extensies opnieuw te ondertekenen. Zodra de browser het nieuwe certificaat ontvangt, zullen alle extensies opnieuw werken. Het blijft een uitdaging om het nieuwe certificaat automatisch en op afstand naar de gebruikers te brengen, en om Firefox te dwingen om de uitgeschakelde extensies opnieuw te controleren.
Normandy en het onderzoeksysteem
Ironisch genoeg wordt dit probleem opgelost door een speciale extensie die 'systeem'-extensie wordt genoemd. Om onderzoeken uit te voeren, hebben we een systeem ontwikkeld genaamd Normandy, dat onderzoeken naar gebruikers levert. Deze onderzoeken worden automatisch uitgevoerd in de browser en hebben uitgebreide toegang tot interne API's van Firefox. Onderzoeken kunnen nieuwe certificaten aan de certificaatopslag toevoegen.
Opmerking van de auteur: we voegen het certificaat niet toe met enige speciale privileges; het is ondertekend door een rootcertificaat, daarom vertrouwt Firefox erop. We voegen het gewoon toe aan de pool van certificaten die door de browser kunnen worden gebruikt.
Dus de oplossing bestaat uit het creƫren van een onderzoek:
- die het nieuwe certificaat dat wij hebben gemaakt aan de gebruikers installeert
- dat de browser dwingt om de uitgeschakelde extensies opnieuw te controleren, zodat ze opnieuw werken
"Maar wacht eens", zult u zeggen, "de extensies werken niet, hoe start ik een systeem-extensie?" Laten we het ondertekenen met het nieuwe certificaat!
Laten we alles samenbrengen... waarom duurt het zo lang?
Dus, het plan: een nieuw certificaat uitgeven ter vervanging van het oude, een systeemuitbreiding maken en deze aan gebruikers installeren via Normandy. De problemen, zoals ik al zei, begonnen op 4 mei om 4:00 uur, en al om 12:44 uur op dezelfde dag, minder dan 9 uur later, hebben we een oplossing naar Normandy gestuurd. Het duurde nog eens 6-12 uur voordat het bij alle gebruikers aankwam. Dat is al aardig, maar gebruikers op Twitter vragen waarom we niet sneller konden handelen.
Ten eerste kostte het tijd om een nieuw intermediair certificaat uit te geven. Zoals ik eerder heb vermeld, wordt de sleutel van het rootcertificaat autonoom opgeslagen in een hardwarebeveiligingsmodule. Dit is goed qua veiligheid, omdat de root zeer zelden wordt gebruikt en goed beschermd moet zijn, maar het is een beetje ongemakkelijk als er snel een nieuw certificaat moet worden ondertekend. Een van onze ingenieurs moest naar de HSM-opslag gaan. Vervolgens waren er mislukte pogingen om het juiste certificaat uit te geven, en elke poging kostte een tot twee uur aan tests.
Ten tweede kostte de ontwikkeling van de systeemuitbreiding enige tijd. Conceptueel is het heel eenvoudig, maar zelfs eenvoudige programma's vereisen aandacht. We wilden er zeker van zijn dat we de situatie niet nog erger maakten. Onderzoek moet worden getest voordat het naar gebruikers wordt gestuurd. Bovendien moet de uitbreiding worden ondertekend, maar ons systeem voor het ondertekenen van uitbreidingen was uitgeschakeld, waardoor we een alternatieve oplossing moesten zoeken.
Ten slotte, nadat we het onderzoek voor verzending hadden voorbereid, kostte de uitrol tijd. De browser controleert elke 6 uur op updates van Normandy. Niet alle computers zijn voortdurend aan en verbonden met het internet, dus het kost tijd voordat de oplossing zich onder de gebruikers verspreidt.
Laatste stappen
Het onderzoek moet het probleem bij de meeste gebruikers oplossen, maar is niet voor iedereen beschikbaar. Voor sommige gebruikers is een speciale aanpak nodig:
- gebruikers die onderzoek of telemetry hebben uitgeschakeld
- gebruikers van de Android-versie (Fennec), waar onderzoek helemaal niet wordt ondersteund
- gebruikers van aangepaste versies van Firefox ESR op bedrijven waar telemetry niet kan worden ingeschakeld
- gebruikers die achter een MitM-proxy zitten, aangezien ons systeem voor het installeren van extensies sleutelbinding (key pinning) gebruikt, wat niet werkt met dergelijke proxies
- gebruikers van verouderde versies van Firefox die geen onderzoeksondersteuning bieden
We kunnen niets doen voor de laatste categorie gebruikers - ze moeten zeker upgraden naar een nieuwe versie van Firefox, omdat verouderde versies ernstige ongepatchte kwetsbaarheden hebben. We weten dat sommige mensen op oude versies van Firefox blijven omdat ze oude extensies willen draaien, maar veel van die oude extensies zijn al aangepast voor de nieuwe versies van de browser. Voor andere gebruikers hebben we een patch ontwikkeld die een nieuw certificaat installeert. Het is uitgebracht als een bugfix-release (opmerking van de vertaler: Firefox 66.0.5), zodat mensen het zullen ontvangen - waarschijnlijk hebben ze het al ontvangen - via het gebruikelijke updatekanaal. Als je een aangepaste versie van Firefox ESR gebruikt, neem dan contact op met je maintainer.
We begrijpen dat dit alles niet ideaal is. In sommige gevallen hebben gebruikers gegevens van extensies verloren (bijvoorbeeld de gegevens van de extensie Multi-Account Containers).
Dit neveneffect was niet te vermijden, maar we denken dat we op de korte termijn de beste oplossing voor de meeste gebruikers hebben gekozen. Op de lange termijn zullen we zoeken naar andere, meer geavanceerde architecturale benaderingen.
Lessen
Ten eerste heeft ons team geweldig werk geleverd door minder dan 12 uur na ontdekking van het probleem een oplossing te creƫren en te verzenden. Als iemand die bij de vergaderingen aanwezig was, kan ik zeggen dat mensen in deze moeilijke situatie zeer hard werkten en er heel weinig tijd verloren ging.
Het is duidelijk dat dit helemaal niet had mogen gebeuren. We moeten onze processen duidelijk aanpassen om de kans op dergelijke incidenten te verkleinen en het herstel van de gevolgen te vergemakkelijken.
Volgende week publiceren we een officiƫle post-mortem en een lijst met veranderingen die we van plan zijn door te voeren. Voor nu wil ik graag mijn gedachten hierover delen. Ten eerste moet er een betere manier zijn om de staat van dingen te volgen die een potentiƫle tijdbom kunnen zijn. We moeten ervoor zorgen dat we niet in een situatie terechtkomen waarin er plotseling eentje afgaat. We werken nog aan de details, maar in ieder geval is het noodzakelijk om een inventarisatie van al deze zaken te maken.
Ten tweede is er een mechanisme nodig voor een snelle levering van updates aan gebruikers, zelfs wanneer ā vooral wanneer ā alles andere niet werkt. Het was geweldig dat we het 'onderzoek'-systeem hebben kunnen gebruiken, maar het is een imperfecte tool met enkele ongewenste bijwerkingen. We weten bijvoorbeeld dat veel gebruikers automatische updates hebben ingeschakeld, maar dat ze liever niet deelnemen aan onderzoeken (ik geef toe, ik heb ze ook uitgeschakeld!). Tegelijkertijd hebben we een manier nodig om updates naar gebruikers te sturen, maar ongeacht de interne technische implementatie moeten gebruikers zich kunnen abonneren op updates (inclusief spoedoplossingen), maar zich kunnen afmelden voor alles wat daarbuiten komt. Bovendien moet het updatekanaal responsiever zijn dan het nu is. Zelfs op 6 mei waren er nog gebruikers die geen gebruik maakten van een oplossing of nieuwe versie. Aan dat probleem wordt al gewerkt, maar wat er is gebeurd heeft laten zien hoe belangrijk dat is.
Tenslotte kijken we naar de beveiligingsarchitectuur van de add-ons om ervoor te zorgen dat deze een passend beveiligingsniveau biedt met een minimaal risico om iets te breken.
Volgende week bekijken we de resultaten van een grondigere analyse van wat er is gebeurd, maar in de tussentijd beantwoord ik graag vragen per e-mail: ekr-blog@mozilla.com
Bron: linux.org.ru
