Ondersteuning van OpenSSL 1.1.1 is afgelopen

OpenSSL 1.1.1 heeft officieel de end-of-lifestatus bereikt en krijgt vanaf 11 september geen beveiligingsondersteuning meer. De nieuwste versie van de software is OpenSSL 3.1.

OpenSSL is een opensourcebibliotheek voor cryptografie die gebruikt wordt voor de implementatie van beveiligingsprotocollen in netwerken. Het gebruik van de verouderde versie van de software kan voor ernstige beveiligingsproblemen zorgen. Zo waarschuwde het Nederlandse Digital Trust Center eerder: "Ernstige kwetsbaarheden in software die de versleuteling verzorgt, kunnen de confidentialiteit en integriteit van systemen en informatie aantasten." Het is niet bekend hoeveel netwerken nog gebruikmaken van OpenSSL 1.1.1. Systeembeheerders kunnen de betreffende software updaten naar OpenSSL 3.0 of OpenSSL 3.1.

Reacties (57)

[P1nGu1n]

Om deze reden is Node v16 (LTS) ook per vandaag end-of-life, 7 maanden eerder dan gepland: https://nodejs.org/en/blog/announcements/nodejs16-eol

[Polderviking]

Dat je gaat pielen met je support datum moet je niet te veel hebben denk ik... vind het best twijfelachtig dat je "zomaar" zo'n datum drie kwart jaar naar voren trekt.
Zeg dan niks.

Ook niet de eerste keer zo te lezen.

[Reactie gewijzigd door Polderviking op 22 juli 2024 16:12]

[Mitsuko]

Wat ik persoonlijk kwalijker vindt is dat ze de vereiste versie van glibc stilletjes ook opgehoogd hebben voor Node.js v18, waardoor je in sommige gevallen (CentOS 7 bijvoorbeeld) een heel nieuw besturingssysteem nodig hebt om over te kunnen stappen op een ondersteunde versie. Erg onhandig dat dit samenvalt met de vervroegde EOL.

Microsoft werkt hier inmiddels al omheen in vscode-server door een custom build van Node.js v18 te bundelen, maar het is natuurlijk de vraag hoe lang dit blijft werken.

[CAPSLOCK2000]

Wat ik persoonlijk kwalijker vindt is dat ze de vereiste versie van glibc stilletjes ook opgehoogd hebben voor Node.js v18, waardoor je in sommige gevallen (CentOS 7 bijvoorbeeld) een heel nieuw besturingssysteem nodig hebt om over te kunnen stappen op een ondersteunde versie. Erg onhandig dat dit samenvalt met de vervroegde EOL.

Als je nu nog op RHEL7 zit heb je grotere problemen. Wat Node.js doet is misschien niet ideaal maar wel pragmatisch. Op een oude libc versie blijven zitten is ook niet echt veilig. Als je om security geeft had je al lang klaar moeten zijn met de migratie. Als je nu nog op RHEL7 zit kun je niet volhouden dat security echt een prioriteit is. Don't shoot the messenger.

[ninjazx9r98]

RHEL 7 en CentOS 7 maintenance support eindigt in juni 2024. Welke grote problemen zijn er dan op dit moment?

[CAPSLOCK2000]

Je eerste grote probleem is dat je minder dan een jaar hebt om deze server uit te faseren of te upgraden. Als je in een omgeving als de mijne zit is 1 jaar eigenlijk te kort. Als er iets mis gaat heb je geen speelruimte meer over.

Ten tweede heb je nu al geen volledige support meer: "During (...) Maintenance Support 2 Phase for Red Hat Enterprise Linux version 7, Red Hat defined Critical and Important impact Security Advisories (...) may be released as they become available."
Je hebt dus alleen support "critical" en "important" security fixes en Red Hat bepaalt welke dat zijn. Bugs die vanuit het OS gezien niet kritiek zijn kunnen dat wel zijn voor applicaties die er gebruik van maken.

Dat gaat niet alleen over veiligheid maar ook over hulp bij migratie/upgrade. Als je migratie nu mislukt mag je het zelf uitzoeken en kun je niet meer bij RedHat terecht voor hulp (volgens het contract, in realiteit verwacht ik dat ze wel degelijk best-effort hulp geven).

Ten derde is het zo dat als je OS zou oud is dan zijn je applicaties dat waarschijnlijk ook en zou migreren naar iets anders wel eens lastig kunnen worden. Zeker als de rest van de omgeving ook zo oud is.

Ten vierde wil je niet dat er nieuwe systemen worden ingericht die in backwards-compatibility mode (of zo iets) moeten draaien om compatible te zijn met je 10 jaar oude servers. Neem bijvoorbeeld SSH, het SSH v1 protocol is al jaren geleden uitgeschakeld. Toch zie ik nog steeds systemen die de oude versie moeten blijven gebruiken vanwege (vermeende) compatibility met nog oudere systemen.

In het kort komt het er op neer dat je de randen van support niet moet opzoeken maar daar ver weg moet blijven. Hoe langer je wacht hoe minder bewegingsruimte je hebt. Als je te lang wacht kun je geen kant op als er iets gebeurt.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 16:12]

[ninjazx9r98]

