Digital Trust Center waarschuwt voor naderend einde van OpenSSL 1.1.1

Het Nederlandse Digital Trust Center waarschuwt bedrijven voor het naderende einde van OpenSSL 1.1.1. Dat gebeurt op 11 september. Bedrijven zouden dan moeten overstappen naar versie 3, al is niet bekend hoe wijdverspreid de verouderde software in Nederland is.

Het Digital Trust Center schrijft in een waarschuwing aan Nederlandse bedrijven dat OpenSSL 1.1.1 binnenkort haar end-of-lifestatus bereikt. De software krijgt vanaf dat moment geen beveiligingsondersteuning meer en kan daardoor gevaar opleveren. OpenSSL waarschuwde in juni al voor het einde van de longtermsupportrelease. OpenSSL 1.1.1 kwam op 11 september 2018 uit en kreeg, zoals alle lts-releases van OpenSSL, een ondersteuningsperiode van vijf jaar. Die eindigt dan ook over enkele weken.

Het DTC zegt dat als een algemene waarschuwing en niet met een specifieke aanleiding. De instantie zegt bijvoorbeeld niet of er buitenproportioneel veel oude OpenSSL-implementaties in Nederland worden gedetecteerd. Wel noemt het DTC de risico's voor het gebruik van de verouderde software. "Ernstige kwetsbaarheden in software die de versleuteling verzorgt, kunnen de confidentialiteit en integriteit van systemen en informatie aantasten", zegt het DTC. "Daarnaast staat software zoals OpenSSL vaak direct in verbinding met het internet, waardoor aanvallers kwetsbaarheden makkelijker op afstand kunnen misbruiken." Het DTC noemt de kwetsbaarheid in log4j als voorbeeld van een bug die makkelijk uit te buiten is en de potentiële schade die dat kan veroorzaken, al leek het voorspelde, grootschalige misbruik daarvan overigens uit te blijven.

Het DTC zegt dat bedrijven en hun systeembeheerders moeten controleren waar in hun systemen nog oude versies van OpenSSL zitten. Die moeten worden bijgewerkt naar OpenSSL 3.0 of OpenSSL 3.1. Versie 3.0 is een lts-release die ondersteuning krijgt tot 7 september 2026. OpenSSL 3.1, een reguliere release, krijgt ondersteuning tot 14 maart 2025. OpenSSL biedt zelf verder ook verlengde, betaalde ondersteuning aan voor software die de end-of-lifestatus heeft bereikt.

Reacties (28)

[CAPSLOCK2000]

Ik durf te voorspellen dat de er de komende vijf jaar nog nieuwe apparaten op de markt verschijnen met de oude versie van OpenSSL. Sterker nog, die gaan in reclame zetten dat ze veilig zijn en nog jaren ondersteuning van de fabrikant krijgen*.

We stormen af op een gevaarlijke kloof tussen verschillende belangen rond het ondersteunen van software.

Van de ene kant willen we software die lang mee gaat en lang ondersteuning krijgt. We willen niet dat we apparaten na 3 jaar weg moeten gooien omdat de software niet meer wordt onderhouden. Dat is duur, onhandig, slecht voor het milieu, etc....

Van de andere kant willen we software die veilig is en goed wordt onderhouden. Dat kost steeds meer moeite omdat we steeds meer software gebruiken en de software steeds complexer wordt. Daardoor wordt het steeds lastiger om oude versies lang te blijven ondersteunen. Er wordt al snel gekozen om alleen de nieuwste versies te onderhouden en gebruikers te vertellen dat ze moeten upgraden naar de nieuwste versie.

Die twee kanten conflicteren nogal met elkaar. Zeker als je ook met andere software moet samenwerken en dus eigenlijk vaste interfaces/api's wil hebben.

Het probleem wordt veel groter doordat er ontzettend veel leveranciers/producenten/fabrikanten zijn die allemaal hun eigen ding doen en voor ieder product dat ze uitbrengen opnieuw. Het zou een hoop helpen als ze meer zouden samenwerken en hun werk met elkaar delen. Met open source software als OpenSSL kan dat. Als alle gebruikers wereldwijd iets zouden bijdragen aan OpenSSL (geld, code, bugreports, whatever) zou het geen probleem moeten zijn om zo'n oude versie nog jaren te onderhouden. (Vroeg of laat zullen er problemen gevonden die zo fundamenteel zijn dat je niet kan oplossen zonder compatibility kwijt te raken).

