Mozilla schakelt ondersteuning voor verouderde tls 1.0 en 1.1 weer in in Firefox

Mozilla schakelt ondersteuning voor de verouderde tls 1.0- en tls 1.1-protocollen in Firefox weer in, nadat het die eerder had verwijderd. Het bedrijf wil op die manier overheidswebsites tijdens de coronapandemie bereikbaar houden die nog steeds van de oude protocollen gebruik maken.

Mozilla zet de wijzigingen in de release notes van Firefox 74.0. Die versie kwam anderhalve week geleden uit. Het was de eerste versie van Mozilla waarbij ondersteuning voor tls-versies 1.0 en 1.1 werd uitgeschakeld. Websites die gebruikmaken van oudere protocollen dan tls 1.2 en 1.3, waren vanaf dat moment niet meer te bezoeken in Firefox. Gebruikers kregen dan een error-pagina te zien met een knop om nieuwere tls-versies te forceren. Inmiddels zijn die verandering teruggedraaid, zegt Mozilla. "We doen dat voor onbepaalde tijd om voor betere bereikbaarheid te zorgen van overheidswebsites die covid-19-informatie plaatsen", schrijft het bedrijf.

Tls 1.0 en tls 1.1 zijn al lange tijd achterhaald. Eerder dit jaar begonnen naast Mozilla ook Apple, Google en Microsoft het protocol uit te faseren in browsers Safari, Chrome en Edge. Welke overheidswebsites er op dit moment nog gebruikmaken van tls 1.0 en 1.1, is niet bekend. Het protocol wordt nog maar weinig gebruikt.

Reacties (49)

Levert dit die cannot-connect pagina's op? Had ik net in FF met Microsoft NL ....

Update. 21/3. Het was dus in FireFox op een downloadpagina van Microsoft Teams, de eerste google hit. Het zal een tijdelijk probleem geweest zijn want de pagina's die ik nu zie in google werken allemaal. De US pagina werkte gisteren wel goed.

Het was overigens een foutpagina zonder blauwe knop dus toch net iets anders.
Melding opgezocht in de cache:
SSL_ERROR_INTERNAL_ERROR_ALERT

Overigens zie ik ook dat andere foute pagina's het nu weer doen, van bv een pagina op een site van mijn werk. Het kan zijn dat er iets gewijzigd is maar ik heb geen aanpassingen gedaan. Ik verwachtte een 74.0.1 die het automagisch zou oplossen

[Reactie gewijzigd door zaadstra op 21 maart 2020 10:05]

Nee. Je krijgt een melding met knop of tls 1.0 en 1.1 weer in te schakelen.
Wel wordt er uitleg gegeven en wordt er gezegd dat support definitief stopt. Het is dus niet onmogelijk de site te bezoeken.

microsoft.com gebruikt zo te zien TLS 1.2; dus los van dat de betreffende foutmelding in Firefox veel duidelijker is dan dat, zou dat niet de oorzaak mogen zijn

Het kan aan je eigen instellingen liggen. In Edge kun je bijvoorbeeld zelf TLS 1.2 hebben uitgeschakeld. Als je dan een site bezoekt die TLS 1.2 afdwingt, en als die site geen fallback toestaat, kun je een dergelijke melding krijgen.
Omgekeerd kan overigens ook, maar lijkt me in geval van de Microsoft site erg onwaarschijnlijk

Goed besluit van Firefox lijkt mij! Echter, waarom zijn er dan nog steeds blijkbaar zo veel (overheids)websites die nog op sterk verouderde versies draaien???

https is pas sinds vorig jaar verplicht voor overheidssites. Gemeenten moeten vaak al bezuinigen op vanalles, en dan lijkt investeren in een website niet het meest cruciale punt, omdat dit vaak outsourced moet worden.

Dit speelt al heel lang. Zie bijvoorbeeld https://www.frankwatching...bsites-vaak-te-duur-zijn/ (2011)

“De kosten van de procedure zijn soms bijna een derde van de waarde van de opdracht zelf”

edit:

Zie ook https://www.frankwatching...es-niet-taakgericht-zijn/ (2012)

[Reactie gewijzigd door Redsandro op 20 maart 2020 19:26]