Dat is in de ideale wereld maar velen van ons leven daar helemaal niet in en als je nu nog een maand of negen te gaan hebt en een planning zo goed als klaar hebt voor uit faseren, migraties en upgrades dan mag je jezelf gelukkig prijzen in mijn/onze omgeving.
Het OS upgraden/vervangen is nog wel het meest simpele van het hele proces maar als vervolgens alle betrokken applicaties in een keten beheerd worden door een hoeveelheid aan interne en externe partijen
en er ook raakvlakken zijn met Windows servers dan kun je voor OS beheer nog zo graag willen upgraden maar in de lead ben je sowieso niet.
Wat dat betreft is het eerder dat het OS de applicatie volgt dan andersom. Wij kunnen nog zo graag een half jaar geleden of nog eerder naar een hogere OS versie willen gaan maar als een bedrijfskritische applicatie van de klant daar nog niet voor geschikt is kun je simpelweg niet upgraden. Of voor die applicatie heb je wel een werkende versie maar iets verderop in de keten zit een applicatie van een andere leverancier die daar weer niet mee overweg kan.

Wij zoeken dan ook niet de randen van support op, dat gebeurt bijna automatisch als je een serieus grote keten hebt met veel afhankelijkheden waarbij veel verschillende partijen zowel intern als extern bij betrokken zijn. Als je dan vele (keten)testen succesvol hebt afgerond en een planning klaar hebt liggen voor de komende periode is er naar mijn idee helemaal niet zo'n groot probleem.

[Reactie gewijzigd door ninjazx9r98 op 22 juli 2024 16:12]

[Polderviking]

Rhel7 doet nog bijna een jaar mee qua support. Dus ben benieuwd naar je onderbouwing.

[CAPSLOCK2000]

zie CAPSLOCK2000 in 'Ondersteuning van OpenSSL 1.1.1 is afgelopen'

[Polderviking]

Je eerste grote probleem is dat je minder dan een jaar hebt om deze server uit te faseren of te upgraden. Als je in een omgeving als de mijne zit is 1 jaar eigenlijk te kort. Als er iets mis gaat heb je geen speelruimte meer over.

Ik heb geen ervaring in omgevingen waar ik zelf niet gewoon achter alle knoppen zit of iemand kan spreken die dat zit, dus ik zal me voorzichtig uitdrukken, maar een jaar om een server te vervangen vind ik toch echt wel naarstig veel tijd.

Ten tweede heb je nu al geen volledige support meer: "During (...) Maintenance Support 2 Phase for Red Hat Enterprise Linux version 7, Red Hat defined Critical and Important impact Security Advisories (...) may be released as they become available."
Je hebt dus alleen support "critical" en "important" security fixes en Red Hat bepaalt welke dat zijn. Bugs die vanuit het OS gezien niet kritiek zijn kunnen dat wel zijn voor applicaties die er gebruik van maken.

Dat gaat niet alleen over veiligheid maar ook over hulp bij migratie/upgrade. Als je migratie nu mislukt mag je het zelf uitzoeken en kun je niet meer bij RedHat terecht voor hulp (volgens het contract, in realiteit verwacht ik dat ze wel degelijk best-effort hulp geven).

"As is" is toch altijd het hele motto met OSS? Zeker als je in het CentOS landschap zit. Vertrouwen in deftig handelen up stream is impliciet of je gebruikt dat hele OS niet, of dat nou binnen of buiten onderhoud zit.

Ten derde is het zo dat als je OS zou oud is dan zijn je applicaties dat waarschijnlijk ook en zou migreren naar iets anders wel eens lastig kunnen worden. Zeker als de rest van de omgeving ook zo oud is

Dit is een aanname waar ik niet zo veel mee kan op argumentatief vlak.
Statistisch kan dit best kloppen maar het lijkt me geen gegeven.

Ten vierde wil je niet dat er nieuwe systemen worden ingericht die in backwards-compatibility mode (of zo iets) moeten draaien om compatible te zijn met je 10 jaar oude servers. Neem bijvoorbeeld SSH, het SSH v1 protocol is al jaren geleden uitgeschakeld. Toch zie ik nog steeds systemen die de oude versie moeten blijven gebruiken vanwege (vermeende) compatibility met nog oudere systemen.

Eens. Maar ook hier hoeft natuurlijk niet persé sprake van te zijn.

In het kort komt het er op neer dat je de randen van support niet moet opzoeken maar daar ver weg moet blijven. Hoe langer je wacht hoe minder bewegingsruimte je hebt. Als je te lang wacht kun je geen kant op als er iets gebeurt.

Wederom eens, maar voor veel mensen is juni nog ver weg.
Ik haal hier al met niet echt een deftige rechtvaardig uit voor "je zit nog een RHEL 7 dus beveiliging boeit je niet".

[CAPSLOCK2000]

Ik heb geen ervaring in omgevingen waar ik zelf niet gewoon achter alle knoppen zit of iemand kan spreken die dat zit, dus ik zal me voorzichtig uitdrukken, maar een jaar om een server te vervangen vind ik toch echt wel naarstig veel tijd.

Daar ben ik het helemaal mee eens, maar in praktij ken ik migraties die meer dan vijf jaar lopen . En dan druk ík me voorzichtig uit

Ik heb het natuurlijk niet alleen over de tijd die nodig is om op de knoppen te drukken maar het hele proces inclusief communicatie met de gebruiker, research naar de nieuwe versie, onderzoeken of het tijd is om te migreren naar iets anders, hoe dat dan moet, en, last but not least, vertragingen en problemen bij anderen waar je afhankelijk van bent. Het hoeft allemaal niet lang te duren maar het kan wel. In sommige omgevingen kun je dat met keiharde zakelijke SLAs afdekken maar in andere omgevingen is dat niet acceptabel (bv een ziekenhuis waar mensen dood gaan als de IT er mee stop).

