Franse privacytoezichthouder geeft AVG-boetes voor SHA-1- en TLS 1.0-gebruik

De Franse privacytoezichthouder CNIL heeft in 2024 meerdere organisatie AVG-boetes gegeven omdat die verouderde encryptie- en verbindingsprotocollen gebruikten om data te beschermen. De organisaties gebruikten SHA-1 als hashalgoritme en TLS 1.0 of 1.1, maar die zijn verouderd.

Het is niet bekend om hoeveel organisaties het precies gaat, maar de Commission nationale de l'informatique et des libertés of CNIL schrijft dat het in 2024 in totaal 15 sancties heeft opgelegd aan Franse bedrijven voor het overtreden van de AVG. Daarbij deelde de organisatie voor in totaal 98.500 euro aan boetes uit. Het gaat om een reeks aan verschillende overtredingen. Zo hadden de organisaties geen functionaris gegevensbescherming in dienst, deden ze niet aan inzage- en verwijderverzoeken en werkten ze slecht mee met de onderzoeken.

Deels draaiden de sancties ook om slechte beveiliging, al specificeert CNIL niet in hoeveel gevallen dat was en welk aandeel dat had in de totale sancties. De toezichthouder zegt dat het boetes heeft uitgedeeld aan meerdere organisaties voor die beveiliging. Die organisaties gebruikten TLS 1.0 of TLS 1.1. Dat zijn beide verouderde verbindingsprotocollen, die in de meeste browsers ook al enkele jaren niet meer worden ondersteund. Toch gebruikten enkele Franse organisaties die nog steeds, waardoor persoonsgegevens volgens de CNIL via een onbeveiligde verbinding werden gestuurd. Daarmee voldeden de organisaties niet aan de minimale AVG-eisen voor gegevensbeveiliging.

Hetzelfde geldt voor organisaties dia SHA-1 gebruikten als hashalgoritme om gegevens te beveiligen. Ook dat is al jaren verouderd en onveilig en ook daarvoor geven browsers al bijna tien jaar waarschuwingen, maar toch kwam het in Frankrijk nog regelmatig voor. De CNIL beroept zich bij de beslissing op een eerdere uitspraak van het Franse cybersecurityagentschap. Dat raadt al jaren aan dat organisaties en overheden migreren naar modernere beveiligingsprotocollen.

Reacties (51)

[david-v]

Als je persoonsgegevens verwerkt is dit wel een goeie manier om bedrijven/instellingen te dwingen om iets aan de beveiliging te doen. Een aantal jaar geleden moest ik op de website van de school van mijn kinderen allerlei gegevens invullen en dat ging via een http verbinding (ipv https). Geweigerd natuurlijk en erop gewezen dat dat echt niet kon. De realiteit is dat kleinere partijen, instellingen die geen geld hebben om professionelen in te schakelen enz vaak een zeer slechte beveiliging hebben met alle gevolgen van dien.

Maak dan geen gebruik van deze middelen als je het niet veilig kan opzetten, zeker als je persoonsgegevens verwerkt.

[kozue]

Scholen en IT zijn sowieso geen goede combi. De basisschool van mijn dochter vind het ok om belangrijke informatie alleen via een *app* te delen, zonder ooit te overwegen dat er ook mensen zijn die ofwel geen apple/google apparaat hebben/willen, ofwel hier niet van afhankelijk van willen zijn. Alle IT afdelingen die je verplichten iets met smartphones te doen zouden ze wat mij betreft mogen vervangen door anderen die hun werk wél willen doen ipv zich er makkelijk vanaf te maken.

[Polderviking]

Ik denk dat er weinig IT afdelingen zijn die op eigen houtje dat soort operationele keuze's maken.

[david-v]

Hoe zou je dan belangrijke informatie willen delen? Want het enige alternatief blijft dan een papieren overdracht via je kinderen moeten zij (want soms ook nog steeds gedaan wordt). Ik ben het wel met je eens dat het naast een app (wat ik vele male liever heb dan whatsapp/facebook want dat heb ik niet) ook bijvoorbeeld een website beschikbaar moet zijn. Als een school bijvoorbeeld socialschools of magister gebruikt dan kan je de informatie ook via een website krijgen, dus dat is al beter geregeld. Die websites zou je dan het liefst als PWA installeren (geen idee of deze twee opties dat goed aanbieden).

