Ook Google blijft tls 1.0 en 1.1 wat langer ondersteunen in Chrome

Na Microsoft en Mozilla heeft Google ook besloten om tls 1.0 en 1.1 iets langer te blijven ondersteunen. Het is niet officieel aangekondigd, maar de ondersteuningsstop is verschoven van Chrome 81, dat volgende week uitkomt, naar Chrome 83, dat eind mei uitkomt.

Dat blijkt uit de webpagina Deprecations and removals in Chrome 81, die ergens kort geleden aangevuld is met de tekst 'het verwijderen van tls 1.0 en tls 1.1 is vertraagd tot Chrome 83, die naar verwachting eind mei 2020 wordt uitgebracht'. Die aanpassing aan de planning lijkt ergens eerder deze maand gedaan te zijn. Chrome 81 staat gepland voor een release in de komende week. Versie 82 is wegens de coronacrisis geschrapt. Zo krijgt het ontwikkelteam een lastenverlichting.

Een lastenverlichting is wellicht niet de reden voor het uitstellen van het afscheid van deze tls-versies. Omdat Mozilla en Microsoft de zet al gemaakt hadden, plaatst dit Google in de nadelige positie dat het als enige van deze grote drie bepaalde sites weigert weer te geven. Google doet echter zelf geen uitspraken over het waarom van dit uitstel. Microsoft baseert het uitstel op de 'huidige wereldwijde omstandigheden' en Mozilla wil op die manier overheidswebsites tijdens de coronapandemie bereikbaar houden die nog steeds van de oude protocollen gebruik maken.

De grote browserbouwers kondigden in 2018 tegelijkertijd aan dat ze begin 2020 ondersteuning voor tls 1.0 en 1.1 gingen uitschakelen. Tls staat voor transport layer security en is een standaard voor de versleuteling van webverkeer. Tls 1.0 en 1.1 zijn verouderde webstandaarden die nog maar weinig gebruikt worden. De eerste versie van tls dateert van ongeveer twintig jaar geleden.

Reacties (39)

[CAPSLOCK2000]

Omdat Mozilla en Microsoft de zet al gemaakt hadden, plaatst dit Google in de nadelige positie dat het als enige van deze grote drie bepaalde sites weigert weer te geven.

Dit is een van de grote zwaktes van (IT-)beveiliging.

Beveiliging gaat altijd over dingen die onmogelijk worden gemaakt, dingen die niet meer kunnen en dingen die geblokkeerd worden. De meeste mensen hebben daar geen boodschap aan, die willen dat dingen wel kunnen, zeker als de reden voor de blokkade complex of moeilijk begrijpbaar is. Zo wordt beveiliging ervaren als een fout of storing. Ergens klopt dat ook wel, maar het probleem zit niet bij het product dat wel goed beveiligd is.

Het gaat fout als er een ander product (zoals een browser) is dat wel nog werkt omdat het minder goed beveiligd is. De meeste mensen concluderen dan dat het product dat niet werkt stuk is, en het product dat wel werkt goed is.
In dit geval zouden mensen concluderen dat Chrome stuk is, terwijl het eigenlijk de webserver is die een probleem heeft. In plaats van dat mensen Chrome en Google prijzen met het veilige beleid worden ze boos en klagen ze dat Chrome stuk is. Dat is nogal oneerlijk.

Het is een beetje als een wegpiraat die klaagt dat auto's die stoppen voor rood licht zo slecht zijn voor de verkeersdoorstroming.

[Zezura]

Als Chrome zijnde kan je het mensen in een scherm gewoon uitleggen.

En zo nodig een overgangsfase in acht nemen. Bijvoorbeeld om waarschuwing te geven met optie toch door te gaan.

[Sovjet]

Ja en nee, als je een eindgebruiker gaat vertellen dat TLS 1.0 niet meer veilig genoeg is etc, dan heb je twee scenario's:

1. Ja, boeien ik wil naar me site toe, gebruikt vervolgens andere browser.

2. Leuk, geen idee wat het is en dus klik ik maar door.

Soms moet je eindgebruikers gewoon een bepaalde hoek in duwen, dan dat de keuze bij hun blijft.

[erikmeuk3]

Als ik Google om welke belangrijke sites het gaat. Kom ik op .gov en .gov.uk sites uit.
De overheid van deze landen mag je natuurlijk niet belachelijk maken met een waarschuwing in de browser.
En voor zielige landen, hadden ze de maatregel niet terug gedraaid.

[Bensimpel]

En dan mogen ze hun zaken niet op orde hebben? Het is juist goed als ook die organisaties eens in een hoek geduwd worden. .Gov of niet zal niet eens uit moeten maken. Hup TLS 1.0 eruit.

[Zezura]