Maar in praktijk zijn we daar nog heel ver vanaf. Er zijn er nog steeds een hoop die helemaal nooit onderhoud doen en niet eens een mechanisme/interface hebben om updates te installeren. En dan hebben we het nog niet gehad over de enorme hoeveelheid mislukte bedrijven die failliet zijn gegaan waardoor niemand nog voor hun software zorgt.

Ik denk dat we bedrijven moeten gaan verplichten om de broncode van hun software te registreren zodat die kan worden vrijgegeven als het bedrijf er zelf niet meer voor zorgt. Ofwel omdat ze failliet gaan ofwel omdat het te duur wordt. Als ze willen dat hun broncode geheim blijft moeten ze zelf maar voor updates blijven zorgen. Dat is ook een goede stimulans om na te denken over hoe software op lange termijn onderhouden kan worden.
In mijn ogen is de beste aanpak om zoveel mogelijk gebruik te maken van bestaande software die ook door anderen gebruikt wordt zodat je het onderhoud kan verdelen. Hoe meer standaard software je gebruikt hoe minder aantrekkelijk het wordt om zelf iets afwijkends te doen dat de compatibility verstoord. Hoe groter de compatibility van verschillende stukken software en hardware hoe makkelijker het wordt om zo'n component te vervangen door een andere standaard component met dezelfde interface. Als we daar zijn dan hebben we een model dat wel houdbaar is op lange termijn. Daar zijn we echter nog ver vanaf.

* In theorie is het zeker mogelijk want het is open source. In praktijk verwacht ik dat de meeste bedrijven daar niet eens over nadenken.

[Aldy]

Weer een argument voor Open Source software. Je weet ook nooit of je softwareleverancier er alles aan doet om hun reeds geleverde software up-to-date en veilig te houden. De meeste (kleine) leveranciers hebben daar het geld en de mensen niet voor of hebben het er niet voor over.

[_JGC_]

Het is opensource. Dat betekent dat bugfixes publiek beschikbaar zijn en gebackport kunnen worden naar oudere versies. Linux distributies doen dit ook op grote schaal. Debian 10 en 11 komen met OpenSSL 1.1.1n, die worden nog ondersteund tot juni 2024 en juni 2026 en zullen dus ook security fixes blijven toepassen. CentOS7/RHEL7 heeft zelfs nog OpenSSL 1.0.2k, die is al veel langer EOL en krijgt ook nog met regelmaat bugfixes (revisienummer 26 inmiddels).

Ander voorbeeld is PHP. Alles beneden de 8.0 is inmiddels EOL. Toch krijgen die versies nog regelmatig updates: https://deb.sury.org/
"The main repositories now contain both PHP 5.6, PHP 7.0-7.4 and PHP 8.0-8.2 coinstallable together."
En ja, ik heb nog wat oude zooi draaien op 5.6, die krijgt net zo regelmatig een update als een 8.0 of 8.1.

[HollowGamer]

> OpenSSL biedt zelf verder ook verlengde, betaalde ondersteuning aan voor software die de end-of-lifestatus heeft bereikt.

Ah gelukkig! Net zoals bij Windows, kan de overheid hier duur geld aan blijven uitgeven, i.p.v. huidige systemen te upgraden.

[wiseger]

Upgraden van systemen is ook duur. En schaarse resources kan je maar een keer inzetten dus moet men daarin ook keuzes maken, een upgrade project of nieuwe dan wel gewijzigde functionaliteit uitrollen de komende periode.

Overheden hebben te maken met veranderende wetten en regels dus regelmatig is de noodzakelijke nieuwe dan wel gewijzigde functionaliteit ook niet uit te stellen.

[mphilipp]

Upgraden van systemen is ook duur. En schaarse resources kan je maar een keer inzetten dus moet men daarin ook keuzes maken, een upgrade project of nieuwe dan wel gewijzigde functionaliteit uitrollen de komende periode.

Ja, maar zoals met alles, moet je een balans zien te vinden. Soms laten bedrijven (net zo goed als overheden) dit te lang liggen, waardoor upgraden echt een hel wordt door de afhankelijkheden en compatibiliteits issues. Die heb je dan zelf veroorzaakt door niet tijdig te upgraden. Ik heb ooit bij een gemeente met een HP server te maken gehad die 2 gold-packs achter liep. Mijn Oracle installer wilde niet eens installeren. Ja, dan wordt het een feest, want er waren meerdere afdelingen die er iets op hadden draaien en die moet je dan allemaal overtuigen om nu echt wat te gaan doen. Maar niemand wil, want ze weten nooit hoe alles met elkaar samen hangt. Het bekende (niet) documenteren feestje weer. Geen hond die eraan denkt om dat soort cruciales zaken te documenteren....