"As is" is toch altijd het hele motto met OSS? Zeker als je in het CentOS landschap zit.

Je had het specifiek of RHEL (Red Hat Enterprise Linux). Dat is juist populair onder mensen die wel commerciele ondersteuning willen. Het idee van OSS is niet dat je alles zelf móet doen maar dat het kán. Je hóeft geen support af te nemen maar er staat nergens dat het niet mag. Je bent alleen niet verplicht om de oorspronkelijk auteur/eigenaar in te huren maar mag het ook door iemand anders laten doen. Je kan het ook zelf doen maar dat is niet de enige optie.

Zelf doen is mogelijk maar je moet het wel doen. Je kan niet zeggen "er zit geen support op dus we hoeven onderhoud te plegen".

Vertrouwen in deftig handelen up stream is impliciet of je gebruikt dat hele OS niet, of dat nou binnen of buiten onderhoud zit.

Ik weet niet zeker of ik je wel goed begrijp. Het klinkt nu alsof je zegt dat je er maar op moet vertrouwen dat upstream alle software oneindig lang blijft ondersteunen. Dat begrijp ik vast verkeerd. Niemand kan software oneindig lang ondersteunen, aan alles komt een eind. Van te voren duidelijk aangeven hoe lang je support kan geven (al dan niet van commercieel contract) is juist een manier vertrouwen te scheppen.

Het hoeft ook niet commercieel te zijn. Debian geeft ook duidelijke grenzen aan over hoe lang je support kan verwachten op hun software.

Dit is een aanname waar ik niet zo veel mee kan op argumentatief vlak.
Statistisch kan dit best kloppen maar het lijkt me geen gegeven.

Het is inderdaad geen gegeven, vandaar ook dat ik het woord "waarschijnlijk" gebruikte. Maar ik denk dat de kans groot genoeg is dat je er maar beter rekening mee kan houden.

Eens. Maar ook hier hoeft natuurlijk niet persé sprake van te zijn.

Klopt, het is allemaal niet 100% zeker. Door een rood stoplicht rijden is geen 100% garantie op een ongeluk of een boete. Een verstandige automobilist neemt die gok niet en stopt altijd voor rood.

Als alles vooraf zeker was dan hadden we deze discussie niet. Je moet in het leven rekening houden met tegenslagen. Als je eerst 9 jaar niks doet en dan 1 jaar hebt om je server te upgraden dan denk ik dat je te veel risico neemt. Het kan goedkomen maar het kan ook mis gaan, zoals alles in het leven. Als het niet goed gaat heb ik liever te maken met jonge software dan met antiek waarvan niemand nog weet hoe het werkt. Al is het maar omdat ik bij jonge software meer tijd heb om een andere oplossing te zoeken.

Ik haal hier al met niet echt een deftige rechtvaardig uit voor "je zit nog een RHEL 7 dus beveiliging boeit je niet".

Ok, goed, jouw boeit het wel, maar je klant niet. Of, anders bekeken, er zijn andere zaken die méér boeien.
Laat ik het omdraaien: "Als security prioriteit heeft dan zou je niet meer op RHEL7 zitten." Zie het als een vorm van kansberekening of risicomanagement. Hoe ouder een systeem hoe groter de kans op complicaties en hoe meer tijd je zou moeten resereveren om met complicaties om te gaan. Dat geldt niet alleen voor security maar voor alle problemen waar je mee te maken zou kunnen krijgen bij oude software. Bij RHEL7 is de kans op complicaties statistich gezien vrij groot en de tijd om die op te vangen vrij klein. Dat is een risico.

[gorgi_19]

Ze hebben meer dan een jaar vooraf ankondiging gedaan (bijna 15 maanden!), dus kondigen ze het ruim vooraf aan. Er zijn genoeg alternatieven voorhanden.

Ze hebben geen mogelijkheden meer omdat ze afhankelijk zijn van een externe component.

Het is niet dat ze dit een weekje vooraf bedenken.

[Polderviking]

Ik zeg dan ook nergens dat het termijn van aankondiging onredelijk is.
Gaat me puur om het aanpassen/verkorten van een eerder gestelde deadline.
Hele idee van LTS releases is toch wel precies dat.

[The Zep Man]

Gaat me puur om het aanpassen/verkorten van een eerder gestelde deadline.
Hele idee van LTS releases is toch wel precies dat.

Het hele idee van LTS is dat er over een lange periode (veilige) ondersteuning wordt gegeven. Gezien OpenSSL integraal en essentieel daarvoor is, is het logisch dat de ondersteuningsperiode van Node.js werd aangepast aan de ondersteuningsperiode van OpenSSL.

De deadline werd op tijd met een goede reden aangepast. Gezien ik aanneem dat je geen servicecontract hebt afgesloten voor deze oudere versies van Node.js en OpenSSL heb je twee keuzes: accepteren en op tijd plannen, of geen gebruik maken van deze software.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:12]

[ThaStealth]

De OpenSSL v1.1.1 library blijft het na vandaag gewoon ook nog doen, dus software wat erop gebouwd is kan gewoon blijven werken. Dat NodeJS deze aankondiging aangerijpt om hun eigen product eerder niet meer te ondersteunen vind ik wel raar. Er kunnen namelijk nog altijd beveiligingsissues optreden in v16 die niets met OpenSSL te maken hebben, die worden niet meer gepatched.

De vraag is natuurlijk wel of je nog v16 moet willen gebruiken als je weet dat er een niet meer ondersteunde library in zit.

