Release OpenSSL 3.0 is uitgesteld tot oktober volgend jaar

OpenSSL 3.0 komt pas op zijn vroegst in het vierde kwartaal van volgend jaar uit. Dat is een vertraging van een half jaar. In de zomer van volgend jaar moet de eerste bèta van de code worden opgeleverd.

Ontwikkelaar Matt Caswell van OpenSSL beschrijft de vertraging in een voortgangsblog. Daarin staat dat de ontwikkelaars de voorgestelde deadline niet gaan redden en dat de software pas rond oktober volgend jaar moet uitkomen. Aanvankelijk had OpenSSL 3.0 al eind 2019 af moeten zijn, maar die deadline werd verplaatst naar 'medio 2020'. Nu blijkt ook dat te ambitieus te zijn geweest. OpenSSL 3.0 wordt naar verwachting aan het einde van het tweede kwartaal in bèta opgeleverd. De definitieve release volgt 'in het begin van het vierde kwartaal'.

De belangrijkste verandering van OpenSSL 3.0 is de toevoeging van zogeheten 'providers'. Er komen verschillende providers voor verschillende type encryptiealgoritmes. De default-provider implementeert de meestgebruikte algoritmes, maar er komt ook een Legacy Provider voor legacy-algoritmes en een provider voor algoritmes die met FIPS gevalideerd zijn.

Reacties (40)

Aangezien ik het zelf even moest opzoeken: FIPS validated betekend dat het algoritme is goedgekeurd voor gebruik bij de Amerikaanse overheid.

https://nl.m.wikipedia.or...ation_Processing_Standard

Edit: link toegevoegd

[Reactie gewijzigd door JeroenED op 8 november 2019 21:28]

Er staan ook wel degelijk eisen in als een validatie van de algoritmen voor gebruik en bijvoorbeeld het tijdig vernietigen van sleutelmateriaal. En dan zijn er natuurlijk nog de testvectoren waaraan de implementaties moeten voldoen, sleutelgroote en methodes van versleuteling, random generatie etc. Sowieso is het handig om bij een claim van FIPS uit te zoeken wat het precies betekend.

FIPS 140-2 is ook vaak een eis bij wide area netwerken in de financiële wereld.

Vooral een papieren tijger en risico afkopen, net als PCI compliance. In de praktijk zijn die systemen net zo goed te misbruiken als non-FIPS systemen.

Enige reden dat er wat mee gedaan wordt is om met de overheid te mogen werken.

[Reactie gewijzigd door johnkeates op 9 november 2019 00:45]

Ook veel Europese instanties eisen FIPS en / of Common Criteria. Hoewel zo'n systeem in de praktijk net zo kwetsbaar kan zijn, is het wel zo dat je in ieder geval aan een minimum aan eisen voldoet.

Dus het werken met de Amerikaanse overheid is zeker niet de *enige* reden.

Daarom schreef ik ook nergens 'amerika' of 'USA'.

Vooral een papieren tijger en risico afkopen, net als PCI compliance.

Ja en nee. Net als ISO 2700x is het voornamelijk bedoeld om aan te tonen dat men over iets heeft nagedacht. Als het fout gaat kan men niet meer terugvallen op "wir haben es nicht gewußt".

Ja en nee. ISO20k en 27k hebben nog wel wat meer denkwerk achter zich zitten, die zijn inderdaad vooral gericht op 'zorg dat je er over nagedacht hebt en dat je er een proces voor ingericht hebt en zorg dat je daar ook weer een proces voor controle op ingericht hebt'. PCI DSS enz. hebben toch wel erg veel directe implementatie eisen, zoals '3DES' wat toch echt geen zin meer heeft. Of ze gaan van fysieke omgevingen uit. Of van tape backups als eerste lijn. Of van on-line backup als enige toegestane optie (slecht plan met ransomware).

Moet ik er dan vooral maar van wegblijven? Zodra de US overheid iets valideert kan het zomaar zijn dat zij een methode hebben om deze versleuteling te ontcijferen... :-/

FIPS zelf is geen encryptie methode maar een certificering en werkomschrijving. O.a. SHA-512 is FIPS.

Ik heb momenteel OpenSSL 1.1.1d geinstalleerd op mijn systeem.
Slaan ze de 2.x reeks over?

Slaan ze de 2.x reeks over?

Ja. Vanaf versie 3 gaan de OpenSSL en OpenSSL FIPS versienummers synchroon lopen. Op dit moment heeft de FIPS module van OpenSSL 1.x versienummer 2.x. Vanaf OpenSSL 3 zijn ze allebei versie 3.

edit:

Zie https://www.openssl.org/blog/blog/2018/11/28/version/

[Reactie gewijzigd door Redsandro op 8 november 2019 22:03]