[kozue]

Een website lijkt me prima, dat kun je overal op openen, niet alleen op gesloten apparaten die Apple of Google software draaien.

[Polderviking]

Totdat IT daar ook de cyphers iets te strak aantrekt, waardoor Beppie's antieke "werkt toch nog" tablet het niet meer snapt.

[Reactie gewijzigd door Polderviking op 22 juli 2024 13:59]

[CAPSLOCK2000]

Totdat IT daar ook de cyphers iets te strak aantrekt, waardoor Beppie's antieke "werkt toch nog" tablet het niet meer snapt.

Ik zie een feature, geen bug, hoe vervelend dat voor Beppie ook is. Ik hoop dat Beppie aanspraak kan maken op garantie voor tablet die binnen de verwachtte levensduur niet meer bruikbaar is.

[Polderviking]

Dat hoef je mij niet uit te leggen.

Maar de praktijk is toch wat meer gevuld met o.a. discussies als het mannetje wat security belangrijk vind moet discussiëren met het mannetje die wil dat het platform op zo veel mogelijk dingen werkt.

[jurroen]

Dat hoef je mij niet uit te leggen.

Maar de praktijk is toch wat meer gevuld met o.a. discussies als het mannetje wat security belangrijk vind moet discussiëren met het mannetje die wil dat het platform op zo veel mogelijk dingen werkt.

Makkelijk op te lossen toch? Elke ouder gebruikt netjes het online portaal die de school aanbiedt en alleen TLSv1.2 en TLSv1.3 met sterke ciphers accepteert.

Beppie mag dan in persoon even naar de school komen om het in orde te maken.

En dat mannetje die vind dat het op Android Kitkat nog moet werken, mag lelker optyfen. Elke privacy officer of CISO kan je zeggen dat de organisatie zich dan niet aan de wettelijke kadera houdt.

En nee, TLSv1.2/TLSv1.3 is geen wettelijke vereiste. Wél dat je het adequaat dient te beveiligen en dat is TLSv1 en TLSv1.1 echt niet meer.

Als Beppie dat lastig vind mag ze het proberen bij Apple, Google, Samsung of wie de fabrikant van haar device ook is.

[kozue]

Valt wel mee. TLS 1.2 wordt overal nog als acceptabel beschouwd en bestaat sinds 2008. Iedere tablet die nu nog gebruikt wordt is een stuk nieuwer dan dat, en zou dat moeten ondersteunen. En je hoeft ook niet te verwachten dat alles nog netjes werkt op een apparaat wat zo oud is.

[Polderviking]

TLS 1.2 is pas sinds Marshmellow standaard present binnen Android. Heb je het over eind 2015 toch nog.
Dat heeft anno 2024 inmiddels evengoed een gemarginaliseerd marktaandeel maar het is toch wat recenter dan je hier schetst.

[S-1-5-7]

Als de IT de cyphers strakker insteld en het niet meer werkt in de browser van Beppie haar antieke tablet, zal dat waarschijnlijk niet anders zijn als diezelfde tablet een app gebruikt... Uiteindelijk is een browser namelijk ook gewoon een app...

[jurroen]

Ciphers*

Maar ligt eraan. Als de browser de systeem library voor SSL/TLS gebruikt, zeker. Maar dat hoeft niet het geval te zijn.

Zo gebruikt Edge geloof ik Stunnel (standaard op Windows) en shipt Chrom{e,ium} met een eigen library.

[david-v]

Totdat IT daar ook de cyphers iets te strak aantrekt, waardoor Beppie's antieke "werkt toch nog" tablet het niet meer snapt.

Dit maken we nog regelmatig mee, vooral mensen die bijvoorbeeld met digid moeten inloggen en het allemaal niet werkt omdat je apparaat (maakt niet uit welke) geen veilige verbinding kan opzetten omdat het door de leverancier niet is bijgehouden wat betreft certificaten.

Beppie moet dan helaas gaan klagen bij de leverancier van het apparaat. Terecht dat het apparaat geweigerd wordt. Zo simpel is het.

[dinoballz]