@Blokker_1999 NodeJS had natuurlijk een disclaimer kunnen plaatsen bij de v16 versie dat ze nog wel security patches krijgen van NodeJS, maar als het probleem in OpenSSL zit ze dit niet kunnen/zullen fixen.

Ik denk dat diezelfde groep mensen nu ook met een onveilige omgeving zitten omdat ze ervanuit gingen nog enkele maanden te hebben (de groep die nooit zal updaten laat ik even buiten beschouwing)

[Reactie gewijzigd door ThaStealth op 22 juli 2024 16:12]

[Blokker_1999]

En wat als er ineens een issue in OpenSSL 1.1.1 opduikt? Dat is uiteraard de reden dat men dit doet. Als je het gewoon blijft ondersteunen en mensen blijven het gebruiken maar dan ineens zit er een beveiligingsprobleem in OpenSSL zit je met een onveilige omgeving en geen plan om er op enkele dagen vanaf te geraken.

[Anoniem: 718943]

Hoe kun je nu support leveren op iets waarvan een subset geen support heeft? Support lever je op heel je product, een eis daarvan is dat je de support op componenten waarover je zelf geen controle hebt, af kunt schuiven.

Anders is het geen support meer, maar best effort; "ik kijk wat ik kan doen met de componenten waar in controle over heb, is het iets in OpenSSL, tja, jammer kan ik ook niets aan doen en de leverancier support het niet, zoek dan maar een ander product."

[CAPSLOCK2000]

Dat NodeJS deze aankondiging aangerijpt om hun eigen product eerder niet meer te ondersteunen vind ik wel raar. Er kunnen namelijk nog altijd beveiligingsissues optreden in v16 die niets met OpenSSL te maken hebben, die worden niet meer gepatched.

Ik denk dat je het vooral heel pragmatisch moet zien. Er is steeds meer focus op security en oude software onderhouden is moeilijk en duur. Als je het krap hebt moet je grenzen stellen.

Op hun website geven ze duidelijk aan dat ze verschillende opties hebben overwogen en dat die allemaal neerkomen op erg veel moeite voor een zeer beperkt resultaat. Het zou mensen maar misleiden, dus zeggen ze liever eerlijk dat het gewoon niet meer mogelijk is om de oude versie te ondersteunen.

[Polderviking]

De deadline werd op tijd met een goede reden aangepast.

Ook dat spreek ik niet tegen. Maar dat doet niks af aan mijn punt. Ook je gehamer op servicecontracten niet.

[sfranken]

Je kiest ervoor om de 1e zin uit de reactie te negeren, prima, maar hier draait het om:

Het hele idee van LTS is dat er over een lange periode (veilige) ondersteuning wordt gegeven. Gezien OpenSSL integraal en essentieel daarvoor is, is het logisch dat de ondersteuningsperiode van Node.js werd aangepast aan de ondersteuningsperiode van OpenSSL.

Ik heb het belangrijkste deel van de zin even dikgedrukt gemaakt voor je. Een LTS wil niet zeggen dat het maar zonder support doorgaan is als deze eenmaal is uitgebracht. Juist bij een LTS wil ik zulk gedrag wat NodeJS hier gedaan heeft zien. Je moet het immers niet willen dat dit onder het spreekwoordelijke vloerkleed was geveegd, toch? En dan, mocht het foutgaan/uitlekken, zou jij waarschijnlijk gereageerd hebben dat dit soort gedrag écht niet kan en waarom er niemand was die dit (tijdig) heeft aangekondigd?

Sorry, maar je komt nu een beetje over als iemand die z'n vingers in z'n oren steekt en heel hard LALALALA roept en accepteert wat voor jou goed uitkomt, en de rest naast zich neer legt.

[divvid]

Wees een vent en update gewoon je zooi op tijd.(of blijf bij, dan heb je dat gezeur niet)

[The Zep Man]

Gaat me puur om het aanpassen/verkorten van een eerder gestelde deadline.

Deadlines worden wel eens aangepast in de echte wereld. Deal with it. zeker omdat het een gratis product betreft dat veiligheid verkiest boven eerder gemaakte beloftes die niet waargemaakt kunnen worden.

[Blokker_1999]

Het is heel eenvoudig om alles als irrelevant te bestempelen, maar wat wil je dan? Geen LTS aankondigen? Mensen geen enkel vooruitzicht geven op ondersteuning? Soms heb je geen keuze. Je brengt een product uit in je LTS cyclus en op dat moment is er nog geen sprake van een EOL van OpenSSL 1.1.1. Het enige wat je nog zou kunnen doen is een * bij de term LTS zetten waarbij je aangeeft afhankelijk te zijn van derde partijen.

En zolang al de aankondigingen goed op tijd komen, kan iedereen er zich op aanpassen. Is het leuk om ineens enkele maanden vroeger te moeten vervangen, mogelijks je testtijd te verkorten en je deployment te versnellen? Neen, uiteraard niet. En ja, dat kost geld. Maar je kan mogelijks ook andere mitigerende maatregelen treffen.

De enige manier om te bekomen wat jij wenst is wanneer je zelf maar even OpenSSL begint te forken en te onderhouden, maar waar ben je dan in hemelsnaam mee bezig?

[vrow]

Ik ben het hier toch met @Polderviking eens.
Als iets gratis is betekent dat niet dat het vrijblijvend is.
Als je een LTS-datum belooft, moet je dus afspraken hebben met alle onderliggende leveranciers van componenten. Zo simpel is het.