Ze hadden het beter naar OpenTLS X.0 kunnen hernoemen, OpenSSL hint nog naar het SSL 3.0 protocol, maar dan is al jaren onveilig verklaard.

Maar het is de naamsbekendheid die je niet wil verliezen. Alle gebruikers kennen het als OpenSSL. Ga je het hernoemen gaan mensen denken dat een ander product gebruikt wordt.

Het gaat niet om de afkorting maar de betekenis er achter.

SSL staat voor Secure Socket Layer. Dat wil zeggen dat de stekker op een nader te bepalen niveau (van de stack van de iso-osi standaard) met van security wordt voorzien.

TLS staat voor Transport Layer Security. Hierbij wordt dus expliciet de transport laag van security voorzien.

Dat de tool OpenSSL gebruik maakt van TLS is 1 van de vele mogelijkheden. Met de huidige mogelijkheid van 'providers' houdt niemand je tegen om een ssl provider te maken, of zelfs een provider die niet versleutelt, bijvoorbeeld voor test en onderzoek doeleinden.

"iso-osi" standaard? Er zijn een heleboel ISO standaarden, maar OSI in deze context verwijst naar het theoretische OSI 7-laags model. En TCP/IP is géén ISO standaard en volgt niet het OSI-lagen model.

Klopt helemaal. De transport layer is er wel 1. Het woord layer in ssl verwijst wel naar dergelijke lagen en socket naar de aansluiting tussen de lagen.
Tcp/ip is ongeveer laag 1 en de helft van laag 2.
Dat gezegd hebbende kan de socket ook midden in een iso-osi laag zitten.

Inmiddels prefereer ik inderdaad LibreSSL in plaats van OpenSSL. Dat het gecertificeerd wordt door de Amerikaanse overheid zegt me ook niet zoveel. Als er zwakheden in zitten zullen ze het niet vertellen maar wel laten gebruiken door de drieletterige organisaties.

Leuk man, prima dat jij dit prefereert....helaas voor jouw gaat LibreSSL op de voorheen ingeslagen (verkeerde) voet van OpenSSL verder, daarom is dus gelijk een fork niet altijd beter...of je moet van spaghetti (code) houden?

Niet echt LibreSSL is een fork door het OpenBSD team en die staan bepaald niet bekend om hun spaghetticode.
Kleine quote van wiki: After the Heartbleed security vulnerability was discovered in OpenSSL, the OpenBSD team audited the codebase and decided it was necessary to fork OpenSSL to remove dangerous code.[.............................................]. In the first week of development, more than 90,000 lines of C code were removed. Unused code was removed, and support for obsolete operating systems was removed

Gezien de omvang van openSSL zijn 90000 regels code redelijk beperkt van omvang. Als je support voor platformen wegsloopt, dan krijg je minder code. Bij openSSL is ook een hoop code conditioneel. Effectief is die code bij compileren weg, als de functionaliteit uit staat. Mijn ervaring met de openSSL contributors is dat ze goed weten waarover ze praten.

Feit is natuurlijk wel dat als je een product forked waarvan je weet dat de code eigenlijk onbeheersbaar is geworden dat je dan met moeilijkbeheersbare code blijft zitten. Dat was net de reden van OpenSSL om met versie 3 te beginnen. Een clean sheet waar men modulair kan gaan werken.

Met al die forks die er tegenwoordig zijn, zitten er nog veel te wachten op OpenSSL 3.0?
Als je het overzicht van Wikipedia neemt, zie je genoeg andere die ontwikkeling zijn.

Ik heb het een tijd niet meer gevolgd, maar ik heb altijd begrepen dat OpenSSL nog altijd veel problemen heeft met hun implementatie en dus velen zijn overgestapt op iets anders.

Wat bedoel je met zitten wachten op openssl? Dat er veel diversiteit is geeft al aan dat er veel verschillende meningen zijn over wat de ontwikkelaar of opdrachtgever nodig meent te hebben. Daar tegenover staat dat er diverse software bestaat met ieder zo de eigen afhankelijkheden. Veel systemen hebben op de een of andere manier wel een software afhankelijkheid waardoor openssl geinstalleerd is. Of dat is omdat de gebruiker ook op zit te wachten is weer wat anders.

Omdat de betrouwbaarheid van OpenSSL nogal te wensen over laat. Er is veel discussie of deze lib nog wel te vertrouwen is en/of niet vervangen moet worden door iets moderners/beters.

Maarja, dat is dan toch ook te zeggen van de forks, als de basis die je gebruikt niet te vertrouwen is, hoe kun je dan de fork wel vertrouwen?

Omdat een fork mogelijk andere beslissingen neemt dan 'de basis'. Vergeet niet hoeveel 'zooi' er dankzij die forks al uit is gegooid en weer wordt teruggemergd in de master.