DigiD verplicht in de audits dit jaar wel TLS 1.2, dus het gaat de goede kant op.

Verplichten is één ding, uitvoeren is een tweede...

Als jij niet aan die verplichting voldoet als gemeente, hangt Logius vrij rap aan de telefoon.

En zetten ze 3 maanden na constatering de dienst uit. Dus dat is bijzonder vervelend in zo'n tijd

Alleen veel overheidssites, met name de kleinere gemeentes, doen hun DigiD afdeling op een aparte site. Waardoor de DigiD audit enkel over die aparte site gaat en de "hoofd" site voor de informatie voorziening dus achter kan blijven.

je kunt je alleen afvragen wat gemeenten met eigen servers moeten iedere it-consultant zal al minimaal 10 tot 15 jaar geleden hebben aangedrongen op managed-vps servers voor de hosting van dat soort sites.

Dat de hele digiD-omgeving daar los van staat doet nauwelijks ter zake ... enerzijds omdat dat een heel ander verwachtingspatroon biedt en anderzijds omdat de veiligheid het vergt. je kunt dan tegelijkertijd zeggen dat het bij digiD veel meer van belang is om software zolang mogelijk stabiel en bekend te houden, maar aan de andere kant eist het steeds de laatste en beste beveiligingsmethodes door de vertrouwelijkheid van de data.

Daar tegenover staat een simpel CMS waar gemeenten informatie over huisvuil, bouwvergunningen en dergelijke kunnen plaatsen. Die sites hallen al lang naar de laaste versie van IIS, of Apache gezet moeten worden.

Dat vind ik interessant... Je zou toch zeggen dat een website van overheid of een gemeente juist veilig moet zijn en daar op vooruit moet lopen. Ik snap wel dat alles geld kost, maar laten we nou eerlijk zijn, dit soort dingen zijn vandaag de dag echt niet meer de kosten.

edit: Interessant artikel, dat ga ik eens doornemen!

[Reactie gewijzigd door Bose321 op 20 maart 2020 19:20]

Volgens de richtlijnen moeten overheidsinstellingen in NL minimaal TLS 1.2 gebruiken. Ik gok dat dit meer voor andere landen geld.

YUP DUITSLAND.
Al langer ook , maar ook daar is handhaving en uitvoering uhum.
Ben overigens jaren terug al aan het stoeien geweest met de reg settings in Microsoft producten om default tls 1.2 als first af te dwingen.

Moet je ook best oppassen welke "versleutelings protocollen" je al dan niet schakelt, kwam nog zo'n oude testmachine tegen daar werken sommige sites met edge niet meer en niet om tls versie maar daarom.

De fouten kan je dan in de log files terug vinden.

[Reactie gewijzigd door jahoorisieweer op 21 maart 2020 13:21]

Inderdaad onbegrijpelijk dat er nog sites bestaan die op tls 1.0 of 1.1 draaien. Meestal is het slechts een kwestie van wat configuratie om alleen 1.2 en hoger in te schakelen.

Nee hoor. Soms is het ook een gevallentje van moeten. Wij hebben bijvoorbeeld klanten met verouderde Android devices zonder TLS1.2 ondersteuning, dan is het al gauw lastig om TLS1.0 uit te schakelen.

Dat is toch geen reden om TLS 1.2 níet te ondersteunen?

Voor zover ik weet kunnen servers meerdere TLS versies ondersteunen, zodat ze compatibel zijn met clients die alleen TLS 1.0 (oude Android versies) of TLS 1.2 (nieuwe Firefox versies) ondersteunen.

Correct me if I'm wrong...

Als je meerdere TLS versies ondersteunt op je backend, kunnen kwaadwilligen toch proberen de "slechtste" versie te gebruiken (dus bijvoorbeeld in dit geval forceren dat de verbinding over TLS 1.0 loopt, ook al ondersteun je 1.2), en bijgevolg de kwetsbaarheden die in het verouderd protocol zit misbruiken?

't Is een best practice om je TLS-instellingen zo in te richten dat browsers de best beschikbare versie gebruiken; daar zijn zelfs wat protocollen voor om te voorkomen dan ze toch een lagere gebruiken. Kwaadwillenden kunnen dan wel zelf kiezen voor TLS 1.0, maar in principe niet andere gebruikers daartoe dwingen.

