Firefox-verbindingsproblemen kwamen door Google-wijziging en fout in library

Firefox was medio januari enkele uren beperkt te gebruiken. Naar nu is gebleken was een Google-dienst onaangekondigd overgestapt op HTTP/3. Dit activeerde een bug in de browser die hoofdletters in een header verving door kleine letters. De HTTP/3-code kan die niet lezen.

Een deel van de Firefox-gebruikers kon op 13 januari ruim vier uur lang geen websites bezoeken, al bleek toen al dat het uitschakelen van HTTP/3 hielp. Firefox Tech Lead en Senior Staff Security Engineer Christian Holler legt op een Mozilla-blog uit waardoor dit kwam. Het probleem ontstond toen Google Cloud Platform de standaard HTTP overzette naar HTTP/3. Google had dit niet vooraf aangekondigd en de Firefox-browser nam deze wijziging standaard over. Firefox gebruikt clouddiensten als GCP voor updates, telemetrie, het beheren van certificaten, crashreports en andere functies.

Mozilla kwam er al snel achter dat het omschakelen naar HTTP/3 tot de storing leidde. Toen dit werd uitgeschakeld en de browsers weer HTTP/2 gingen gebruiken, was het probleem voorbij. Hiermee was echter nog niet duidelijk waarom HTTP/3 problemen opleverde.

Dit bleek te liggen aan onderdelen van de Firefox-browser die op basis van Rust gemaakt zijn, specifiek de Telemetry-header. Alle HTTP/3-verbindingen gaan via Necko, de netwerkstack van Firefox. Rust-componenten gaan echter niet direct via Necko, maar lopen eerst via de intermediate library viaduct. Bij deze intermediate library ging het fout.

De lower-level-HTTP/3-code vereist namelijk de Content-Length-header, die Necko automatisch aanmaakt als code deze header nog niet heeft. Bij het controleren of code die header heeft, kijkt Necko echter niet naar het onderscheid tussen kleine letters en hoofdletters. Dit bleek een probleem te zijn, doordat viaduct van alle hoofdletters in headers kleine letters maakt. Daardoor ontstaat de content-length-header, dus zonder hoofdletters.

Bij Rust-code waar de header nog niet was toegevoegd, ging niets fout. Viaduct maakt zelf namelijk geen headers aan, maar verandert alleen de hoofdletters in kleine letters. De code ging dus zonder header naar Necko, dat de juiste Content-Length-header aanmaakte.

Telemetry was tijdens de storing het enige Firefox-onderdeel dat is gemaakt in Rust en dat de juiste Content-Length-header had. Viaduct maakte hier content-length van, wat niet door Necko werd aangepast. Doordat de lower-level-HTTP/3-code de Content-Length-header met hoofdletters vereist, kon de HTTP/3-code de header niet vinden, terwijl die er volgens Necko wel was. Daardoor onstond een oneindige loop en kwam er ook geen errormelding. Die loop had op zijn beurt tot gevolg dat andere netwerkcommunicatie werd geblokkeerd en de browser onbruikbaar werd. Rust-onderdelen zonder de header werkten wel, omdat de header dan pas bij Necko werd toegevoegd. Daardoor konden gebruikers die Telemetry uitschakelden, wel de browser gebruiken.

Mozilla zegt nu in contact te zijn met Google om dergelijke onverwachte veranderingen te voorkomen. Het bedrijf erkent dat een aankondiging het risico op een dergelijk incident niet helemaal wegneemt, maar dat daardoor wel meer tests mogelijk zijn. Daarnaast gaat Mozilla alle service configurations nalopen om te kijken of andere diensten ook zomaar de standaardinstellingen van een andere dienst overnemen, zoals bij de overschakeling naar HTTP/3 gebeurde. Tot slot wil Mozilla meer tests uitvoeren met verschillende HTTP-versies en wil de organisatie zijn incident response versnellen.

Reacties (48)

[depeje]

Wat mij vooral verbaast is dat een browser die volgens de makers privacy-vriendelijk zou moeten zijn gaat communiceren met google.

Granted, als je de volledige verklaring leest is het duidelijk dat ze soms data naar google sturen, maar de telemetrie die hierboven genoemd wordt, wordt niet in hun privacy notice aangeduid. Verder blijft het tegenstrijdig dat ze google services noemen in een document met als titel "At Mozilla, we believe that privacy is fundamental to a healthy internet.".