Ik snap dat dat lastig is en misschien zelfs onmogelijk. Dat is prima, maar dan kun je dus gewoon geen LTS-versie uitbrengen. Je kunt die datum in de verre toekomst namelijk helemaal niet beloven omdat je die tijdspanne niet kunt overzien voor al je componenten.

[martijnvanegdom]

Ja wel, het is zo simpel. Waar iedereen hier aan voorbij gaat is de licentie van Node:

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
IN THE SOFTWARE.

(zie https://github.com/nodejs/node/blob/main/LICENSE)

Dat is waar je mee instemt als je Node gaat gebruiken.

[vrow]

Oneens. Dat je als gratis product of dienst niet aansprakelijk wilt kunnen worden gesteld, dat vind ik logisch.

Maar moreel kun je stellen: als jij die datum niet kunt garanderen vanwege reden xyz die best geldig is, beloof dan simpelweg die datum ook niet. Dan is er geen enkele discussie en ben je er helemaal vanaf. Dat is wat ik probeer te zeggen en @Polderviking volgens mij ook (maar dat weet ik niet zeker, dat vertelt hij misschien zelf nog wel zometeen)

[gorgi_19]

Met die redenatie maak je het dus onmogelijk voor opensource om gratis LTS aan te bieden.

Neem bijvoorbeeld de supportcontracten voor alleen openssl. Die kosten 50.000 euro per jaar.
https://www.openssl.org/support/contracts.html

Neem enkele andere componenten die ze gebruiken en het bedrag gaat enorm oplopen.
Of je krijgt constructies waarbij je bepaalde onderdelen 'los' moet downloaden, zodat ze buiten de support vallen, maar eigenlijk ook niet zonder kunnen.

Dan neem ik voor lief dat een LTS versie in enkele uitzonderlijke gevallen niet 5 jaar support heeft, maar 4,25 jaar en dat dit na 3 jaar aangekondigd wordt. Het is lange termijn, het is overmacht, dit is niet te voorzien en ligt buiten hun aard en er is een alternatief.

[Reactie gewijzigd door gorgi_19 op 22 juli 2024 16:12]

[Polderviking]

Als je voor de tweede keer moet terugkomen op een supportdatum kan je allicht in ieder geval beter kortere data vaststellen.

Of gewoon niet aan long term support doen doen als je iedereen gewoon op het actuele wil hebben, dan zal iedereen gewoon hun processen er omheen moeten vouwen.

Ik snap die gepikeerde reacties op wat ik zeg niet zo eerlijk gezegd.

[The Zep Man]

Dat je gaat pielen met je support datum moet je niet te veel hebben denk ik... vind het best twijfelachtig dat je "zomaar" zo'n datum drie kwart jaar naar voren trekt.

Ik vind het best wel twijfelachtig dat men 'zomaar' drie kwart jaar voor het verlopen van een deadline nog niet gemigreerd is naar N-1. De laatste versie is versie 20 en de huidige N-1 versie (LTS) is dus 18. Die is al in april 2022 uitgekomen, en in juni van dat jaar was de huidige EoL-datum al bekend. Je zou dus nu al op versie 18 moeten zitten en bezig moeten zijn met een migratie naar versie 20, of die zelfs al af moeten hebben.

Zie ook de planning hier. Als je in een 'maintenance'-periode zit, dan moet je niet wachten tot het uiterste om te migreren.

Uiteraard ben je ook vrij om een SLA af te sluiten met een third-party provider die jou van updates voorziet.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:12]

[Gropah]

Het is javascript. De helft van t werk daarin is onderhoud en versie upgrades verzorgen, omdat de andere helft vooral bezig is met shiny nieuwe zooi te vinden en gebruiken, of te schrijven.

(Gechargeerd natuurlijk)

[jcbvm]

En daarmee dus ook Angular 14… welke nog actief is als LTS tot november dit jaar

[Nozmordre]

Eigenlijk zouden zulke bizar lange LTS versies gewoon moeten worden afgeschaft.
Is alleen maar op vraag van managers die 100% van de tijd willen besteden aan "nieuwe" dingen en niks aan LCM willen doen en enorme technische schuld opbouwen. NodeJs 20.6 is al uit, gewoon migreren. Nee, niet moeilijk doen, gewoon migreren, gewoon altijd op de nieuwste versie zitten. Het is echt niet zo moeilijk.

[dcm360]

Systeembeheerders kunnen de betreffende software updaten naar OpenSSL 3.0 of OpenSSL 3.1.

Dat lijkt mij op zich nog wel een uitdaging voor systeembeheerders, want software moet wel specifiek gemaakt zijn om te werken met de nieuwere versie. In een ideale wereld zou dat geen probleem zijn, maar in de praktijk wordt er veel software gebruikt waar geen update voor beschikbaar zal komen.

[_JGC_]

Van 1.1 naar 3.0/3.1 is op zich niet zo'n idiote overgang qua API.

Van 0.9.8 en 1.0.x naar 1.1 was destijds een hele grote overgang. Ik heb nog heel veel legacy software zitten herschrijven toen ik die migratie deed bij Archlinux.

Maargoed, dit gaat dus om de upstream support. Er zijn nog een aantal linux distributies met 1.1 in de repository, die worden nog gewoon onderhouden. RHEL7, Ubuntu LTS 20.04, Debian 10 en Debian 11 gaan echt niet zomaar even naar 3.0 upgraden. Die blijven fixes backporten. RHEL7 zit zelfs nog op 1.0.2.

[CAPSLOCK2000]