Ook geen fan van MFA dan?

[aikebah]

Niet als ik de tweede factor op mijn eigen prive device zou moeten plaatsen nee. Tweede factor voor het werk prima, maar het daarvoor benodigde device moet dan wel van het bedrijf komen.

[kozue]

Nee, niet met mobieltjes nee. Ik heb wel een OTP programma op m’n laptop staan, voor die paar sites waar ik het nodig heb.

[dinoballz]

Ja, en dat heeft dus geen enkele zin. Als er immers al toegang is tot de laptop dan is er ook toegang tot die OTP. Het hele punt is dat je ze gescheiden houdt.

[kozue]

Ik heb nooit om 2FA gevraagd, dat wordt opgedrongen door de tech industrie, dus of het wel of geen zin heeft boeit me niet zo veel.

Maar behalve dat zit je er compleet naast. Wat je nu zegt kun je ook over mobieltjes zeggen. Als je daarop inlogt, en je OTP app daar op staat, heb je exact dezelfde situatie als met beide op de laptop. En dat is precies de use case die het gros gebruikt: een 2FA app op hun telefoon om in te loggen op internettroep op hun telefoon. Je zou alleen een punt hebben als iedereen die OTP app alleen zou gebruiken om in te loggen op een laptop/computer, en dat is meer uitzondering dan regel.

En het principe geldt nog steeds. Je logt niet alleen in met die code, dat zou super onveilig worden. Je logt in met *meerdere* factoren. Over het algemeen wachtwoord + code. Iets wat je *weet* (het wachtwoord) en iets wat je hebt (je apparaat waar de OTP client op staat).

[air2]

Het gaat niet om het gescheiden houden: het gaat om het verschil tussen iets wat je weet en iets wat je hebt. Een ww kan lekken van een andere site waar je dat ww ook gebruikt hebt bv. De mfa zorgt ervoor dat met enkel dat gegeven geen toegang verkregen kan worden.
Het verspreiden over devices zou het theoretisch iets veiliger maken bij een tageted attack, maar het is niet zozeer het hele idee achter mfa.

[Stevendefeij]

Als het om Parro gaat die heeft gewoon een webversie.

Scholen en IT zijn sowieso geen goede combi. De basisschool van mijn dochter vind het ok om belangrijke informatie alleen via een *app* te delen, zonder ooit te overwegen dat er ook mensen zijn die ofwel geen apple/google apparaat hebben/willen, ofwel hier niet van afhankelijk van willen zijn. Alle IT afdelingen die je verplichten iets met smartphones te doen zouden ze wat mij betreft mogen vervangen door anderen die hun werk wél willen doen ipv zich er makkelijk vanaf te maken.

[kozue]

Nee, het heet Kwieb ofzo. En voor zover ik weet is er alleen een app. Zo niet hebben ze steken laten vallen in hun communicatie.

[klakkie.57th]

Principeel snap ik dat je geen http verkiest, maar dat zegt verder toch niks.

Stel ze hadden nu wel https wat gebeurd er dan met de verzamelde data? Is die encrypted ? Retention policies ? Wie heeft er inzage ?…

Bij al dit soort organisaties, scholen, verenigingen, vzw’s ga ik er gewoon van uit dat het niet op orde.

[david-v]

Dat is ook wel zo, maar het was meer om aan te geven dat het soms nog erger is omdat er helemaal niks werd gebruikt. Bij de middelbare school van mijn kinderen vroegen ze ook om een kopie paspoort. Toen heb ik ook gebeld en uitleg gevraagd en ook wat ze ermee deden: uitprinten en in het papieren dossier . Ik heb ze erop gewezen dat dat absoluut niet mag als onderwijsinstelling. Tja, daar weten ze niet wat ze daarop moeten zeggen. Ze snappen het gewoon niet. Ik kan me daar echt heel druk om maken omdat de meeste mensen alsnog een volledige kopie sturen van de id of paspoort

[sircampalot]

omdat de meeste mensen alsnog een volledige kopie sturen

De meeste mensen weten het blijkbaar dus ook niet.
En als ze het wel weten, weten ze waarschijnlijk niet waarom het niet mag.
Het is daarom wel jammer dat de door u gelinkte pagina daar niets over zegt.