Effect wat je creeert is wel dat de sites gaan upgraden en je impact laag houd.

[Anoniem: 470811]

Al dat uitgestelde uitfasering op gebied van encryptie geeft maar aan hoeveel van de vitale infrastructuur (zorg, nuts, overheid) kennelijk nog gebruik maken van oude en onveilige protocollen.

[Pietervs]

Let wel: dit is natuurlijk wereldwijd.
Ik ga er vanuit dat in Nederland de zaken wel redelijk op orde zijn, zelfs binnen Europa zal het over het algemeen goed geregeld zijn.
Maar Azië? Afrika? Zuid- en Midden-Amerika? Dat is toch echt een stuk twijfelachtiger, imho.

[tweazer]

En wat dacht je van 3e wereldlanden waar de westerse wereld zijn spullen na afdanken naar exporteert ?

[SuperDre]

Ik denk dat je behoorlijk naief bent als je denkt dat hier alles wel op orde is.

[Pietervs]

Goed onderbouwd ook!

[dmantione]

Een informatiesysteem moet nu eenmaal vaak tientallen jaren mee, software is dusdanig duur, dat je het je niet kunt permitteren om iedere paar jaar een nieuw systeem te maken op basis van de nieuwste softwaretechnieken. Als je oude systemen bij de tijd kunt houden is dat natuurlijk ideaal, maar vaak ligt het ook daar ietsje genuanceerder. Ik vind niet dat we neerbuigend moeten doen over oude systemen. Niet ieder gebruik van een minder veilig protocol betekent direct dat je gegevens op straat liggen.

[oef!]

Verreweg de meeste software is tegenwoordig web based en daardoor staat de ssl/tls beveiliging los van de applicatie zelf.

En anders kun je er een reverse proxy voortzetten zoals @The Zep Man ook al zegt.

[Killemov]

Eens. Maar je moest eens weten hoeveel bedrijven nog belangrijke software op MS-DOS (of ouder) hebben draaien waarvan de fabrikant allang niet meer bestaat en de source-code is verdwenen.

[The Zep Man]

Een informatiesysteem moet nu eenmaal vaak tientallen jaren mee, software is dusdanig duur, dat je het je niet kunt permitteren om iedere paar jaar een nieuw systeem te maken op basis van de nieuwste softwaretechnieken.

Als software zo duur is dan kan je ook eisen stellen aan dat het modulair en onderhoudbaar is.

Verder is er geen enkele reden om TLS 1.0 en TLS 1.1 server-side in stand te houden. Zet er een reverse proxy voor.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 17:54]

[dmantione]

Er is een hele hoop modulaire en onderhoudbare software in Cobol geschreven, waar geen programmeur meer voor te vinden is en onderhoud ondoenlijk omdat de omgeving niet aan de eisen van de tijd voldoet.

Ik vind het bijna arrogant om zo te redeneren zonder de specifieke details van de situatie te kennen.

[SuperDre]

Grappig waarom jij -1 krijgt terwijl je toch gewoon verteld wat klopt, maarja helaas zijn dat tweakertjes die vinden dat je altijd met de aller nieuwste technieken moet werken, anders ben je niet hip, en dat terwijl de nieuwe technieken vaak niets toevoegen dan luiheid of exact hetzelfde is als 20 jaar geleden, maar opnieuw geintroduceerd met een ander naampje.

[tweazer]

Je hebt gelijk in je reaktie. Desondanks gaan bedrijven failliet en is niet altijd proprietary materiaal dan meer te updaten...

[Rataplan_]

Wat een drogreden. Als een leverancier niet meer bestaat en een product krijgt geen beveiligingsupdates meer blijf je het maar gebruiken? Dan moet je toch zorgen dat die spullen geïsoleerd kunnen draaien. Op relatief korte termijn zal je dan toch je systemen moeten vervangen. Want wat doe je als er support nodig is en de leverancier bestaat niet meer? Geen goed idee. Of draai jij nog Windows XP op je machine waarmee je op internet gaat?

[tweazer]