Maargoed, dit gaat dus om de upstream support. Er zijn nog een aantal linux distributies met 1.1 in de repository, die worden nog gewoon onderhouden. RHEL7, Ubuntu LTS 20.04, Debian 10 en Debian 11 gaan echt niet zomaar even naar 3.0 upgraden. Die blijven fixes backporten. RHEL7 zit zelfs nog op 1.0.2.

Dat is wel best effort he. OpenSSL heeft de grootste om voldoende medewerking te krijgen van capabele programmeurs met kennis van security om de huidige versie bij te werken. Het is een beetje een illusie dat er wel mensen zijn om de oude versies echt goed te onderhouden. Ik weet dat de distributies daar een steentje aan bij dragen maar ik zou me er niet al te veel van voorstellen. Het is ook geen garantie dat alles nog gedicht kan worden. Daarnaast wordt er ook niet meer actief onderzocht of oude versies kwetsbaar zijn.

Ik heb veel respect voor het werk dat de distros doen maar als ik zie hoeveel moeite we hebben om de nieuwste versie te onderhouden dan zou ik niet op gokken dat die oude versie wel goed ondersteunt wordt.

Ik zou zeker niet wachten tot het punt bereikt is dat je zeker weet dat het niet meer gaat. Je migratie had nu eigenlijk al klaar moeten zijn. (tip: development versies staan niet voor niets online zodat je kan beginnen met testen voordat er een stabiele versie uit is).

Iedereen die vindt dat 2 jaar te kort is: welkom op het moderne internet. De keuze is meedoen of gehackt worden. De wereld gaat verder en security is steeds belangrijker, steeds vaker patchen en upgraden hoort daar ook bij. De tijd dat je 5 jaar niet naar een server hoefde om te kijken is voorbij.

OpenSSL is belangrijk genoeg dat ik verwacht dat de ergste problemen toch nog wel een fix krijgen van de distributies, maar dat kan op iedere moment onmogelijk worden en ophouden. Wacht daar niet op.

[rbr320]

De wereld gaat verder en security is steeds belangrijker, steeds vaker patchen en upgraden hoort daar ook bij. De tijd dat je 5 jaar niet naar een server hoefde om te kijken is voorbij.

Mee eens. Niet helemaal gerelateerd aan het onderwerp maar als ik bij een klant binnen kom en daar servers zie met een uptime van meerdere maanden of zelfs ruim meer dan een jaar, dan ga ik vragen stellen.

Verder ben ik het helemaal met je eens dat je niet moet blijven hangen bij een oudere versie van je distributie omdat deze nog in support is en je er dus vanuit gaat dat het allemaal wel goed komt. Het verbaast me nog steeds hoeveel organisaties, zowel overheid, non-profit als commercieel, bang lijken voor updates/upgrades en dus maar gewoon het minimale doen op dat gebied. Als je nu nog machines uitrolt met bijvoorbeeld RHEL 7 ben je gewoon niet goed bezig en veel te laat met nadenken over je migratieplan. Life cycle management lijkt nog een behoorlijk ondergeschoven kindje.

[_JGC_]

In geval van Debian 12 is die versie nog maar een paar maanden uit. Ik heb klanten met Percona Cluster draaien waar support voor Debian 12 nog in de testfase is. Klanten met Plesk op Debian hebben helemaal geen ondersteuning voor 12. Debian 12 is de eerste versie met OpenSSL 3.0.

[rbr320]

Dat is allemaal prima, @CAPSLOCK2000 en ik zeggen ook niet dat je vandaag al geupgrade moet zijn naar de laatste versie, maar denk in ieder geval na over je upgrade traject en doe alvast zoveel mogelijk voorbereidend werk. Bij te veel organisaties leunt men achterover met het idee dat alles goed gaat zolang alle software nog binnen de support contracten is.

Zorg wel dat je nu op N-1 zit, wat in geval van Debian versie 11 is en in geval van RHEL versie 8. Dat bedoelde ik te zeggen met dat als je nu nog nieuwe infra uitrolt op basis van Debian 10 of RHEL 7, je niet goed bezig bent.

[CAPSLOCK2000]

Dat is allemaal prima, @CAPSLOCK2000 en ik zeggen ook niet dat je vandaag al geupgrade moet zijn naar de laatste versie, maar denk in ieder geval na over je upgrade traject en doe alvast zoveel mogelijk voorbereidend werk. Bij te veel organisaties leunt men achterover met het idee dat alles goed gaat zolang alle software nog binnen de support contracten is.

Zorg wel dat je nu op N-1 zit, wat in geval van Debian versie 11 is en in geval van RHEL versie 8. Dat bedoelde ik te zeggen met dat als je nu nog nieuwe infra uitrolt op basis van Debian 10 of RHEL 7, je niet goed bezig bent.

We zitten behoorlijk op één lijn maar ik wil toch nog en verduidelijken hoe ik er precies in sta.
Het doel moet zijn om (in productie) altijd de huidige versie te draaien (versie "N").
Uiteraard moet er wel tijd zijn voor migratie, dus N-1 is op zich acceptabel, zolang je upgrade maar voltooid is voor N+1 uit komt.

Daarmee is niet gezegd dat N-2 onveilig is. In praktijk is N-2 prima veilig en dat is maar goed ook want er zullen altijd situaties zijn waarin je de planning niet haalt en langer moet doodraaien met een oud systeem.
Als het systeem op dat moment N-2 is dan heb je nog even de tijd om een nieuw plan te maken en uit te voeren.