[CAPSLOCK2000]

Tjakka! Pak ze!
Dit gaat hard pijn doen, maar het is helemaal terecht.

We zijn al jaren en jaren aan het bidden en smeken om van die oude crypto af te komen voordat er rampen gebeuren. Op papier is iedereen het daar mee eens maar vrijwel niemand overziet hoe veel werk er nog moet gebeuren. Er wordt nog steeds hardware/software geleverd die dit toestaat.

Je moet al je hardware en software controleren en configureren. Het is niet voldoende dat er ondersteuning is voor nieuwere crypto, je moet zorgen dat de oude uitstaat en je kan er niet eens van uitgaan dat het uberhaupt configureerbaar is.. Nu zou je sowieso alle crypto in je organisatie zelf moeten configureren maar dat is in praktijk volgens mij nergens zo.
Vuistregel: alles van meer dan 5 jaar oud bevat dit soort oude crypto, bij systemen van meer dan 10 jaar staat het by default aan.

Vaak zit het ook nog op de meest pijnlijke plekken zoals de centrale fileserver. Die worden bewust achter gehouden omdat oude machines anders niet meer kunnen verbinden. Dat is eigenlijk precies verkeerd om. Laat die oude systemen maar tegen de muur lopen, het is een feature dat ze niet mogen inloggen als ze niet worden onderhouden. Sterker nog, oude crypto is waarschijnlijk niet het grootste problemen van dat onbeheerde systemen. Laat die crypto maar een waarschuwing zijn dat het beheer niet voldoet.

Een ander pijnpunt is embedded apparatuur, zeker buiten het normale IT-domain, zoals koffieautomaten, slimme lampen en bewakingscamera's. Die worden geacht om 20 jaar mee te gaan en er is vaak geen budget of tijd voor onderhoud, als er uberhaupt nog support mogelijk is na 10 jaar.

Dat is ook waarom ik weinig sympathie heb voor het argument dat het wel meevalt met die oude crypto omdat in praktijk het vaak nog steeds vrij lastig is om er misbruik van te maken. Nu misschien nog wel maar hoe lang nog? Wacht niet tot het zo lek is dat je hals over kop alles moet vervangen of uitschakelen.

PS. Ik hou het voor het gemak even bij "oude" en "nieuwe" crypto in de context van security. Er zijn andere toepassingen van bv sha1 hashes prima bruikbaar zijn omdat er geen security implicatie is. Wie dat soort subtiliteiten snapt heeft mijn post toch niet nodig.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 13:59]

[david-v]

Ik ben het deels met jee eens wat betreft embedded apparatuur. Een slimme koffieautomaat (heb ik, niet verbonden met internet), slimme lampen of bijvoorbeeld een wasmachine....die verwerken allemaal geen persoonsgegevens bijvoorbeeld. De security eisen voor deze specifieke apparatuur zijn/kunnen bijvoorbeeld anders zijn dan een camerasysteem, (wifi)router of een slimme deurbel waar beelden mee opgenomen kunnen worden.

[CAPSLOCK2000]

De eisen zouden anders kunnen zijn, maar als er maar 1 set eisen is dan zal die oude meuk ook moeten voldoen. Dat zo'n apparaat geen persoonsgegevens verwerkt vind ik geen heel goed argument want dat soort spul kan als springplank gebruikt worden om verder in je organisatie/netwerk door te dringen.

Ik heb een beetje moeilijke relatie met flexibele eisen. Mijn ervaring is namelijk dat alleen securitybewuste IT'ers die snappen en die gaan uitzichzelf al veel verder dan mijn minimale eisen. De mensen zonder dat bewustzijn zien securityeisen vooral als excuus om dingen niet te hoeven doen, een ideaal, geen ondergrens.

[david-v]

Ik snap je betoog, maar dat heeft ook enorme implicaties voor geleverde apparatuur en de kosten die daar aan verbonden zijn. Een simpele bluetooth/wifi speaker zou dan aan de security eisen moeten voldoen voor de komende *levensduur* jaren. Dat is een zeer hoge eis die je dan economisch gezien moeilijk kan doorvoeren op dergelijke apparaten. Ik snap je heel goed, maar ik vraag me persoonlijk af hoe je dit in een werkbare/betaalbare vorm zou kunnen uitvoeren.

