OpenSSL 3.0 is verschenen

Versie 3.0 van OpenSSL is na drie jaar ontwikkeling verschenen. Het ontwikkelteam heeft een flink aantal wijzigingen aangebracht in de populaire toolkit voor SSL en TLS. Deze is dan ook niet volledig backwards compatibel met vorige releases.

Aan de release van OpenSSL 3.0.0 gingen zeventien alfareleases, twee bètareleases en meer dan 7500 commits en bijdragen van meer dan 350 ontwikkelaars vooraf, meldt Matt Caswell van het OpenSSL Project. Tegenover de vorige versie, OpenSSL 1.1.1, die in 2018 verscheen, is de beschikbare documentatie volgens hem met 94 procent en de hoeveelheid coderegels met 54 procent toegenomen.

Een van de wijzigingen is dat OpenSSL voortaan onder een Apache License v2 in plaats van een eigen OpenSSL- of SSLeay-licentie valt. Nieuw is het 'provider'-concept, waarbij gebruikers kunnen specificeren welke provider ze willen gebruiken voor applicaties en deze providers maken algoritme-implementaties zoals cryptografische modules beschikbaar. Standaard zijn er vijf providers aanwezig en een ervan is die voor de Amerikaanse overheidsstandaard FIPS, oftewel Federal Information Processing Standards. Ook derde partijen kunnen providers beschikbaar maken die in kunnen haken op OpenSSL.

Het OpenSSL-team meldt in een uitgebreide changelog alle wijzigingen die zijn doorgevoerd. Omdat het om een major release gaat, moeten applicaties die nog een oudere versie van OpenSSL draaien, opnieuw gecompileerd worden. Daarbij kunnen waarschuwingen getoond worden over uitgefaseerde api's. De meerderheid van applicaties die werkten met OpenSSL 1.1.1, moet hoe dan ook ongewijzigd functioneren met versie 3.0.0, al kunnen in enkele gevallen wijzigingen doorgevoerd moeten worden, volgens het OpenSSL Project.

OpenSSL moest volgens de aanvankelijke planning in 2019 verschijnen, maar de release werd meer dan eens uitgesteld.

Reacties (38)

Het belangrijkste nieuws is eigenlijk wat er _niet_ in OpenSSL 3 zit: QUIC support; nodig voor HTTP/3.

Zie https://github.com/openssl/openssl/pull/8797 en https://www.openssl.org/blog/blog/2019/11/07/3.0-update/

In april 2019 was deze versie van openSSL al zo ver in ontwikkeling dat de pull request om QUIC toe te voegen 'te laat' zou zijn. Vervolgens 2,5 jaar 'development hell' en we hebben nu een nieuwe versie van OpenSSL maar nog steeds zonder QUIC support. Heel erg jammer, want inmiddels hebben Chrome, Edge en Firefox al HTTP/3 support. Maar als jij HTTP/3 wilt supporten met je eigen NGINX of Apache gaat dat dus niet werken (ja, er is een tech preview van NGINX en Cloudflare heeft ook een eigen patchset).

Maar dit betekent dus dat de 'grote' cloud-providers een extra voorsprong hebben op self-hosted: het is niet makkelijk mogelijk om self-hosted HTTP/3 te doen. En da's echt jammer. Mochten de OpenSSL-mensen wat meer hun best gedaan te hebben om de bestaande patchset te integreren, dan was dit waarschijnlijk nu veel makkelijker geweest!

Van wat ik lees komt de QUIC-support in dat merge request uit BoringSSL, wat ook gewoon een open source library is.

Dat Nginx nog geen HTTP/3-ondersteuning heeft, betekent niet dat je het niet kan inbouwen als ontwikkelaar als je wilt. Caddy kan al sinds minstens vorig jaar HTTP/3, CloudFlare heeft hun HTTP/3 stack open beschikbaar gesteld. en hun code bevat een voorbeeldserver. Als je meer aan Apache2 vast zit, is LiteSpeed wellicht een goed alternatief wat ook HTTP/3 en QUIC ondersteunt.

Mensen die self-hosting gebruiken hebben sowieso weinig voordelen aan het gebruik van HTTP/3, maar iedereen kan gewoon HTTP/3 aanzetten als ze dat echt willen; je hoeft alleen maar een proxy voor je applicatie te hangen. De traagheid zit in nginx en apache2, maar dat heeft meer te maken met de librarykeuzes en hoeveelheid beschikbare ontwikkeltijd van die projecten dan met de grote boze techreuzen.