En bedrijven zijn niet veel beter. Ooit een keer een assesment moeten doen bij Unilever (kan het nu wel zeggen, is lang geleden) in de mooie gebouw aan de Maas waar ze de Calvé pindakaas maakten. De Oracle database en applicatie (en onderliggende Sun Solaris shizzle) was zó oud, dat de nieuwe beheerpartij er niets mee te maken wilde hebben. Ik moest uitzoeken hoe je dit nog kon upgraden naar een nieuwe Oracle versie. En die applicatie stuurde rchtstreeks via een API de machines aan die de pindakaas maakte. Je raad het al, ook die machines waren al stokoud en de fabrikant van de controllers was al lang overgenomen door Siemens. De API werd al lang niet meer ondersteund, en ga zo maar door. Een groot feest. Niets was dus nog ondersteund, hooguit de ethernet kabels nog maar misschien was dat nog fast ethernet. Je verwacht dat niet van een bedrijf dat gewoon miljarden verdient per jaar. Nu snap ik het.

[CAPSLOCK2000]

was zó oud, dat de nieuwe beheerpartij er niets mee te maken wilde hebben.

Herkenbaar. Vaak gaat het samen met het verschijnsel dat de vorige beheerder het al een tijdje heeft laten verslonzen omdat het contract toch bijna afloopt. Zeker als er eigenlijk een grote upgrade nodig is.

Ik moest uitzoeken hoe je dit nog kon upgraden naar een nieuwe Oracle versie. En die applicatie stuurde rchtstreeks via een API de machines aan die de pindakaas maakte.

Wij maken geen pindakaas maar ik zit midden in een vergelijkbaar traject maar ik ga de details nog niet op internet zetten anders dan dat het erg lastig is en we met de rug tegen de muur staan. Het project is meer gericht op overleven dan op verbeteren.

Niets was dus nog ondersteund, hooguit de ethernet kabels nog maar misschien was dat nog fast ethernet. Je verwacht dat niet van een bedrijf dat gewoon miljarden verdient per jaar. Nu snap ik het.

Als je eenmaal te ver achter loopt is het haast onmogelijk om er nog uit te komen zonder drastische maatregelen. Uitzoeken hoe dingen werken en waarom bepaalde keuzes zijn gemaakt is vrijwel onmogelijk. Structurele verbeteringen zijn haast onmogelijk en verschrikkelijk duur. Niet/weinig upgraden lijkt goedkoop tot het fout gaat en dan is het te laat en vormt zich een zwart gat dat steeds meer naar binnen trekt. Vroeg of laat bereik je het punt dat je op lichtsnelheid werkt en nog steeds niet kan ontsnappen. (Tot er een big crunch/big bang komt, maar dat is voorlopig vooral theorie en niet iets waar je op kan gaan zitten wachten. Het enige dat we zeker weten is dat zwarte gaten vroeg of laat instorten onder hun eigen zwaartekracht. En daarmee is deze analogie wel ver genoeg opgerekt )

[GeroldM]

Ook een boel servers "geerfd" van een beheerder die niets aan documentatie deed. En cryptische one-liners hoog in het vaandel had staan.

Sinds de overname heb ik een bootlading aan documentatie toegevoegd, servers vervangen, met alle stappen beschreven enz. Diegene die na mij komt, zal eerder klagen over teveel documentatie dan te weinig. Maar goed, de zoekfunctie in xWiki is best wel ok te noemen.

Gebrek aan documentatie, nou ja het idee achter bepaalde keuzes, daar heb ik een hele grote hekel aan gekregen over de jaren. Het kost minder moeite dan je denkt om vast te leggen wat je doet en waarom, terwijl je er mee bezig bent. Het is zeker niet het leukste onderdeel, maar heb er zelf ook profijt van gehad. Na een jaar of wat hebben een heleboel nuances van een server toch weten te ontsnappen. Dan is het prettig om na een korte blik op je eigen documentatie weer van de hoed en de rand weet.

[CAPSLOCK2000]

Upgraden van systemen is ook duur. En schaarse resources kan je maar een keer inzetten dus moet men daarin ook keuzes maken, een upgrade project of nieuwe dan wel gewijzigde functionaliteit uitrollen de komende periode.

In mijn ervaring schatten mensen het alleen totaal verkeerd in. Oude systemen hebben een hoop verborgen kosten die je pas ontdekt als het te laat is. Zo zie ik regelmatig servers draaien met verouderde instellingen om de configuratiefiles compatible te houden met oudere versies van diezelfde software. Of er worden twee (of meer) versies van dezelfde configuratiefile gebruikt. Dat geeft weer extra werk en meer risico op fouten.