Al met al is dat niet helemaal triviaal, mede doordat soms beveiligingslekken bekend worden en je dan een afweging moet maken om bepaalde delen (zoals specifieke ciphers) van het protocol uit te schakelen of 'naar achteren' te plaatsen.

Klopt, maar het ondersteunen van oudere versies van TLS in moderne browsers is alleen nodig als een site geen TLS1.2 ondersteund en dat is waarschijnlijk waar @Soultaker op doelt, als je oudere TLS versies moet ondersteunen wegens legacy, kun je voor moderne browsers nieuwe versies aanbieden.

Ja, maar dat zou een argument zijn om alléén TLS 1.2 te ondersteunen, niet om alléén TLS 1.0 te ondersteunen, waar sprake van was in de reactie waar ik op reageerde. Als de uitgangssituatie is dat je server alleen TLS 1.0 ondersteunt, dan lijkt het me een strikte verbetering om óók TLS 1.2 te ondersteunen.

Het klopt dat het beveiligingsniveau dan strikt genomen niet beter is dan TLS 1.0, maar in ieder geval werkt je site dan ook met clients die alleen TLS 1.2 ondersteunen.

(Sowieso lijkt me dat een goed beginpunt om van TLS 1.0 naar 1.2 te upgraden, want als je beide ondersteunt, kun je zien welk percentage van je gebruikers 1.2 prefereert. Als dat percentage dicht genoeg bij de 100% ligt kun je er voor kiezen om TLS 1.0 uit te zetten.)

Nu ik @Michaelr1's reactie nog eens lees, zei hij ook niet dat hij TLS 1.2 niet wilde inschakelen. Alleen dat hij TLS 1.0 niet wilde uitschakelen. Dat klinkt dus wel logisch.

[Reactie gewijzigd door Soultaker op 21 maart 2020 01:22]

verouderde android devices, misshien moet je dan even op mm.nl kijken naar de nieuwe galaxy A10 of een vergelijkbaar toestelletje van nokia of xiami of...

Als gemeente werk je met data van burgers die erop moeten vertrouwen dat je weet wat je aan het doen bent. ze zijn wettelijk verplicht die data te geven, dan kun je er op zijn minst fatsoenlijk mee omgaan door je beveiliging op orde te houden!

Beroepsmatig heb ik met iets soortgelijks te maken. Toch hebben wij er al een tijd geleden voor gekozen om TLS 1.0 en 1.1 uit te schakelen. En ook om niet meer door de fabrikant ondersteunde browsers als Internet Explorer niet langer te ondersteunen, maar een melding te tonen dat het onveilig is om deze nog te gebruiken. Op die manier gedragen wij ons als een verantwoordelijk leverancier en proberen we de gebruikers te motiveren om over te stappen naar modernere devices en browsers.

[Reactie gewijzigd door BamSlam_ op 22 maart 2020 15:22]

Het zal eerder zijn omdat het product dat ze gebruiken van lang geleden dateert en een oude ingebouwde openssl library heeft van voor de tijd dat tls 1.2 uitgevonden was. Kan ook de ingebouwde webinterface van een apparaat zijn (printer, server, ...). Dat is ook een "site".

Dan gebruik je iets als stunnel, haproxy of nginx als TLS 1.2 front-end. Die kan vervolgens webverkeer doorzetten naar oude SSL/TLS versies of een pure HTTP site. Kunnen ze meteen gepaste security headers toevoegen richting de browser.

[Reactie gewijzigd door The Zep Man op 21 maart 2020 06:21]

Daar noem je op zijn minst 7 begrippen, waarvan op het gemiddelde gemeentehuis, niemand weet wat ze überhaupt maar betekenen. Het probleem is niet dat het allemaal te ingewikkeld is. Het probleem is gewoon dat de kennis er niet is en het uitbesteden duur is.

Sterker je bent dat soort bedrijven en instellingen dan vaak ook snel als klant kwijt , want ze zijn up to date en "volledig" veilig "schreeuwen" ze dan.

Tja vooral dat soort termen als "volledig" zegt dan al weer genoeg.