Eerlijk gezegd vind ik QUIC als protocol helemaal niet thuishoren in een TLS-library, aangezien SSL/TLS en QUIC compleet andere protocollen zijn. Ik snap best dat de ontwikkelaars meer prioriteit aan andere issues geven. Persoonlijk vind ik protocolgerelateerde verbeteringen als eSNI belangrijker dan "zorgen dat OpenSSL werkt met Google Chrome", wat de oorzaak is geweest dat het gelinkte PR ooit gemaakt is.

Ja, het _kan_ met patches, dat schreef ik al. En het kan met BoringSSL. Maar als je `apt install nginx` wilt doen heb je dus geen enkele kans om HTTP/3 te kunnen gebruiken; en de komende tijd zal dat ook niet veranderen. Dus met NGINX of Apache, in pakketten van je Linux distro, krijg je geen HTTP/3. Ook niet de komende tijd. En da's gewoon heel jammer.

Als je apt install nginx wilt doen, zul je eerst je distro moeten upgraden, want zo'n protocolwijziging zal niet snel worden gebackport naar de huidige supported versies. Zodra de feature uitkomt, zul je dus sowieso (opnieuw) een apt dist-upgrade of do-release-upgrade zullen moeten uitvoeren, en alle gebroken softwarepakketten repareren.

Wil je modernere software, dan kun je vandaag nog uit de AUR altijd nog nginx-quic installeren via pacman (drie dagen geleden voor het laatst bijgewerkt), of de default nginx package uit Nix halen. Gebruik je een stabielere Linux-distro, dan zul je inderdaad even moeten wachten. De feature is gewoon nog niet stabiel, en daarvoor zul je de ontwikkelaars van Apache en Nginx ook even lief aan moeten kijken.

Ik verwacht sowieso eigenlijk niet dat Debian of Ubuntu op OpenSSL 3 overstappen; Ubuntu wellicht in de 21.10 unstable, maar Debian heeft net een major release gehad. Fedora target de upgrade naar OpenSSL 3 voor Fedora 36, welke over driekwart jaar pas uitkomt.

Is er een specifieke reden dat je HTTP/3 wilt? Voor zover ik heb kunnen zien heeft het alleen echt voordelen in superspecifieke gevallen (als je een miljoen servers beheert of als je veel klanten serveert met de equivalent van een 2G-verbinding over satelliet?).

In de US hebben 'we' zo'n 40 miljoen klanten. Een groot deel daarvan heeft een internet verbinding die slechter is dan de meest belabberde in Noord Nederland.

Kunnen we ons hier in NL met glas en
VDSL bijna niet voorstellen, maar ja: er is een goede use case voor QUIC.

Ook handig voor web push trouwens.

docker pull whatever

Netscape navigator ondersteund het ook niet. Boehoe.

Als het echt zo moeilijk is voor iemand zal de website/-app ws ook niet groot genoeg zijn om er genoeg baat bij te hebben.

Ik denk niet dat dat een probleem is. HTTP/3 is vooral leuk voor grote IT-reuzen. Net als HTTP/2 is HTTP/3 vooral door Google, voor Google. Als kleine webhoster of als je zelf je eigen website host heb je niet echt voordeel van HTTP/3. En een IT-reus als Google is prima in staat om z'n eigen QUIC implementatie te doen.

Nee, HTTP/3 is vooral leuk voor iedereen! Door de verbeteringen in het protocol krijg je snellere verbindingen. Je kan gemakkelijker, met minder latency, gegevens heen en weer sturen. En Google/Facebook/etc hebben dit nu aan staan op hun servers. Als jij een website of web-app draait, en je gebruikt geen CloudFlare of etc, dan is het nu best wel heel lastig om HTTP/3 te supporten, wat zorgt voor een (net iets mindere) gebruikerservaring.

Er zijn ook alternatieven die het al wel (experimenteel) ondersteunen zoals Caddy en Traefik.

Http2 maakte mijn nextcloud instance opeens veel sneller, dus het is niet alleen voor google.

Maar dit betekent dus dat de 'grote' cloud-providers een extra voorsprong hebben op self-hosted: het is niet makkelijk mogelijk om self-hosted HTTP/3 te doen. En da's echt jammer.