Precies wat je zegt is de situatie: om technische reden niet meer te updaten, om financiele reden daar nog eens dubbelop overheen, pad lcm. Soms heb je daarbij oude versies van java en soortgelijke produkten nodig om legacy beheer uit te voeren. Juridisch moet soms data 10 tot 20 jaar lang bewaard blijven inclusief ondersteunende omgeving. Zolang amerikaans slagschepen nog op windows nt 4 draaien hoef je je overigens nergens druk over te maken... De minuteman rakketten op Apple ][ hardware zijn vziw al geupdate...

[The Zep Man]

Precies wat je zegt is de situatie: om technische reden niet meer te updaten, om financiele reden daar nog eens dubbelop overheen,

Hoeveel is er met die software bespaard c.q. verdiend?

Dat organisaties hun boekhouding niet op orde hebben is eigenlijk nog slordiger. Alles schrijft af, ook software.

[tweazer]

Als je legacy en proprietary soft-/hardware (geen support en/of leverancier) moet gaan herschrijven zonder broncode, met mogelijke copyright infringements zit je juridisch, technisch en financieel in een niet positief economische situatie, dan is de boel isoleren en laten uitsterven een betere optie. Tot het laatste bitje moet je dan wel die omgeving kunnen bereiken... Juist in deze situatie hebben bedrijven hun boekhouding in orde, andere partijen zouden geld in een bodemloze put gooien (de belastingdienst ?) of het risico negeren.

[Transportman]

Alleen gaat dat uitsterven dan nooit gebeuren. Het draait nog, dus is er geen noodzaak om het proces aan te passen of uit te faseren.

En dat kan soms vergaande impact hebben op een hele keten. Als deelproces N niet meer onderhouden wordt, dan kan je op N-1 en N+1 soms rare constructies krijgen om het maar aangesloten te houden, ook al doet deelproces N eigenlijk helemaal niets interessants. En opeens kost al het meerwerk aan N-1 en N+1 veel meer dan het ooit gekost zou hebben om N een keer te vervangen. Maar niemand voelt zich verantwoordelijk voor N, niemand wil zijn vingers eraan branden, dus N blijft maar bestaan en sterft nooit uit.

[tweazer]

Yup, welkom bij laag 8 en 9 van het iso 7 layer model: politics & economics
Het leuke/meest trieste/always the case is als een issue onstaat waar al decennia voor gewaarschuwd wordt, de dader letterlijk of figuurlijk op het kerkhof ligt en die sukkel die er het laatste aan gezeten heeft altijd de sjaak is, nooit enigerlei waardering krijgt voor al die tijd dat hij/zij moord en brand schreeuwde over de dienstverlening en dan nog gelijk krijgt ook ...

[Rataplan_]

Data bewaren (en benaderbaar houden) is iets heel anders als onveilige machines in productie houden. Bij de aanschaf hou je rekening met een bepaalde afschrijving. Als je na die periode geen nieuwe machine kunt aanschaffen heb je geen gezonde bedrijfsvoering denk ik.
Aan de andere kant, als Philips nou omvalt, zijn er vast legio clubjes die de MRI scanners kunnen onderhouden lijkt me. Er is altijd wel een weg. Maar het meest basale doet vaak mn haren overeind staan. Zoals op de basisschool van mn dochter waar ze gewoon Windows 7 blijven gebrukey 'omdat het toch nog werkt?'. Maar daar gaan wel 'onze' gegevens mee de lucht in. Aan de ene kant hoeven we niet panisch te zijn dat elk 'onveilig' systeem gehackt oid wordt, aan de andere kant, zet eens een Windows bak met 3389 open kaal aan internet en volg je firewall log eens. In de regel ben je binnen 24 uur aan de beurt geweest.

Daarnaast, de NT4 systemen die bij defenynog draaien zijn absoluut niet van buitenaf te bereiken, en daar zit de crux.

[tweazer]

Ik lees tussen de regels door dat je geen werkervaring bij een multinational hebt ? Of eerder een economische blik op de techniek ?
"Legio clubjes die mri scanners kunnen onderhouden" Zo'n SEM, TEM scanner etc hangt aan elkaar van copyrighted, closed source, proprietary material. Denk in de verste zin niet dat een ziekenhuis door een sanity check komt met onderdelen van marktplaats of darkweb. Ga eens praten met een ziekenhuis techneut en een hele wereld gaat voor je open....
Defensie draait nog met VAX/VMS ook zo'n dinosaurier...

[Reactie gewijzigd door tweazer op 23 juli 2024 17:54]

[Rataplan_]

Zeker wel. Ik heb jaren voor Philips gewerkt. En ja, daar heb ik zelfs nog de VAXen gedaan en (helaas?) uitgefaseerd. En ja, het zit allemaal vol met proprietary spul. Maar zo'n scanner schrijf je ook niet op 4 jaar af. Ik heb niks te maken gehad met contracten (ik zat niet bij Medical) maar mocht zo'n club omvallen, kan je als ziekenhuis wellicht niet maar gelijk een ander model aanschaffen.
Wellicht niet het juiste voorbeeld, want inderdaad in de medische wereld meent men soms dat elk schroefje gecertificeerd moet zijn. Het punt was dat ik primair vind dat je niet op unsuporterd en dus onveilige spullen moet draaien (vanuit de IT-kant gezien) maar als je een machine van meerdere miljoenen hebt staan, kan je die ook niet ineens economisch afschrijven. In zo'n situatie zou er toch een oplossing moeten komen.

[tweazer]

Ik geef je 100% gelijk, helaas heeft de werkvloer het niet altijd te beslissen. PMS daar zat Paul Keltjens Ooit nog eens PEO als pionier van Philips op internet gezet ... Semiconductors kwam pas jaren later ...

[N8w8]

Dat is waar, en het is daarom ook goed dat er druk op gezet werd door de browsers, anders beginnen ze pas met upgraden zodra ze in de krant lezen dat hun gegevens op straat liggen oid.
Maar vziw is TLS 1.0/1.1 niet zo onveilig, dat er urgentie is daar _nu_ helemaal mee te stoppen.
De partijen die bezig zijn met de pandemie enzo, als die ondanks die druk nu nog steeds geen TLS 1.2 hebben, gaan dat in deze omstandigheden al helemaal geen prioriteit geven.
Dan zorgt die druk alleen maar voor dat belangrijke partijen niet goed kunnen communiceren.
Maar buiten deze bijzondere situatie is het een ander verhaal.

[SuperDre]

Probleem is alleen, als de software zelf goed draait en er geen vervangingvis omdat er geen andere producent het maakt, wat moet je dan en vooral waarom moet je dan als de verbinding wel nodig is, maar niet belangrijk is om uberhaupt te encrypten.

[MrAndy9797]

@The Zep Man

Moest meteen aan jou denken,"zie hoe Google zaken doordrukt in Chrome" op het vorige artikel waar Microsoft de ondersteuning verlengde. Het lijkt me niet de moment om nu zaken door te drukken, zoals in het artikel vermeld wordt om overheidswebsites bereikbaar te houden, ookal maken ze gebruik van verouderde en onveilige protocollen.

[The Zep Man]

@The Zep Man

Moest meteen aan jou denken,"zie hoe Google zaken doordrukt in Chrome" op het vorige artikel waar Microsoft de ondersteuning verlengde. Het lijkt me niet de moment om nu zaken door te drukken,

Dan had je meteen ook naar deze reactie van mij kunnen refereren, waarin ik aangeef dat mijn opmerking breder was en niet gericht was op het moment.

• Dat er zaken door het coronavirus vertraagd worden? Begrijpelijk. Dit is niet het moment om kritieke zaken door te drukken.
• Dat organisaties geen goede tijdsmarges hebben tussen technologie uitfaseren voordat het overbodig wordt (in plaats van andersom) is een kwalijke zaak.

De huidige crisis maakt het juist extra pijnlijk dat organisaties hun zaken niet op orde hebben. Al hadden ze dat wel, dan was er nu meer veiligheidsmarge.

Zoals ik elders ook heb genoemd is er voor TLS 1.0 en 1.1 in de meeste use cases eigenlijk geen excuus. Men had ook (voor de crisis) er een reverse proxy voor kunnen zetten die TLS 1.2 en 1.3 naar de buitenwereld communiceert.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 17:54]