SSL 3.0 toelaten komt zelfs heel soms nog voor vooral bij mail.

[Reactie gewijzigd door jahoorisieweer op 21 maart 2020 13:25]

Daar noem je op zijn minst 7 begrippen, waarvan op het gemiddelde gemeentehuis, niemand weet wat ze überhaupt maar betekenen.

Daar hebben gemeenten toch IT-ers voor?

Woensdag nog bij een klant gezien, nieuw alarmmeldingssysteem werd opgehangen, publiek aan internet. Telnet voor console toegang en webinterface met SSL 3.0. Welkom in 2020.

Dan dienen die devices te worden bijgewerkt danwel vervangen.

In websites voor consumenten heb je daar gelijk in, maar vergis je niet hoeveel stokoude meuk er in de b2b wereld nog gebruikt wordt. Ik ben nu met een migratietraject bezig naar TLS 1.2 en van de 10 partners waar ik tot nu toe mee gewerkt heb moesten er 10 van alles upgraden om naar TLS 1.2 te kunnen.

Die upgrades zijn lang niet altijd simpel. Een Java VM kun je wel zomaar upgraden, maar de applicatie die daarop draait kan dan stuk gaan en de leverancier is al jaren geleden falliet gegaan, het support contract is verlopen of ze hebben gewoon geen nieuwe versie die op een recente JVM kan draaien.

Is dat slecht: Ja, zeker, maar het is ook de realiteit. We moeten dan kiezen tussen TLS 1.1 ondersteunen of betalende klanten verliezen.

Toch blijf ik zo'n benadering van it assets raar vinden. Lease auto's worden gewoon vervangen, als.ze nog rijden. Als machines afgeschreven zijn, vrijwel altijd ook.

Onderhoud van gebouwen, hele delen van installaties worden vervangen.

Maar dat geldt nauwelijks voor software...

Omdat iters vaak een correct antwoord proberen te geven op de vraag waarom dingen moeten. En met correctheid komt nuance. En de combinatie nuance en technische termen is fakking saai voor accountants. Dus nee, geen geld voor hoor doei met je rare praatjes. Pfff, mafkees.

Ik vind je reactie niet netjes en nogal overboord.

Het punt staat. Bijna alle assets in een bedrijf worden beter onderhouden dan de it assets. Terwijl die nog belangrijker zijn in veel bedrijven dan al het andere.

Ik hoef bijvoorbeeld niet op kantoor te komen om mijn werk te doen, en met mij velen. Dankzij it.

Tja ze zijn minder secure, maar ik heb ze gewoon nog aanstaan voor een website waar wat statische content op staat. Integrity van die data is niet van belang, waarbij avalability dat wel wat meer is.

Helemaal geen goed besluit wat mij betreft. Overheden moeten hun zaken op orde hebben, dat is namelijk wat diezelfde overheid van ons ook verwacht. TLS1.2 is niet iets van het laatste jaar. Persoonlijk vind ik het zwaar belachelijk dat eindgebruikers de beveiliging omlaag moet schroeven teneinde overheids diensten te kunnen bezoeken. De overheid moet maar zorgen dat gebruikers veilig hun diensten kunnen bezoeken. En zeg nou niet 'maar ze hebben nu wel wat anders aan hun hoofd', de IT dienst daar is vast niet heel druk met corona, en bovendien hebben ze al jaren de tijd gehad. Nu wint de lakse overheid het weer van de veiligheid. En in NL al heel zeker, hier is geld zat. Maar eigenlijk is er gewoon geen excuus meer om nu nog met enkel TLS1.0 en/of 1.1 aan te komen.

[Reactie gewijzigd door Rataplan_ op 20 maart 2020 20:09]

De Nederlandse overheid heeft dan ook gewoon TLS 1.2 op zo ongeveer iedere gangbare website. Maar de wereld is groter dan Nederland, of de westerse wereld in het algemeen. Er zijn veel overheden in Afrika, Centraal Amerika, Zuid Amerika, Azië en zelfs delen van Europa die echt wel andere prioriteiten hebben dan de TLS versie omhoog schalen, landen waar ook absoluut geen ruimte over is om een IT budget op te schalen. En de mensen in die landen moeten ook informatie over een pandemie kunnen benaderen van hun overheid.