Als je wacht met upgraden tot het N-2 is dan weet je dat een deel van de systemen het niet zal halen en N-3 worden. Daar komt bij dat oude systemen lastiger te vervangen/upgraden zijn dan nieuwe. Deels omdat de kennis is weggezakt, deels omdat makkelijke systemen meestal voorrang krijgen. Als je eenmaal N-3 bereikt begint het een tijdbom te worden. Het wordt steeds moeilijker en duurder om nog ondersteuning te krijgen maar ook om dingen te veranderen.

Als je N-4 bereikt (na 8 jaar) kun je alleen nog maar een brief aan management sturen want die oude systemen worden een blok aan je been die het ook moeilijk maken om je andere systemen modern te houden (bv omdat je SSL configuratie niet meer compatible is, om nog even on topic te zijn ).

Eigenlijk kijk ik liever de andere kan top. In plaats van te focussen op het laatste moment waarop systemen kunnen worden geupgrade adviseer ik om het juist zo vroeg mogelijk te doen. Liever nog vóór release dan erna. Test & Beta-versies zijn er niet voor niets. Test die zodat je klaar bent voor de upgrade op het moment dat de software officieel wordt gereleased. Een extra test-vm'tje draaien zou vandaag de dag geen probleem meer moeten zijn.

[CAPSLOCK2000]

In geval van Debian 12 is die versie nog maar een paar maanden uit. Ik heb klanten met Percona Cluster draaien waar support voor Debian 12 nog in de testfase is. Klanten met Plesk op Debian hebben helemaal geen ondersteuning voor 12. Debian 12 is de eerste versie met OpenSSL 3.0.

Om even een beetje te prikkelen:
Wanneer is er begonnen met Debian 12 te testen? Op het moment dat definitieve versie uit kwam of op het moment dat de eerste Testing-versie beschikbaar was?

Ik weet dat min of meer normaal is om pas naar een nieuwe versie te kijken op het moment dat de leverancier verklaart dat die af is. Bij closed source software is dat vaak ook pas het eerste moment dat je de software kan uitproberen.

Ik adviseer om zo vroeg mogelijk te beginnen met testen en deel te zijn van het ontwikkelproces. Zeker bij Open Source software.

Ten eerste weet je dan eerder waar je aan toe bent.
Ten tweede heb je meer kans om bugs op te (laten) lossen in de testperiode, na release is dat lastiger.
Ten derde kun je dan maximaal gebruik maken van de ondersteunde periode.
Ten vierde kun je helpen richting geven aan de ontwikkeling van de software.
Ten vijfde is het krijgen van hulp en support makkelijker op het moment dat software nieuw is en iedereen alles nog vers in het hoofd heeft.
Ten zesde helpt het om je kennis en vaardigheid op peil te houden als je meeleeft in het ontwikkelproces*.
Ten slotte weet je snel wanneer er show-stoppers zijn waardoor je langer met een oude versie met doen en heb je maximaal de tijd om een andere oplossing te zoeken.

Datzelfde geldt net zo zeer voor de leveranciers van Plesk en Percona. Ook die hadden nu eigenlijk klaar moeten zijn met hun werk. Ik snap traditioneel gezien waarom ze dat niet doen maar het is eigenlijk niet houdbaar. Debian komt iedere 2 jaar uit. Als Percona dan nog eens 6 maanden nodig heeft en Plesk daarna ook weer 6 maanden dan ben je al een jaar verder. Als je dan pas kan beginnen aan de systemen te upgraden die met Plesk beheerd worden dan loop je al direct ver achter.

* Je hoeft niet actief mee te programmeren ofzo, gewoon de mailinglijst of commits een beetje volgen is meestal genoeg.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 16:12]

[_JGC_]

Percona kwam na anderhalve maand met "we hebben het aangezet bij de build config" na een initiële "geen interesse, voor nu nog niet".

Het kan ook anders... MS heeft SQL server op linux. Daar hebben ze net technology preview voor Ubuntu 22.04. Productie op 20.04. Dat is N-2.

[Guru Evi]

De reden dat je oa. RHEL en Ubuntu Pro koopt is zodat je die developers wel hebt wanneer het nodig is. Het is software, het is niet 'onmogelijk', in het slechtste geval bouw je een API-proxy waar de oude routines vertaald worden naar de nieuwe versie.

Het enige 'probleem' dat je hebt is dat oa. SSL2/SSL3 (dat je niet meer zou mogen gebruiken) misschien wat minder getest wordt en dat je 'nieuwe fouten' niet meer kan herstellen. Maar je draait Ubuntu 14 dan ook niet voor nieuwe systemen, alles wat draait op die oude systemen draait er al jaren.

[CAPSLOCK2000]

De reden dat je oa. RHEL en Ubuntu Pro koopt is zodat je die developers wel hebt wanneer het nodig is. Het is software, het is niet 'onmogelijk', in het slechtste geval bouw je een API-proxy waar de oude routines vertaald worden naar de nieuwe versie.

Alles is oplosbaar als je oneindig veel geld en tijd hebt. In de realiteit zijn er forse grenzen aan wat je kan verwachten. Een hele API vertalen zou ik niet verwachten.

[Guru Evi]

Het is dan ook onwaarschijnlijk dat je OpenSSL volledig moet vervangen. Een deel van OpenSSL gaat door in de volgende versie, backport is grotendeels copy/paste voor “bestaande” algoritmes. API moet je ook niet volledig vertalen of van de bodem herschrijven, wolfSSL, libreSSL, BoringSSL etc heeft een OpenSSL-compatibele API, meestal is de vertaallaag in een paar maanden geschreven. dus het is echt niet onmogelijk.