[glatuin]

Ik vraag me af hoeveel sites in NL nog TLS 1.0 of 1.1 gebruiken. Ik heb om te testen 1.0 en 1.1 support uitgezet in mijn browser maar vooralsnog geen problemen met Nederlandse sites gezien. Alles connect met TLS 1.2. En zowel tweaker als mijn eigen server met TLS 1.3

[Reactie gewijzigd door glatuin op 23 juli 2024 17:54]

[tweazer]

Ik las laatst een verhaaltje over waterschappen die hopeloos verouderde pompapparatuur bediende, legacy ten top... MIts het een gesloten omgeving is, 'if it ain't broke, don't fix it ?'

[tweazer]

Het liefst zou ik zelf by default alle onveilige protocollen uit willen zetten, daarnaast wellicht voor mijzelf rfc1918 ipreeksen willen excluden. Teveel oud spul dat nog steeds zijn (afgeschermde) doel heeft en technisch nog eens niet up te daten is ......

[DutchKevv]

Zou er niet eerst een waarschuwing pagina getoond kunnen worden net als in Chrome de 'rode waarschuwing' pagina, waarop je alsnog de site kunt bezoeken?

Zodat overheden zelf ook wat meer getriggerd worden haast te maken..

[joyrider3774]

is er ergens informatie beschikbaar wanneer google op hun servers TLS 1.0 & 1.1 zou blokkeren bij hun api calls ? hier gaat hem over de browsers, maar het kan evengoed geblokkeerd worden op server niveau en vraag me af of ze dat samen gaan doen met hun browser aanpassingen of op een andere datum

[arjan1995]

Ik hoor dit nu al een paar keer worden genoemd, maar kan iemand misschien een paar voorbeelden geven van COVID-informatiesites die enkel via TLS 1.0 en 1.1 te benaderen zijn? Want die informatie lijkt in elk artikel hierover te missen.