Goed besluit van Firefox lijkt mij! Echter, waarom zijn er dan nog steeds blijkbaar zo veel (overheids)websites die nog op sterk verouderde versies draaien???

Omdat Firefox internationaal is en er meer overheden zijn dan de Nederlandse. Niet elk land zal hier even veel kennis, resources en prioriteit voor hebben.

Idd verbazingwekkend wat er zoal veroudert draait. Maar veel van die sites zijn ooit opgezet icm content systeem e/o koppelingen met andere it systemen. Voor jou en mij zou het eenvoudig zijn om (alleen) de webserver te updaten of de config file aan te passen zodat we de oude tls niet meer gebruiken. Maar voor veel organisaties is het niet een server(cluster) waarvan je eenvoudig de webserver van kan updaten maar is het een 'black box' of appliance die door de originele leverancier bijgewerkt zou moeten worden. Maar als het originele project is afgesloten en er geen 'update/upgrade' abonnement is afgesloten (of is verlopen) dan blijft alles doordraaien as-is totdat het fout gaat....

Het slaat nergens op wat Mozilla doet.

Vaak weten de eigenaren van overheidssites al lang dat de sites niet werken met nieuwere browsers. Ik ken zelfs sites die een hele tutorial aanbieden om je Firefox te downgraden naar versie 56, zodat de site nog werkt. Sommige overheidssites blokkeren standaard nieuwe Firefox versies, ook al heb je TLS1.0 erop geactiveerd.

De webmasters zijn gewoon koppig. Eigenlijk zouden ze vanuit de EU moeten verplichten dat overheidssites werken met de nieuwste browsers.

[Reactie gewijzigd door Rex op 20 maart 2020 21:35]

Heb je voorbeelden?

Geen Nederlandse voorbeelden, maar wel een boel buitenlandse.. Dit is de tutorial voor de downgrade van de Spaanse Royal Mint. De Spaanse belastingdienst werkt niet met Chrome 42 of hoger.

De wereld is groter dan Europa, niet ieder land heeft de mogelijkheid om consistent met de techniek mee te gaan.

Chrome is ondertussen bezig om wijzigingen uit te rollen mbt het SameSiteCookie. Ik heb hier al een zorg applicatie op zien falen. Dit gaat geheid ook problemen opleveren.

Volgens mij zijn de sites daardoor zelf wel bereikbaar, maar werkt bijvoorbeeld een hotjar, google Analytics of een chat invoegtoepassing niet.

Er kan van alles mis gaan als een site dit niet heeft aangepast. Om te beginnen de authenticatie. Wat mij betreft moet Google dit nu niet willen doen. Ze kunnen best een paar maanden wachten net zoals Firefox.

Het kan wel degelijk allerlei bijeffecten hebben. Denk bijvoorbeeld aan cookies in iframes, bijvoorbeeld voor SSO of een aanvullende feature, wat mogelijk nu niet meer werkt.

Wat ik in heel veel van deze berichtgeving mis (ook aan de bron!) is het onderscheid tussen "TLS 1.0 of TLS 1.1 gebruiken" en "geen TLS 1.2 gebruiken".

Ondertussen heb ik fiat van hogerhand om TLS 1.0 en TLS 1.1 uit te schakelen (ze vinden de userbase eindelijk klein genoeg t.o.v. het risico), maar TLS 1.2 wordt al jaren ondersteund door de diensten die ik beheer. Voor de duidelijkheid, die diensten kunnen dus alle drie.

En ieder nieuwsbericht opnieuw moet ik op zoek gaan naar het antwoord op de vraag "en wat voor websites die alle drie doen?". Zoals in dit bericht de zin: "Websites die gebruik maken van oudere protocollen dan tls 1.2 en 1.3 waren vanaf dat moment niet meer te bezoeken in Firefox". Tja, mijn sites maken gebruik van die oudere protocollen als jouw client niet hoog genoeg komt...

Het lijkt mij logisch (en uit de rest van het bericht valt het in dit geval wel op te maken) wat er bedoeld wordt, maar het eerste bericht van Mozilla hierover maanden geleden was hier heel onduidelijk over, en browserbouwers doen wel vaker rare dingen.