[Reactie gewijzigd door Guru Evi op 22 juli 2024 16:12]

[wica]

Als je naar OpenSSL 3 wilt, moet je door gaan naar RHEL9.

Zolang je nog (extended) support hebt op je RHEL7 of 8 zit je wel goed. Daar betaal je tenslotte voor.

Maar als je toch al van plan bent te upgraden van je OS., zou ik het ieder geval doen naar een disro die openssl 3 ondersteund.

[MOmax]

Volgens mij zit het ook nog dik ingebouwd in Cisco Anyconnect 4.10 - dat gebruikt wordt door het bedrijf waar ik werk voor VPN.
Vraag: onderhoudt Cisco ook een eigen branche van OpenSSL of is dit product nu ook EOL?

[Guru Evi]

Cisco gebruikt zover ik weet OpenSSL 1.1.1 adhv de security bugs die ze hebben. Het is niet omdat OpenSSL 1.1.1 EOL is dat alle producten gebaseerd op OpenSSL EOL zijn, het enigste verschil voor oa. Cisco is dat ze niet verder security bugs gaan herstellen, dus zolang er geen CVE is dan is er geen probleem.

Wat daarna gebeurt is afhankelijk, Windows XP en oude macOS krijgen af en toe ook nog eens een update als er iets 'heel erg' is. Het is open source, oa. Ubuntu en RHEL moeten tenminste nog een paar jaren met OpenSSL 1.1.1 rondlopen (RHEL 6 en Ubuntu 14 verloopt qua "Extended Support" maar in 2024 en daarmee verloopt waarschijnlijk de laatste support van OpenSSL 1.0, tussen Ubuntu 16 en 20 heb je OpenSSL 1.1 en dan de opvolger OpenSSL 3 is slechts in de huidige versie (Jammy/RHEL9) vervangen dus ik denk dat je nog 10 jaar backports zal krijgen.

[The Zep Man]

Vraag: onderhoudt Cisco ook een eigen branche van OpenSSL of is dit product nu ook EOL?

Dat kan je beter bij Cisco vragen, denk ik. In principe zou je goed moeten zitten als je binnen de gestelde ondersteuningsperiodes blijft. In de praktijk loont het om een oogje te houden op meegeleverde middleware en de kwetsbaarheden die daarin zitten, en om leveranciers op tijd te verwittigen van mogelijke problemen waar je je als klant zorgen om maakt.

[gorgi_19]

Cisco heeft een dusdanig groot belang, dat het me niet zou verbazen als ze een support contract met OpenSSL hebben afgesloten:
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.

Dus mochten er security issues komen, dan kan cisco die nog krijgen. Die fixes worden alleen niet meer publiek beschikbaar gemaakt.

[ta_chi79]

Je kan ook gewoon een support contract afsluiten ($50.000/y) en dan krijg je ook van EOL versies nog gewoon support.

Dat heeft een van onze leveranciers ook gedaan (zeggen ze), maar blijven vervolgens nog steeds 3 verschillende versies van nog oudere unsupported versies van OpenSSL meeleveren bij hun product

[Guru Evi]

Zolang het werkt en ondersteunt wordt, zie ik het probleem niet. $50k/y is waarschijnlijk goedkoper dan je eigen applicatie herstellen. Het probleem blijft bij de klant, waarom vertrouw je op een leverancier die het kapitaal niet heeft om hun applicatie te hercompileren. Binnen nu en een paar jaar verder gaan ze inderdaad nog steeds die oude applicatie leveren, zit je vandaag op Windows 10 dan blijf jij steken op Windows 10 want zij kunnen niet upgraden, komt er iets nieuw op de markt of, gaan ze niet mee.

En die keten gaat zo langzaam door totdat JIJ met een Windows NT 4 machine zit omdat de leverancier nooit een nieuwe versie aangeleverd heeft en uiteindelijk stilletjes aan failliet gegaan is.

[Reactie gewijzigd door Guru Evi op 22 juli 2024 16:12]

[wica]

Paniek om niets. Bijna niemand gebruik openssl 1.1.1 lib direct. Meestal gebruiken ze de lib die mee geleverd wordt door hun O.S.

Neem als voorbeeld RHEL8 en alle varianten er van. Dit O.S. is pas in 2029 EOL. Maar heeft wel openssl 1.1.1.

[freaky]

Paniek is een beetje zwaar, maar zowat ieder stukje OSS software wat TLS doet gebruikt het.

Veel distro's zullen wel backporten, maar daar komt wel wat bij kijken zonder upstream ondersteuning.

[markjanssen]

Eerder deze week is er nog een laatste security-patch uitgekomen voor een minor/low issue... Daarmee was wel duidelijk dat het daarna echt afgelopen was met de 1.1 tree.

Helaas is openssl 3.x compatibility in veel software nog niet geweldig... hopelijk neemt dat wat meer een vaart nu 1.1 echt EOL is.

[Anoniem: 80910]

Je kunt ook docker images gebruiken als test. Helaas zit mijn provider nog op debian 11, maar zoals gezegd die heeft eol op juli 2024, net als debian 10.

[Jack Flushell]

FreeBSD zit voorlopig officieel vast op 1.1.1 tot versie 14 (2026), maar je kan 3.0 en 3.1 wel gebruiken via ports. Link. Best curieus dat zo'n security focused OS zo lang blijft hangen op iets wat dus nu EOL is. Een firewall pakket als OPNSense zit daardoor ook nog op 1.1.1 voorlopig.