Een ander aspect is dat als je samenwerkt met andere systemen die andere systemen ook niet gemoderniseerd kunnen worden omdat ze dan niet meer compatbile zouden zijn met je oude systeem.

Als er iets fout gaat met je oude versie dan heb je recht op support maar of je die ook echt krijgt is vraag twee. Vaak is kennis van oude software flink weggezakt, ook bij de leverancier, het kan best dat de programmeurs van toen inmiddels op een andere klus zitten of zelfs bij een ander bedrijf werken. Dan moet je hopen dat de leverancier z'n documentatie op orde heeft maar dat zal vaker niet dan wel zo zijn.

De leveranciers weten dat ook wel en dit soort end-of-life / extended-long-time-support contracten zijn vaak heel beperkt. Je krijgt typisch geen volledige ondersteuning maar alleen patches voor de grootste security bugs en verder krijg je hulp bij upgraden naar de nieuwste versie en niet meer dan dat. En dan nog op grond van "best effort" en voor maximaal X uren per jaar.
Maar de meeste mensen lezen nooit contracten en gaan er van uit dat je voor 5k/jaar wel volledige support zal krijgen en zelf niks hoeft te doen.

Ik adviseer dus om extreem proactief te zijn met patchen en upgraden. Ga er altijd van uit dat het laatste keer is dat je de kans krijgt om onderhoud te plegen en het systeem daarna nog 10 jaar door moet draaien zonder onderhoud. Ga er altijd vanuit dat je migratietraject mislukt en opnieuw moet. Ga er altijd van uit dat je leverancier morgen failliet gaat en je niet meer kan helpen.

Het is misschien wat overdreven maar komt een stuk dichter in de buurt van de realiteit dan aannemen dat het allemaal wél goed gaat. Als het op één van deze punten fout gaat wordt het al snel heel erg duur om het nog op te lossen. Zorg dat je jaren van de grens blijft en dat lukt alleen door altijd maar door te rennen en steeds weer te upgraden. We moeten echt af van het idee dat je een systeem kan bouwen en het dan met minimaal onderhoud 10 jaar kan laten draaien tot het helemaal end-of-life is.

Je hebt typisch 2 jaar "productie" en dan komt de volgende major versie uit.
Dan heb je 2 jaar om te upgraden naar de volgende versie.
Dan heb je nog 2 jaar om je mislukte upgrade/migratie opnieuw te doen (vaak ben je daarbij afhankelijk van derden waardoor het niet sneller kan).
Als het niet gelukt is loop je inmiddels 3 versies achter en krijg je al geen volledige ondersteuning meer van je leverancier. Als je op dit moment ontdekt dat het oude systeem nog niet weg kan (bv omdat er een ander systeem van afhankelijk is of omdat je wettelijk verplicht bent om de data te bewaren) heb je al beste een groot probleem. Maar goed je hebt nog 4 jaar om dat op te lossen. Dat is lang genoeg om een goed project op te zetten in plaats van paniekvoetbal te moeten spelen. Ondertussen heb je wel een project dat al jaren sleept en een hoop geld heeft gekost allleen al in coordinatie en management.

Dus: upgraden! nu!

PS. Beta/development/nightly-versies zijn er niet voor niets. Wacht niet met software testen tot de nieuwe versie officieel is gereleased. Gebruik beta-versies om bugs te melden als ze nog makkelijk opgelost kunnen worden én om je voor te bereiden zodat je direct aan de upgrade kan beginnen als de nieuwe versie uit komt. Probeer early-adaptor te zijn. Dat is duur, maar niet zo duur als te laat zijn.

[Reactie gewijzigd door CAPSLOCK2000 op 24 juli 2024 11:22]

[HollowGamer]

Het probleem is dat je uiteindelijk achter de feite aanloopt, zoals bij Windows support. Toen waren ze ook te laat, en hebben ze bij MS nog een aantal maanden moeten bijkopen. Dat was niet goedkoop, en veilig is ook maar de vraag.

Als je iets gebruikt als OpenSSL, dan zou je gewoon altijd de laatste versie moeten ondersteunen (of i.g.v. de LTS-versie).

[himlims_]

OpenSSL biedt zelf verder ook verlengde, betaalde ondersteuning aan voor software die de end-of-lifestatus heeft bereikt.