[CAPSLOCK2000]

Een simpele bluetooth/wifi speaker zou dan aan de security eisen moeten voldoen voor de komende *levensduur* jaren. Dat is een zeer hoge eis die je dan economisch gezien moeilijk kan doorvoeren op dergelijke apparaten. Ik snap je heel goed, maar ik vraag me persoonlijk af hoe je dit in een werkbare/betaalbare vorm zou kunnen uitvoeren.

Die economische prijs is er sowieso, de vraag is niet of maar wie er voor moet betalen.
Fabrikanten houden de aanschafprijs laag en dumpen de risico's daarvan bij de klanten die dat zelf typisch niet kunnen overzien, of indirect bij klanten/gebruikers van de klanten of in ultimo bij de maatschappij.
Het bekende verhaal van winsten privatiseren en kosten socialiseren.

De oplossing is dat we meer gebruik moeten maken van generieke software en minder van custom software. Onder de motorkap draait dat soort apparatuur hele gewone software, typisch Linux. 99% is een kant en klaar OS en 1% is custom software van de leverancier (en die is soms ook weer ingekocht). Die leverancier moet niet alleen de eigen software onderhouden maar ook het hele OS. Daarbij is die eigen software vaak helemaal niet bijzonder of uniek. Hoeveel verschillende manieren heb je nodig om een lamp aan of uit te doen?
Het probleem wordt groter met iedere leverancier die je toevoegt die zelf ook weer de hele software stack moet onderhouden.

We zouden een voorbeeld moeten nemen aan de PC markt waar je OS niet uniek is en niet is aangepast aan de hardware maar zo standaard is dat je vrijwel iedere combinatie van losse onderdelen kan kopen om daar zelf Windows / Linux / BSD / .. op te installeren. Veel hardware maakt gebruik van standaard drivers (bv usb muizen) die iedere stuk hardware op de markt kunnen aansturen. Het doel is dat de slimme magnetron voor 99% op dezelde software draait als (bv) je PC en op zelfde manier updates krijgt, direct van de maker van het OS (bv Microsoft) zonder dat er een fabrikant tussen zit.

Het schaalt niet als iedere fabrikant z'n eigen OS-variant moet onderhouden. Als we dat deel onafhankelijk maken zodat de fabrikanten echt alleen voor hun eigen spul hoeven te zorgen dalen de kosten voor iedereen en kan de fabrikant zich richten op de eigen specialiteit.

Liefst zou ik een verplichting zien dat ieder apparaat in principe zelf (her)installeerbaar moet zijn. Dus geen gelockte bootloaders en wel een bereikbare USB-poort, of zo iets.

[Strebor]

Deze apparaten registreren misschien wel de gewoontes van de bewoners van een huis. Wanneer het licht aan en uit gaat en of dat met een automatisering gaat of handmatig. En wanneer je dat allemaal herleidt tot een persoon, groep personen of en woonadres, dan is die data ineens helemaal niet zo onschuldig.

[david-v]

Eens, echter de meeste oplossingen werken alleen op je interne netwerk en zijn niet van buitenaf te benaderen. Als ze dat al zijn dan gaat dat meestal via een dienst va de leverancier, en die zijn "redelijk" beveiligd (lees nog net niet voldoende, maar dat is mijn persoonlijke mening ). Tweakers die daar niet van gediend zijn maken dan bijvoorbeeld via VPN het apparaat toegankelijk vanuit een externe verbinding. Ik doe dan de aanname dat de mensen die dit voor elkaar krijgen ook de nodige beveiliging ingeregeld hebben.

Dus blijft er over dat die apparaten alleen via je eigen wifi te benaderen zijn. Dan moet iemand één adres/persoon hacken waarbij je ook nog eerst toegang moet zien te krijgen tot de wifi. Dat laatste is niet heel ingewikkeld overigens, maar dat even terzijde. Massaal informatie vergaren gaat dan niet, het wordt dan echt een persoonlijke aanval op je smart devices. Ik zie dat niet snel gebeuren, al zal dat vast wel eens voorkomen (baldadigheid?).