Ondanks al die forks is OpenSSL nog altijd het meest gebruikt en net omdat het forks zijn blijven de meeste ook hard leunen op al het werk dat OpenSSL doet. Vele forks hebben echt niet de mankracht om op eigen benen verder te gaan. De enige 2 substantiële forks zijn LibreSSL (OpenBSD) en BoringSSL (Google).

Waarvan ik heb begrepen dat de laatste (BoringSSL) door Google niet wordt aangeraden ter vervanging van OpenSSL en ik begrijp een fork is van LibreSSL. Is LibreSSL niet de vervanger van OpenSSL op langer termijn? Al begrijp ik dat het ontwikkelen van dit soort libs niet erg eenvoudig is en dus ook niet zo een-twee-drie vervangen wordt.

PS. GnuTLS is toch ook een grote naam en actief in ontwikkeling?

GnuTLS heeft geen enkel verwantschap met OpenSSL. Er zijn nog een pak meer projecten die elks hun eigen implementatie doen. Google heeft daarnaast veel code ook gewoon gebackport naar OpenSSL en LibreSSL en zal BoringSSL in de eerste plaats voor interne doeleinden gebruiken.

LibreSSL is zeker niet zomaar de vervanger van OpenSSL op lange termijn. LibreSSL heeft een sterke focus op OpenBSD en heeft daarvoor heel wat dingen die ze niet nodig hebben eruit verwijderd waardoor ze achteraf opnieuw werk hebben moeten maken van het opnieuw compatibel maken ervan met macOS en Linux. Maar zijn ze bijvoorbeeld ook de FIPS 140 certificering verloren. Je moet ze echt als 2 aparte oplossingen zien voor hetzelfde probleem. Oplossingen met eenzelfde oorsprong, dat wel. Maar LibreSSL zal naar mijn bescheiden mening nooit zo groot worden als OpenSSL, al was het maar omdat de focus veel beperkter is. Maar daar waar het wel past kan het daardoor een betere keuze zijn.

En Wolf SSL dan? Deel open, maar ook deels commercieel.

Inderdaad, echter leveren grote distributies OpenSSL ipv de forks. Vraag is echter of die trend doorzet. De certificering/auditing is dan ook een poging om het slechte imago op te poetsen, hoewel het dus nog steeds mainstream geleverd wordt

1 beta klinkt eigenlijk ook wel weinig voor iets wat toch wel vrij belangrijk is voor menig internetverbinding?

Ik vraag me af waarom ze überhaupt een beta uitgeven; iedereen die test zal master gebruiken en bij het aangeven van bugs zal daar, neem ik aan, de voorkeur bij liggen. Een release candidate kan ik wel begrijpen.

Het is gewoon een press release momentje voor alle mensen die moeten/willen testen, dat wat er nu is testbaar en representatief (genoeg) is. Puur voor de communicatie met derden.

Waarom? Het overgrote gedeelte van de testen zal bij een bibliotheek zoals OpenSSL niet in het veld plaatsvinden. Ik kan me voorstellen dat de command line wat meer met gebruikerservaring te doen heeft, maar verder heb je aan 1 beta lijkt me voldoende.

Wie zegt dat het 1 enkele beta release zal worden? Men zal door de beta fase gaan waarin de code feature complete is maar waar men nog werk moet investeren in het oplossen van blokkerende bugs. Dat kan in 1 enkele fase, maar het zullen er al snel meerdere worden.

Als je als softwarebedrijf zaken wilt doen met de Amerikaanse overheid, dan moet je w.s. aan FIPS certificatie voldoen. Ik kan het zo 1-2-3 niet vinden, maar ergens heeft er bij OpenSSL iets gestaan dat FIPS te duur is. Kennelijk gaan ze nu toch wel mee?

Er zijn wel alternatieven, maar w.s. niet open source/free. Als je al software hebt, die op OpenSSL gebaseerd is, dan heb je een probleem als je op een andere variant, die wel FIPS certified is, moet overstappen.

Weet iemand of FIPS de wereld echt veiliger maakt?

Nee, want FIPS 140 schrijft een subset van encryptie standaarden voor die Amerikaanse overheden wel mogen gebruiken en de sterkte daarvan. Ze mogen geen nieuwere standaarden gebruiken omdat die de tand der tijd nog niet hebben doorstaan, terwijl ze waarschijnlijk wel sterker of sneller zijn.

Het verschil tussen OpenSSL en de forks zijn dat in er meer encryptie standaarden mogelijk zijn en je zelf moet filteren of aanzetten. Dat is nogal specialistisch en gaat nogal eens mis. In de FIPS mode valt het filteren gewoon weg, maar dan heb je wel te maken met oudere technieken. Tegenwoordig gaat met autoupdates van browsers de ondersteuning voor nieuwere standaarden zoals TLS 3 gewoon sneller dan vroeger.

Ik wil seks. Mijn foto's en video's zijn hier - http://na.to/ammirafoto