wist dat ze commerciele support bieden, maar ondersteuning bij een EOF status is nieuws voor mij. Dat vind ik overigens ook niet terug bij de support pagina; https://www.openssl.org/support/contracts.html#definitions

[Anoniem: 454358]

https://www.openssl.org/support/contracts.html

Provides extended support for LTS releases (including 1.0.2) beyond the public EOL date for as long as it remains commercially viable to do so. This will also include 1.1.1 when that is beyond its public EOL date.

[Reactie gewijzigd door Anoniem: 454358 op 24 juli 2024 11:22]

[CH4OS]

EOF is End Of File, dus daar kan an sich natuurlijk wel support op geleverd worden. Overigens is betaalde support ondanks publieke EOL iets dat redelijk "gewoon" is. Zie maar hoe lang Windows XP en Windows 7 commerciële support hebben gehad, terwijl er officieel geen support meer erop gegeven werd.

[Mitsuko]

De EOL van OpenSSL 1.1.1 is ook waarom Node.js v16 vervroegd de EOL status krijgt (gelijktijdig met OpenSSL 1.1.1).

Helaas is voor Node.js v18 (de huidige LTS) ook een nieuwere versie van glibc nodig, en de versie van glibc is gekoppeld aan het besturingssysteem. Dus als je bijvoorbeeld nog vast zit aan een server waar CentOS 7 op draait, dan zit je vast aan Node.js v16 en dus ook OpenSSL 1.1.1.

[Keyb]

30 juni 2024 is de end maintenance voor Centos Linux 7. Dus heel veel leven zit er sowieso niet meer in dat OS.

[AW_Bos]

Die ondersteuning van CentOS zijn tegenwoordig behoorlijk kort. Om deze redenen ben ik naar AlmaLinux overgestapt, wat een fork daarvan is.

[aadje93]

niet specifiek rocky linux gekozen? Die word als de opvolger van Centos gezien omdat CentOS niet meer "gemaakt" word nu,=

[AW_Bos]

Volgens mij was die niet beschikbaar toen ik mijn VPS wou installeren. Maar Almalinux wijkt niet veel af van CentOS. Het is zelfs eenvoudig vanuit CentOS over te zetten.

[aadje93]

aah dat kan, rocky linux is er vanaf ~juli 2021 uit me hoofd.

[Mitsuko]

Ja, hopelijk zit men minstens in een traject om over te stappen op een moderner alternatief. In mijn ervaring helaas een nogal moeizaam proces om de verantwoordelijke partijen te motiveren.

[foobar79]

RedHat heeft ook nog ELS voor 7.
Dit is nog eens 4 jaar support na 2024.

Niet dat je dit moet willen maar RedHat zal toch nog de nodige security fixes moeten blijven leveren (voor CVEs met een hoge rating) voor hun ELS klanten.

[Keyb]

Maar levert RedHat ook supported packages voor nodejs? Ik heb zelf geen Centos draaien. Maar als ik deze docs bekijk over hoe je nodejs kan installeren op Centos zie ik geen RHEL packages voor nodejs.

https://www.digitalocean....e-js-on-a-centos-7-server

In dat geval zal RHEL geen security updates voor deze issue leveren.

[casberrypi]

Het zou zomaar kunnen dat om de opvolger OpenSSL3 te kunnen gebruiken in je applicatie je wijzigingen moet doen aan je broncode. Dat is bij eigen applicaties niet zo'n probleem.

Ben je afhankelijk van een specifieke oudere versie van een applicatie, of zit je met een end-of-life product (open source of proprietary) dan zit je met de gebakken peren.

Bijvoorbeeld bij PHP is de vraag of PHP 8.0 met Security Support tot eind november dus nog (voor die twee maanden) moet worden aangepast zodat het compiled tegen OpenSSL3.

[FONfanatic]

Raar dat versie 3.0 langer ondersteund wordt dan versie 3.1. Daar is iets mis gegaan met de toegekende volgorde, of maakte @TijsZonderH een tikfout?

[twiFight]

Nee.

Versie 3.0 is een lts-release

LTS staat voor Long Term Support. Met die kennis snap je het al denk ik.

[fietser1997]

Dit komst doordat versie 3 een lts versie is. Dit zelfde geld voor heel veel ander software pakketten.
I.E.: Java, PHP, Linux etc. versie 3.1 is een iteratie die wordt vervangen door 3.2, 3.3 enzv.

[TijsZonderH]

Nee, wat @twiFight ook zegt. Lts-release krijgt langere ondersteuning dan reguliere release.

[tistjendop]

OPNSense (ook de recentste stable versie) gebruikt alleszins nog de 1.1.1 branch