Bovendien als je toch al in de buurt moet zijn om connectie te kunnen leggen via de wifi, dan kan je net zo goed kijken. Je hoeft niet te hacken om te weten of de verlichting aan/uit staat

[keranoz]

Ze zouden via een lek in een "oude crypto methode" wel gehackt kunnen worden om bijvoorbeeld onderdeel te worden van een IoT botnet.

[david-v]

Mits het apparaat verbonden is met het internet

[Guru Evi]

Niet noodzakelijk, oude crypto wil meestal zeggen dat het een beetje gemakkelijker is om de crypto te breken via vb. een downgrade attack of sleutels uit te vissen. In de meeste gevallen heb je nog steeds een redelijke rekenkracht nodig om er iets nuttig mee te doen, denk dan de schaal van een overheid. Voor de meeste 'commerciele' hackers is de kosten-baten om zulke aanvallen uit te voeren nog steeds te groot zelfs met SSLv3 of TLS1.0.

Moet je weg van <TLS1.3, natuurlijk, maar is het kritisch, hangt er sterk van af, er is veel meer laaghangend fruit in andere aspecten van de veiligheid.

[The Zep Man]

Daarbij deelde de organisatie voor in totaal 98.500 euro aan boetes uit.

Verdeeld over 15 sancties klinkt dit als cost of doing business, want reputatieschade hebben ze sowieso al niet.

Een toezichthouder zou maandelijks een scan kunnen doen van sites van bedrijven. Maand 0 de nulscan+waarschuwing de deur uit. Maand 1 sanctie voor bedrag X. Maand 2 sanctie voor bedrag X*2, maand 3 sanctie voor bedrag X*4, etc. Dit hele proces is te automatiseren.

"Maar een maand is te weinig tijd om zaken op orde te krijgen!"

Dat hadden ze zes jaar geleden kunnen bedenken, toen TLS 1.2 al tien jaar uit was en de kwetsbaarheden van TLS 1.0 en 1.1 al voldoende bekend waren om die als onveilig te oormerken.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 13:59]

[kozue]

Ik denk dat dit helaas het topje van de ijsberg is. Genoeg bedrijven houden hun IT niet bij en draaien nog verouderde troep. Hoeveel hebben er wel niet nog Windows XP machines staan? Of oude databases die niks hogers dan TLS 1.0 ondersteunen (dat was tot een paar jaar geleden nog het geval met de standaard mysql/mariadb build op Ubuntu die met yassl gecompileerd werd ipv openssl). Vorig jaar zelfs nog een automatisering geïmplementeerd met een Nederlandse bank, die via ssh liep, maar een stokoude ssh gebruikte die alleen verouderde cyphers ondersteunt (shame on you, maar ik zal geen namen noemen...). Als zelfs banken het al niet kunnen, wat kun je van kleine toko's verwachten?

[blorf]

Het is ook niet helemaal realistish. Het gaat uiteindelijk over trust-based security. In feite is iedereen met een eigen oplossing zonder die vereiste verder. Je moet alleen maar een uiteindelijke centrale autoriteit ook als risico beschouwen.

[Keyb]

Misschien een soort APK voor computers introduceren. Zonder APK mag je de weg niet meer op?

[david-v]

Als je persoonsgegevens verwerkt zou dat wel praktisch zijn ja. Het is ook niet heel ingewikkeld om dat op orde te hebben. Je webadres hier opgeven en je weet wat je moet doen als het niet helemaal ok is.

[Guru Evi]

Ga eens naar een ziekenhuis, Windows 2000 kun je nog steeds vinden (Philips, Kodak, Fujitsu, GE, Siemens) en vandaag verkoopt Siemens nog steeds nieuwe systemen met Windows 7. Al de pompjes van Baxter, Philips, etc draaien op Windows CE en die krengen zijn redelijk duur om ze elke 5 of zelfs 10 jaar buiten te smijten, zolang ze blijven werken en hersteld kunnen worden gaan ze blijven draaien. Een van zulke modulaire bedsystemen heeft intern tot 5 computers per bed die met een switch aan de WiFi hangen, chip, drivers en RTOS die WPA2 Enterprise konden spreken zijn ook niet echt 'oud' dus moeten we 2.4GHz 802.11b/g blijven aanstaan met een simpel WPA of WPA2 wat vandaag relatief gemakkelijk te kraken valt.