https://caddyserver.com/ gebruiken met:

{
servers {
protocol {
experimental_http3
}
}
}

[Reactie gewijzigd door ookhoi op 8 september 2021 16:23]

Ja, Caddy, dat kan ook, dat snap ik. Dat is wel mooi. Maar de 'standaard' webservers NGINX en Apache (zie ook https://w3techs.com/technologies/overview/web_server) kunnen dit dus niet uit zichzelf.

Wellicht een voordeel maar je bent bijvoorbeeld vrij om BoringSSL te gebruiken die wél QUIC ondersteund. Iets waar hier meer over gezegd wordt:

At the time of writing, OpenSSL does not support QUIC, and it might take many months before any operating system distributions ship with a QUIC‑enabled SSL/TLS library. Our QUIC implementation currently supports BoringSSL and the quictls fork of OpenSSL, which must be compiled with NGINX.

We expect the state of QUIC‑enabled SSL/TLS libraries to become clearer during the period when we are merging the nginx-quic development branch into NGINX mainline.

https://www.nginx.com/blo...uic-http-3-support-nginx/

Ach ik gok er op dat OpenSSL 3.x niet lang op zich zal laten wachten en het lijkt me dat men op dat moment ook QUIC ondersteuning zal toevoegen.

Met dit soort dingen is het eigenlijk heel erg simpel op een bepaald moment moet je nu eenmaal de knoop door hakken en een feature freeze afkondigen omdat je anders nooit een stabiele basis hebt om af te maken zodat je een goed product kunt afleveren.
Dat dat dan betekend dat bepaalde features buiten de boot vallen ach dat maakt weinig uit die kun je altijd mee nemen in een volgende release. Dat je vervolgens 2 jaar bezig bent met de release stabiel krijgen voor het de deur uit kan dat kan natuurlijk nooit de bedoeling zijn geweest.

Wat dat betreft is het gewoon onhandig van de QUIC developer(s) voor OpenSSL dat ze hun code niet net even eerder hadden afgeleverd omdat ze geweten moeten hebben dat de feature freeze er aan zat te komen. Maar ik neem aan dat ook zij op dat moment niet voorzagen dat er 2 jaar nodig zou zijn om de codebase zonder QUIC support de deur uit te doen. En daarom er dus voor kozen om dan de deadline maar te missen en gewoon een volgende release te gebruiken om deze functionaliteit toe te voegen.

Die van CloudFlare is wel goed toch?

QUIC komt inderdaad uit de stal van Google maar het is een open standaard en er zit zeker geen telemetrie in. Wat er nu gestandaardiseerd is door de IETF heeft ook flink wat aanpassingen ten opzichte van de originele QUIC van Google die nu gQUIC genoemd wordt.

Misschien ben je in de war met FLoC? Dat moet inderdaad dood in een hellevuur ja. Maar dat is ook geen standaard en je kan er simpel omheen door gewoon geen Chrome te gebruiken.

[Reactie gewijzigd door GekkePrutser op 8 september 2021 18:43]

De grootste nachtmerrie voor een developer is een niet backwards compatible versie van OpenSSL moeten integreren. Dit omdat OpenSSL vaak statisch wordt gelinkt in menig library waardoor er altijd symbol conflicten ontstaan. Ik acht de kans dan ook erg klein dat over een jaar er een substantieel deel van de code die OpenSSL 1.0.x gebruikt, geüpgrade heeft naar 2.x.

OpenSSL heeft op de meeste distributies symbol versioning ingeschakeld. Vroeger was dat idd niet het geval en had je altijd gezeik.

en de hoeveelheid coderegels met 54 procent toegenomen

Was dat niet juist het probleem met OpenSSL, en waarom er forks als LibreSSL gekomen waren, dat er teveel regels code waren in OpenSSL? Oplossing: meer regels code!

Dat was een slechte quote van Tweakers. Het originele artikel stelt: (nadruk toegevoegd)

I am also delighted to note that there has been a 94% increase in the amount of documentation that we have since OpenSSL 1.1.1 and an (adjusted) increase in the “lines of code” in our tests of 54%.

Oftewel de test suite is flink uitgebreid. Wat alleen maar goed kan zijn.

Dat was een slechte quote van Tweakers. Het originele artikel stelt: (nadruk toegevoegd)

[...]

Oftewel de test suite is flink uitgebreid. Wat alleen maar goed kan zijn.

Een goede correcte van de slechte Tweakers quote, maar ook een verradelijke aanname.
Nou verwacht ik dat het bij OpenSSL best goed zal zitten, maar niets is erger dan een management dat managed op lines-of-code increase... die statistiek is uitstekend te beinvloeden (en die van testcoverage ook), zonder dat er enige verbetering in de feitelijk uitgevoerde testen is.

Hier zie ik het 'provider' concept als een oorzaak: Iedere 'provider' zie ik als een aparte module. Die modules brengen ook allen hun eigen code mee. Daarbij zal er rond die providers de nodige controle code moeten worden toegevoegd om de beveiliging van die modules te controleren. En dat zowel in de modules/providers als in het raamwerk waar ze in worden gehangen.

Weet iemand waarom ze van versie 1 naar 3 gaan en dus 2 blijkbaar hebben overgeslagen?

Volgens wikipedia: The major version 2.0.0 was skipped due to its previous use in the OpenSSL FIPS module

Je bent me voor maar hier met de bron:

The current development version (master branch) will be identified as version 3.0.0. The OpenSSL FIPS module currently under development will also follow this versioning scheme. We are skipping the 2.0.0 major version because the previous OpenSSL FIPS module has already used this number.
https://www.openssl.org/blog/blog/2018/11/28/version/

Er is een OpenSSL FIPS Object Module die versie 2 had, als je de huidige 1.1 download, dan download je eigenlijk 2.0.3+1.1.0h.

Omdat 2 dus al in gebruik was en de nieuwe versie geen losse module heeft, hebben ze besloten om met 3 verder te gaan.

is de beschikbare documentatie volgens hem met 94 procent en de hoeveelheid coderegels met 54 procent toegenomen

Dat is leuk maar ipv meer documentatie zou betere documentatie geen slecht plan zijn.

Even een jaartje af laten koelen en als de bugs eruit zijn gebruiken maar.

Als niemand het gebruikt worden er ook geen bugs gevonden...

Prima, en voor thuisgebruik zal ik er geen problemen mee hebben, maar voordat ik het op werk ga voorstellen wil ik wel even zekerder zijn dat er geen beestjes meer in zitten. Of misschien beter: dat er een goeie reden is om over te stappen, zoals features die we echt nodig (gaan) hebben.

De standaard is er, nu kan/mag ze worden geïmplementeerd. Daarna kunnen wij ze gebruiken.

Zie bijvoorbeeld tls: Versie 1.3 is er al een tijdje maar microsoft biedt ze nu pas met windows server 2022.

En omdat het communicatie betreft moeten beide kanten het ondersteunen voordat het kan werken.

Pfff, 54 procent coderegels toename, toe maar, maar het lijkt me veel relevanter/nieuwswaardiger te vermelden wat de belangrijkste zaken zijn die onderwater aangepast zijn (naast de nieuwe Provider feature!)

Even snel door de changelog:
Belangrijk is dat een aantal algoritmen deprecated zijn verklaard, waaronder MD2 (eindelijk) en DES.

Ook zijn een aantal functies deprecated verklaard omdat ze de mogelijkheid hebben om de nieuwe provider implementatie te omzeilen (toch wel interessant hoe dat dan werkt).

[Reactie gewijzigd door thomasv op 8 september 2021 15:52]

Ik zou het een mooier resultaat vinden als er minder code regels waren. 54% dat is nogal wat voor een security related project. Dat moet allemaal gereviewd en onderhouden worden. Hoe minder code hoe beter (nou ja dat is natuurlijk niet helemaal waar, maar toch)

Ja maar de wereld van security algoritmes staat niet stil. Je kunt niet steeds meer ondersteunen met steeds minder code.

Desondanks is een groei van meer dan 50% wel heel erg onverwacht. Ongetwijfeld dat er binnenkort een Youtube video verschijnt die uitlegt waarom dat zo is.

Helemaal mee eens, wat er op zou duiden dat nog veel legacy in zit. En dat maakt het project complex en lastig te reviewen. Maar tja als stuurman aan de kant…

De meerderheid van applicaties die werkten ..
Het merendeel van de applicaties die werkten ..