[Reactie gewijzigd door depeje op 23 juli 2024 04:10]

[GertMenkel]

Google Cloud Platform is een algemene cloudservice. Net zoals communicatie met AWS niet per se betekent dat je met Amazon (de winkel) communiceert, betekent GCP niet dat je data door Google verwerkt zullen worden.

Edit: persoonlijk vind ik overigens wel dat Firefox veel te snel veel te veel data binnenhengelt tegenwoordig. Ik heb niet het idee meer dat de Mozilla Foundation veel om privacy geeft, ze zijn denk ik ten prooi gevallen van de data-gedreven softwareontwikkeling die je ook bij browsers als Chrome en Edge ziet. Zie bijvoorbeeld de pagina die ze openen met "gefeliciteerd, je browser is geüpdatet" die vol zit met trackers. Als je me lastigvalt met zo'n pagina, zorg dan tenminste dat hij enigszins privacyvriendelijk in elkaar zit.

Telemetrie gaat bij mij daarom tegenwoordig standaard uit in Firefox. 't is dat ik een alternatieve browser-engine wil hebben voor het web, anders zou ik zo langzaamaan toch maar gaan kijken naar een alternatief.

[Reactie gewijzigd door GertMenkel op 23 juli 2024 04:10]

[Duckman51]

Mm welk alternatief zou dat moeten worden dan?

[GertMenkel]

De overlap tussen "open source" en "privacy-vriendelijk" is helaas niet heel groot op desktop. Brave is privacy-vriendelijk maar heeft cryptozooi ingebouwd. Edgium was mijn go-to alternatief in de alfa-versie totdat Microsoft er een totale bende van maakte. Op Android gebruik ik Bromite als een vertrouwd Chrome-alternatief met de meeste troep eruit gehaald, maar daar is helaas geen desktopversie van.

Browsers gebaseerd op WebKit (Konqueror, Gnome Web) missen vaak ondersteuning voor web-API's en CSS/HTML-standaarden; ze zijn een soort van Safari, maar nóg slechter.