[Reactie gewijzigd door Guru Evi op 22 juli 2024 13:59]

[joost00719]

Uit ervaring weet ik dat het nog niet altijd zo eenvoudig is om TLS 1.0 en 1.1 uit te zetten.
Ik heb jaren gewerkt voor een bedrijf dat een soort van tweakers pricewatch als core-business heeft, maar dan voor de installatiebedrijven & fabrikanten.
Toen wij een oudere versie van TLS uit zette, waren er direct klanten aan de telefoon die klaagde over dat hun systeem ons systeem niet meer kon bereiken, i.c.m. dat hun softwarepakket ook niet meer werd onderhouden.
Uiteindelijk wel gelukt, maar heeft echt maanden geduurd voordat we het zomaar uit konden zetten.

[jurroen]

Dat die implementatie maanden duurt is vervelend. Maar ook iets wat al veel eerder had moeten gebeuren. TLSv1.2 is er sinds 2008, als je dat nu nog niet ondersteund heb je de shit simpelweg niet op orde.

[autostatic]

Voel met je mee, ook al anderhalf jaar bezig twee weak cipher suites uit te zetten. De spoeling wordt wel dun op het moment wat betreft betrouwbare cipher suites. Hopelijk krijgen we op termijn de beschikking over cipher suites gebaseerd op nieuwere (bijv. post-quantum) algoritmes.

[CAPSLOCK2000]

Toen wij een oudere versie van TLS uit zette, waren er direct klanten aan de telefoon die klaagde over dat hun systeem ons systeem niet meer kon bereiken, i.c.m. dat hun softwarepakket ook niet meer werd onderhouden.

Ik snap heel goed dat je geen klanten wil verliezen en je zo'n verandering niet wil doorvoeren als het inkomsten kost. Daarom is het goed dat er boetes worden uitgedeeld zodat er financiele druk is om voor veiligheid te kiezen in plaats van eindeloos oude software te blijven faciliteren.

Overigens heb ik ook het omgekeerde meegemaakt, namelijk dat we leveranciers hebben afgekeurd omdat ze nog oude crypto toestonden. Daar wilde wij onze data niet aan toevertrouwen. Helaas zijn er nog steeds leveranciers die vol ongeloof reageren alsof we de eerste zijn die ooit naar security vragen.

Nu er steeds meer regelgeving rond computers is verwacht ik dat het normaler zal worden dat klanten eisen aan de veiligheid stellen en zal de balans vroeg of laat omslaan, maar het zal nog wel een tijd duren.

[Robru1]

TLS 1.0 en 1.1 bestaan al lang - respectievelijk sinds 1999 en 2006 - en zijn inmiddels verouderd. De nieuwste TLS-versie is TLS 1.3 en deze werd in 2018 uitgebracht. In de nieuwste versie zijn de kwetsbaarheden van de vorige versies weggewerkt, wat betekent dat de beveiliging van de nieuwste versie aanzienlijk beter is dan die van de oudere versies. Het gebruik van TLS 1.2 en TLS 1.3 zorgt er daarom voor dat het verzenden en ontvangen van e-mails beter beschermd is tegen hackers.

[david-v]

offtopic: Ik snap niet waarom je 3x een -1 krijgt, heb je een aantal haters hier? .

[Aiii]

Waarschijnlijk omdat het leest als een AI generated wikipedia artikel. Het comment niet echt op het artikel, het is slechts een uitleg van wat TLS is, ik snap eigenlijk de +1 dan weer niet.

[NaZGuLL]

Classification: We are highly confident this text is entirely human

[Frame164]

"Belachelijk. Kunnen ze geen boeven gaan vangen" (refererend aan de reacties op het onderwerp over de boete van crypto.com).

[sircampalot]

Op zich wel goed om die beveiligingen op orde te maken, maar het is wel mosterd na de maaltijd.
Ik denk dat er beter ingezet kan worden op een betere manier van bijv identificeren, zodat die oude ID data waardeloos wordt.

[Reactie gewijzigd door sircampalot op 22 juli 2024 13:59]