Je hebt nog een stel Firefox-forks die gestart zijn omdat de ontwikkelaars ergens op tegen zijn, zoals de forks die de nieuwe UI niet willen of die de oude extensies willen houden, of wat dan ook. Daar heb ik ook weer niet zoveel mee, omdat ik niet afhankelijk wil zijn van een paar kleine vrijwilligers om security-fixes toe te passen (en ik ben het doorgaans eens met best veel van Mozilla's aanpassingen op de desktop).

Kort samengevat: ik weet het nog niet. Ik zit daarom nog bij Firefox, maar op een gegeven moment zal ik wel móeten wisselen.

[Duckman51]

Dank voor je toelichting, precies waarom ik ook bij Firefox blijf aangezien een echt alternatief er niet (meer) is

[Sando]

Ik heb een beetje het zelfde maar dan zit ik bij Brave. Het is een beetje een trilemma tussen gebruikersgemak, privacy en een verdienmodel.

Gebruikersgemak, want je wilt graag je bookmarks, tabs, history, instellingen en misschien een paar wachtwoorden synchroniseren tussen verschillende computers en je smartphoine.

Privacy, want trackers zijn ongewenst en soms gewoon gevaarlijk.

Verdienmodel, want voor niets gaat de zon op, en zoals je met veel open source projecten zonder verdienmodel ziet, kan de ontwikkeling soms voor kortere of langere tijd stagneren, en laat je browser nu net dat ene stukje software zijn waar je juist graag zo snel mogelijk bugfixes en security patches ziet.

Wat mij betreft zijn de enige acceptabele mogelijkheden Firefox en Brave, omdat ze zowel desktop als smartphone apps hebben, en allebei hebben ze e2e encrypted sync daartussen.

Mozilla doet telemetry by default en verdient geld met deals with the devil (search partnerships). Brave verdient geld met crypto currencies en brave rewards ofzo. Je kunt dit in beide browsers uitzetten. Ik heb het gevoel dat Brave iets privacy vriendelijker is, en gedetailleerdere tracking- en adblocking ingebouwd heeft. Maar voor mensen die twijfelen: Kies Firefox. Het is het laatste restje weerstand tegen market domination van Google.

[gorgi_19]

Ze gebruiken Google Cloud Platform: "Firefox gebruikt clouddiensten als GCP voor updates, telemetrie, het beheren van certificaten, crashreports en andere functies."

Dan beweer je nu dat Google alle zakelijke data op hun cloud platform van hun klanten, analyseert, doorzoekt en gebruikt.

Google, AWS, Microsoft's cloud platformen zijn hosting providers en staan los van eventuele privacy issues die de bedrijven veroorzaken met trackers.

[wica]

Is dat zo? Durf jij je hand ervoor in het vuur te steken, dat ze geen misbruik maken van hun positie?

Ik kan niet zeggen en al helemaal niet bewijzen dat ze het wel doen. Maar het is wel een hele grote berg aan data, om er niets mee te doen.

[1superheld]

Als ze dat doen en dat komt naar buiten zijn ze zo een heel hoop klanten kwijt, denk je dat ze dat willen riskeren?

Geen fan van Google producten, maar hier gaan ze zich echt mee in de voet schieten.

[wica]

Waar moeten die klanten dan heen, als ze het allemaal zouden doen?

Dit is al een probleem, maar de klant loopt niet weg.
nieuws: Windows 10 Enterprise en Office voldoen nog niet aan privacyeisen van...

[GeroldM]

Waar gaan klanten dan naar toe?
AWS? Ook daar is niets zeker. Net zoals bij Azure en Oracle trouwens. Jouw data draait op servers die een complete backup van jouw spul in een een paar seconden overjassen naar een backup server. Snel genoeg dat jij er niets van merkt. Nu er een backup is, gaat men dus daarmee aan de slag om te zien of er belangrijke informatie uit te halen valt.

En als dat niet op hun Europese servers gebeurt, dan is diezelfde data binnen een paar seconden overgejast naar een server in de V.S. waar ze er geen ethische bezwaren mee hebben om zich jouw data toe te eigenen.

Begrijp me goed, ik verwacht dat zo'n scenario niet voorkomt. En het zal moeilijk zijn om te bewijzen dat het wel gebeurt. Hetzelfde geldt voor bewijs om zo'n scenario te ontkrachten.

De beheerspanelen die jij voor jouw doen en laten in de cloud gebruikt, die zijn niet hetzelfde voor de personen die de servers daarwerkelijk beheren in de datacenters. Die hebben namelijk veel meer mogelijkheden.

Microsoft en consorten mogen dan wel beweren dat ze niets met jouw data doen, maar het is een leuke poel aan data waar meer dan genoeg (meta-)data uit te vissen valt, welke een leuke bonus op de winstbalans opleveren. En er is geen enkel (Amerikaans) bedrijf dat daar nee tegen zegt.

[Sinnergy]

Google is hier de 'host' van verschillende services. Nu ja, telemetry op zich is iets anders natuurlijk, geen idee of dat opt-in of opt-out is in firefox?

[depeje]

Blijkbaar is het opt-out, want het stond aan in mijn browser.

[EraYaN]

De eerste keer dat je start krijg je een meldingsbalk erover volgens mij, maar die is dan nog steeds opt-out, maar wel redelijk simpel (was altijd 1 klik).

[TheVivaldi]

Ik heb dat laatst na een schone installatie nog moeten uitzetten via about:config. Ik heb geen meldingsbalk gezien.

[CH4OS]

Wanneer je bij Google (of welke partij dan ook, for that matter) betaald voor een product, zoals bij GCP, heb je veel meer privacy. Ze verdienen immers via een andere route aan je en dan zal indexatie ze worst wezen, je betaald dan immers voor de dienst die je afneemt bij ze. Dat doe je bij Search en GMail ook (dienst afnemen), maar je betaalt ook niet, dus haalt Google het geld elders vandaan en daar heeft men info voor nodig.

Je kunt dus echt niet zomaar stellen dat 'omdat Google betrokken is' er dus geen sprake kan zijn van privacy. Sterker nog, ik durf mijn handen in het vuur te steken dat een aantal grote websites en webshops gehost worden via Google, waar Google via de hosting echt niet aan data verzameling voor eigen gewin doet.

Hou er ook rekening mee, dat de privacy statement per product/dienst verschilt. Je kunt dus niet met 1 en dezelfde privacy statement schermen.

[Vuurvleugelhart]

Het is nog veel erger, Firefox voor Android bevat "gewoon" een tracker van Google: https://reports.exodus-pr...rg.mozilla.firefox/latest.
Daarnaast open eens een bijlage in Thunderbird en werp een blik in je firewall.

Helaas Mozilla om uitleg vragen hoe dit rijmt met privacy behoort niet tot de mogelijkheid. Ook Mozilla houdt hun contactgegevens verborgen, al zal het wel net als de meeste andere bedrijven gaan dat je geen eenduidig antwoord krijgt.
Daarom is het jammer dat je Tor niet zonder Tor-netwerk kunt gebruiken, dat is de enige browser die ik tegen ben gekomen die geen data met derden deelt (volgens mij Privacy Browser via F-Droid ook niet).
(weet logischerwijs dat Tor een aangepaste versie van Firefox is en dat dit het nut van Tor teniet zou doen).

Is er een betere/veiligere browser dan Firefox? Die is er niet, het blijft dan ook, vooralsnog, de minst slechte browser om te gebruiken.
Door veranderingen, zowel voor PC maar vooral onder Android, binnen Firefox wordt het wel steeds een minder prettige browser om te gebruiken (maar dit is een andere discussie). Hopelijk komt de dag weer dat Mozilla naar hun gebruikers gaat luisteren...

[Stukfruit]

Waarom maakt dat "viaduct" überhaupt lowercase van die Content-Length header ipv deze direct door te geven zoals het binnenkomt?

Het zomaar muteren van data in locaties waar het alleen uitgelezen of doorgestuurd zou moeten worden is nooit echt een teken van goed programmeerwerk (yes, ik ben zo'n C++ const-zeikerd ) geweest, maar hier wordt helaas met geen woord over gesproken in het bronartikel. Mis ik iets?

[Reactie gewijzigd door Stukfruit op 23 juli 2024 04:10]

[GertMenkel]

Ik gok dat het te maken heeft met het feit dat zo'n header maar één keer per verzoek mag worden ingesteld, en voor de server maken (als het goed is) de hoofdletters niet uit. Je zou locale-afhankelijke vergelijkingen kunnen gaan doen om te controleren of de strings hetzelfde zijn, maar deze headers zijn normaal US-ASCII dus dan werkt een to_lower() net zo goed, dat is ook nog eens een stuk sneller.

Wat je wilt voorkomen is dat één stuk code de Content-Length-header instelt, en een ander stuk code de content-length-header. Dan ga je ongeldige HTTP-verzoeken sturen en daar worden servers vaak niet zo blij van. Ook kunnen dat soort conflicten securityproblemen veroorzaken als je data ontvangt (denk aan een buffer waarvan de grootte is bepaald op basis van Content-Length en een lees-operatie die de content-length header pakt, dan schrijf je zo voorbij je buffer!). Dit soort normalisatie kan je leven als browser een stuk makkelijker maken.

[Stukfruit]

Dus in het kort: ze doen dit om te voorkomen dat er door het toelaten van hoofdlettergevoeligheid meerdere headers voor hetzelfde kunnen bestaan?

Klinkt nog steeds als een hack, maar ik snap wel dat zoiets lange discussies op de programmeervloer kan geven.

[R4gnax]

Dus in het kort: ze doen dit om te voorkomen dat er door het toelaten van hoofdlettergevoeligheid meerdere headers voor hetzelfde kunnen bestaan?

Nee. Dit is een performance dingetje. Het voorkomen van dezelfde string-waarde in verschillende casings, doe je doorgaans middels het case-invariant vergelijken van strings. Maar dat is duur. Nog duurder is het feit dat je met verschillende collaties etc. te maken kunt hebben.
Dus wat je vaak ziet is dat dit soort data waar het binnenkomt meteen genormaliseerd wordt naar een vorm waar het in de hele rest van de applicatie direct op basis van de ruwe numerieke character waardes vergeleken kan worden. (Wordt ook wel een ordinal comparison genoemd.)

De viaduct koppellaag die er lowercase van maakte zat niet fout.
Maar de main HTTP/3 library in Firefox zelf, wel.

Deze probeerde een header afkomstig uit niet genormaliseerde input-data case-sensitive te behandelen en dat is 100% fout. HTTP headers zijn volgens specificatie case-insensitive. Content-Length; content-length; CONTENT-LENGTH; CoNtEnT-LeNgTh; etc. maakt niet uit. Betekent allemaal hetzelfde.

[Reactie gewijzigd door R4gnax op 23 juli 2024 04:10]

[GertMenkel]

Ik weet niet of het de reden is, maar het is een reden om zoiets te doen als je met webapplicaties werkt. Ik heb het zelf ook moeten doen, omdat sommige clients headers om de een of andere stomme reden gingen herhalen. HTTP is mooi en schoon, maar implementaties ervan vereisen helaas vaak vieze string-bewerkingen om de boel vloeiend werkend te krijgen.

Ik zou persoonlijk zo'n standaardheader eerder als enum opslaan of iets dergelijks aangezien het hier alleen om interne code gaat, maar van wat ik begrijp van deze bibliotheek kan de code in de toekomst ook gebruikersinvoer gaan verwerken en dan kom je er helaas waarschijnlijk niet mee weg (vanwege de X-bedenk-wat-leuks-headers voor websites die de standaarden volgen).

[GertMenkel]

Ik vind het een beetje jammer dat ze Google hier onder de bus te gooien. Ik snap dat ze liever willen weten wanneer Google hun HTTP-standaarden aanpast, maar het was toch echt een fout in de browser die dit probleem veroorzaakte. Ieder ander browsercomponent dat met het internet praat had deze fout kunnen veroorzaken.

Als je zelf per se je eigen protocollen wil kiezen, moet je geen managed load balancer afnemen, vind ik. Het hele idee van deze GCP-dienst is voor zover ik weet dat Google dit soort dingen voor je afhandelt zodat jij je kan focussen op het online houden van je servers.

[Reactie gewijzigd door GertMenkel op 23 juli 2024 04:10]

[rubenvb]

Het enige wat je Google kan verwijten is de specificaties van een dienst onaangekondigd wijzigen. Voor hetzelfde geld heb je geen HTTP/3 ondersteuning voor jouw use case.

De grote rode vlag hier blijft in mijn ogen dat de hele browser compleet blokkeerde op een (optionele) extra service. Dat lijkt me gewoon niet OK.

[GertMenkel]

Nou ja, als je client geen HTTP/3 praat dan zal er ook niets veranderen aan de clientkant zolang je client een beetje competent geschreven is. HTTP/3 wordt pas gedaan als een DNS-query van type HTTPS lukt, of als de nodige upgrade-headers in een HTTP 1- of HTTP/2-verzoek worden gehonoreerd. Je praat niet per ongeluk over UDP o.i.d.

Dat de browser blokkeert snap ik ergens wel. Als browser wil je een wachtrij met verzoeken hebben om cache en andere zaken enigszins snel af te kunnen handelen, en als er een aantal verzoeken in die rij een oneindige lus starten, gaat het gewoon mis. Je kunt niet voor elk verzoek een nieuwe (green) thread starten, de overhead zou veel te groot zijn voor de vele kleine verzoeken die een moderne webpagina doet bij het laden. Daarvoor is een threadpool toch een stuk efficiënter, lijkt me.

Het enige dat ik ze kan aanrekenen is dat bij de nodige automatische tests dingen als hoofdlettergevoeligheid niet mee werden genomen. Hopelijk doen ze dat nu wel.

[Jorick]

Het zou niet uit moeten maken of Google nou HTTP1. HTTP/2 of HTTP/3 gebruikt want bij alle versies staat in de HTTP-specificaties dat velden (waaronder dus headers) niet-hoofdletter gevoelig zijn. Dus al had Google deze wijziging van tevoren aangekondigd dan is de kans vrij groot dat Mozilla alsnog tegen dit probleem aan was gelopen omdat dat deel van de code niet conform de specificaties is geschreven en niet afdoende was (of is) getest.

[R4gnax]

De grote rode vlag hier blijft in mijn ogen dat de hele browser compleet blokkeerde op een (optionele) extra service. Dat lijkt me gewoon niet OK.

Dit. Zo - Erg - Dit.

Waarom, oh waarom draaien alle netwerk-connecties binnen Firefox binnen één en dezelfde thread - zoals deze in het artikel genoemd wordt: 'the socket thread' ?

Dat heeft nogal wat beveiligingsimplicaties als er ooit een buffer-overflow aanval met RCE op niveau van de networking stack plaatsvindt, heh jongens? Process isolation van individuele browser tabs of document origins gaat dan weinig meer beginnen...

[likewise]

Maar met Rust is die laag toch vast volledig safe?

(geen idee)

[R4gnax]

Maar met Rust is die laag toch vast volledig safe?

(geen idee)

De networking stack, Necko, is C++.
Via de lijmlaag genaamd viaduct kunnen moderne in Rust geschreven componenten die gedegen gecompmentaliseerd zijn, tegen Necko praten en ermee werken.

Dat is nodig omdat Necko zelf een teringbende aan dependencies; global shared state; thread-bound state; single-threadedness; en andere rommel is wat al jaren een hoofdpijn dossier is voor Mozilla. Je kon vroegâh - weet niet of het nog steeds zo is - bijv. maar één instance van Necko aanmaken per proces. En deze kon niet draaien zonder ook een user-profile - een Firefox profile welteverstaan - vanaf disk in te laden en te gebruiken.

[Reactie gewijzigd door R4gnax op 23 juli 2024 04:10]

[GeroldM]

Omdat multi-threaded programmeren een stuk moeilijker is? En je dan ineens een sloot meer situaties moet ondervangen omdat data van de ene thread wel correct moet zijn om door een andere thread te kunnen worden gebruikt. Kortom overhead.

Logisch gezien heb je met je post gelijk, daar niet van. Je bent waarschijnlijk niet bekend met de implicaties, waardoor het gelijk een stuk makkelijker is om je post te schrijven.

Die overhead waar ik over sprak, dat kan de boel ook behoorlijk vertragen. Daarnaast is het ook nog eens zo dat als je de netwerk-stack van Microsoft gebruikt, je zowieze aan limieten gebonden bent. En als het gaat over netwerk communicatie, dan gebeurt dat over het TCP protocol. Een heel oud protocol wat maximaal 30 seconden wacht voordat het een bepaalde connectie als 'niet bestaand' beschouwd.

Kan je nog zoveel threads hebben lopen, zit er eentje bij die daarwerkelijk 30 seconden moet wachten, dan is de kans enorm hoog dat alle threads 30 seconden moeten wachten. en overstappen op het UDP protocol, dat is een heel ander 'blik met wormen'.

[R4gnax]

Logisch gezien heb je met je post gelijk, daar niet van. Je bent waarschijnlijk niet bekend met de implicaties, waardoor het gelijk een stuk makkelijker is om je post te schrijven.

(Grinnikt.) Ik heb ondertussen tegen de 15jr ervaring als full-time software-engineer; daarvoor nog een jaar of 5 deeltijd. Ik weet echt wel dat multi-threading overhead met zich meebrengt. Tegelijkertijd heb je daar ook heel goede oplossingen voor. Met basale producer-consumer queues die op een read/write lock draaien en een serie persistent threads die via een interne threadpool gemanaged worden kom je al een heel eind.

Die overhead waar ik over sprak, dat kan de boel ook behoorlijk vertragen.

Overhead heb je alleen als je continu threads a/h synchroniseren bent met locking primitives of continu threads en execution contexts aan het wisselen bent. Er zijn degelijke, robuuste asynchronous unit-of-work patronen die dat nou juist zoveel mogelijk proberen te vermijden. Daarnaast hebben we het hier niet over zeer onvoorspelbare workloads; of over tijdskritieke workloads die in de orde van <1ms variantie mogen hebben.

Daarnaast is het ook nog eens zo dat als je de netwerk-stack van Microsoft gebruikt, je zowieze aan limieten gebonden bent.

Nou; dan is het maar goed dat Firefox dat dus niet doet, heh? Ze maken hoogstens gebruik van de lagere socket primitives en TCP/UDP, maar het overgrote deel van de network stack wordt vermijdt. Ja; er zijn inderdaad ook op TCP niveau wat limieten. De belangrijkste is niet meer als 10 concurrent half-open connecties op een consumenten versie van Windows.

En als het gaat over netwerk communicatie, dan gebeurt dat over het TCP protocol. Een heel oud protocol wat maximaal 30 seconden wacht voordat het een bepaalde connectie als 'niet bestaand' beschouwd.

TCP is vastgelegd in RFC-793 die geen maximale bound voor een connection timeout (formeel: retransmission timeout) geeft. Sterker nog de specificatie stelt dat deze timeout vanwege fluctuatie in netwerksnelheid; betrouwbaarheid; en beschikbaarheid; altijd dynamisch bepaald moet worden. De formules die hieraan ten grondslag liggen in de specifieke implementatie in Windows komen, als je ze doorrekend op - ik dacht - ongeveer 25 seconden gemiddeld uit? Misschien dat daar je 30 seconden mythe vandaan komt? (O.a. RFC-5482 biedt trouwens mechanismen aan waarmee beide kanten van de verbinding elkaar over hun actieve timeout waarde kunnen informeren om zo de connectie beter af te stemmen in gevallen van bijv. hoge congestie.)

Dit is overigens totaal anders dan de connection timeouts waar een applicatie zelf grip op heeft, bijv bij het opzetten van een TCP connectie die hierbij eerst in een zgn half-open state terecht komt; totdat ook de server antwoord heeft gegeven - en die in een half-closed state terecht komt als de connectie vanaf de client gesloten wordt; totdat ook de server dit bevestigd heeft.
Applicaties kunnen zelf een veel lagere timeout instellen dan de OS implementatie afdwingt en de meeste zullen dat uit voorbehoud ook doen. (Volgens mij was het maximale timeout venster voor half-open/-closed connectie wat Windows maximaal toestaat, serieus lang -- dat zou iets van in de meerdere dagen zijn had ik ergens vernomen.)

Kan je nog zoveel threads hebben lopen, zit er eentje bij die daarwerkelijk 30 seconden moet wachten, dan is de kans enorm hoog dat alle threads 30 seconden moeten wachten.

Juist niet; als het echt gescheiden units of work zijn en de interruptie zit aan de kant van de wederpartij (de server) dan zal jouw andere netwerkverkeer richting andere partijen daar niet intrinsiek door gehinderd worden; tenzij je dus alle afhandeling van netwerkverkeer op één thread parkeert en serieel afhandelt. Dan heb je maar één blokkerende socket nodig (of bijv. bug die voor een infinite loop zorgt - zoals hier bij Firefox) en wordt alles opgehouden.

en overstappen op het UDP protocol, dat is een heel ander 'blik met wormen'.

(Psst. HTTP/3, waar het hier om draait, is niet meer gelaagd bovenop TCP maar op UDP.)

[Reactie gewijzigd door R4gnax op 23 juli 2024 04:10]

[rob12424]

Ze gooien niemand onder de bus. Dat is een conclusie die jij eruit trekt. Ik zie vooral openheid en ook dat ze zelf helemaal uitleggen wat er gebeurt is en hoe ze dit in de toekomst willen voorkomen.

Zoveel openheid zie je helaas niet veel als er iets mis gaat.

[Nightan]

Wat wordt er verstaan onder 'het beheren van certificaten door GCP'?

[uiltje]

Waarschijnlijk hebben ze de root certificate store op een veilige plek neergezet (qua integriteit en vooral availability, confidentiality is niet echt een ding voor public certs).

[Nightan]

Okay dankjewel, dat zou kunnen. Ik stelde mijn vraag aangezien Firefox een van de weinige browsers is met een eigen certificate store. Chrome op Windows kijkt bijvoorbeeld naar de store van het OS.

Daarnaast heeft Mozilla hun eigen root certificate programma waar sommige Linux distros ook gebruik van maken. Google (Chrome) heeft ook een eigen certificate programme. Dit zijn de lijsten waar alle vertrouwde publieke CA's a la DigiCert in staan.

[watercoolertje]

Volgens mij moet het titel als volgt zijn gezien het probleem helemaal niet door Google komt.

Firefox-verbindingsproblemen kwamen door fout in library en werd zichtbaar door Google-wijziging

Wel is het handiger dat dat soort zaken aangekondigd worden dan had FF inderdaad misschien hun eigen fouten eerder kunnen verhelpen.

[Reactie gewijzigd door watercoolertje op 23 juli 2024 04:10]

[Mitsuko]

De code is inmiddels overigens aangepast om die hele Content-Length check niet meer uit te voeren (bug 1750587, live in Firefox 98), want het was sowieso nogal dom om die blind te vertrouwen (en daarnaast is het theoretisch mogelijk dat de string "Content-Length:" ergens anders in de headers voorkomt).

[Reactie gewijzigd door Mitsuko op 23 juli 2024 04:10]

[R4gnax]

De code is inmiddels overigens aangepast om die hele Content-Length check niet meer uit te voeren (bug 1750587, live in Firefox 98), want het was sowieso nogal dom om die blind te vertrouwen (en daarnaast is het theoretisch mogelijk dat de string "Content-Length:" ergens anders in de headers voorkomt).

Dat was inderdaad sowieso een grandioos grote vector voor malafide partijen die er een DoS mee konden bekokstoven. En dat ze niet eens de headers daadwerkelijk correct door een parser heen haalden maar gewoon keken of er ergens een stukje string in zat wat leek op 'Content-Length : <x>' was helemaal knetter.

[rob12424]

Ik zou zeggen. Het is opensource. Neem de code even door, breng verbeteringen aan. Zijn zij ook blij

[Emiel L]

Mozilla zegt nu in contact te zijn met Google om dergelijke onverwachte veranderingen te voorkomen.

Dus omdat de ontwikkelaars bij firefox de boel niet goed testen, moet Google geen dingen meer aanpassen. Beetje omgekeerde wereld...

[Wouterie]

Het woordje 'onverwacht' verklapt al een beetje waar ze naar verwijzen natuurlijk. Niet dat Google niets mag doen, niet dat ontwikkelaars geen fouten maken, maar dat wijzigingen netjes aangekondigd worden zodat het wat makkelijk troubleshooten is wanneer het niet werkt.

[R4gnax]

Het woordje 'onverwacht' verklapt al een beetje waar ze naar verwijzen natuurlijk. Niet dat Google niets mag doen, niet dat ontwikkelaars geen fouten maken, maar dat wijzigingen netjes aangekondigd worden zodat het wat makkelijk troubleshooten is wanneer het niet werkt.

Onzin. Iemand bij Mozilla had de instelling voor HTTP/3 ondersteuning op hun GCP load balancer gewoon op de standaard instelling 'Automatic' laten staan. Wat dus ook gewoon betekent "doe maar wat standaard is." Ze zijn daarmee akkoord gegaan met het feit dat Google dit gewoon op elk moment kon wijzigen. Hadden ze dit niet gewild of aangedurfd, hadden ze die instelling gewoon op 'Off' / 'Disabled' / etc. kunnen en moeten zetten.

Je bent een professional; en er is een uitgebreidde handleiding. Je hebt geen excuus. RTFM.

Het is heel vals dat ze hiervoor de zwarte piet richting Google proberen te spelen, want ze hebben het zelf gewoon verkloot.

[Reactie gewijzigd door R4gnax op 23 juli 2024 04:10]

[jmvdkolk]

Ik vind het heel knap als alle instellingen niet op 'Automatic' staan. Heel vaak is zelfs aangeraden door componentenleveranciers om dingen op 'Automatic' te laten staan. Het is bijvoorbeeld door Microsoft aangeraden om bij SMTP connecties de security op 'Automatic' te laten staan. Dit om te zorgen dat je automatisch de beste security krijgt. Als je die zelf een aantal jaren geleden op TLS1.1 had gezet dan krijg je niet vanzelf de verbeteringen mee van TLS1.2 en TLS1.3.

[uiltje]

Als alles zonder meer goed werkt dan heb je gelijk. Maar zo zit de software wereld niet in elkaar. Ook als je na veranderingen zelf geen problemen verwacht dan kan je ze nog steeds aankondigen - wel zo netjes. Zeker als cloud provider waar je per definitie high availability aan je klanten wilt leveren.

[Wouterie]

Ah, dus de instelling 'automatic' ontslaat een leverancier of dienstverlener van het verstrekken van changelogs en een beetje communicatie vooraf? Volgens mij proberen ze helemaal niet de schuld in de schoenen van Google te schuiven en zijn ze open over hun eigen falen. Alleen had het troubleshooten een stuk sneller kunnen verlopen als ze wisten wat er gewijzigd was. Het is net als bij elke evaluatie van dit soort 'rampen' dat je zelden kunt zeggen dat er maar één partij schuldig is aan de impact van de ramp. Ja, Mozilla had dit kunnen voorkomen maar door de slordige communicatie van Google heeft het zo groot kunnen worden.

[elmuerte]

Dat is een beetje het risico van experimentele protocollen te gebruiken.

[Kimbo72]

Ik kan nog steeds niks downloaden met Firefox.

Dan moet ik eerst bij probleem oplossen een herstart doen.

Erg vervelend.

[SubSpace]

Viaduct was dus helemaal niet het probleem, maar de lower level HTTP/3 code, want HTTP headers horen case insensitive te zijn... Anders dan wat de eerste paragraaf suggereert, is het vervangen van hoofdletters door kleine letters dus geen bug, maar hooguit "enigzins ongewenst" gedrag. De bug is dat Necko er niet mee overweg kon.

Om Google half de schuld te geven gaat wel erg ver. Firefox had ook gewoon een oudere versie van HTTP kunnen gebruiken zolang ze nog geen goed geteste HTTP/3 implementatie hebben.

[Reactie gewijzigd door SubSpace op 23 juli 2024 04:10]