Sió-Informatika Rendszerház

Az OpenSSL projekt kiadta a 4.1.0-s verziót. A legfontosabb újdonság a DTLS 1.3 támogatása, amely többek között UDP felett teszi lehetővé a titkosított kommunikációt. A kiadás a TLS bővíthetőségét segítő GREASE-mechanizmust is bevezeti, a bejövő kapcsolatokat fogadó SSL listener API pedig már DTLS-hez is használható. Emellett egyes kriptográfiai műveletek gyorsabbá váltak, és változott néhány fordítási beállítás, függőség és támogatott célplatform. Az OpenSSL 4.1.0 hivatalos kiadási jegyzéke

A fejlesztők négy ismert DTLS-problémát dokumentáltak. Ezek ott válhatnak láthatóvá, ahol egy laboratóriumi alappróba rendszerint véget ér: a kézfogás egy része elveszik, egy már létrejött kapcsolat átmenetileg nem írható, vagy kulcsfrissítés történik, miközben egy korábbi üzenetre még nem érkezett nyugta. A kiadási jegyzék ezeket működési és megbízhatósági hibaként ismerteti; nem sorolja őket a kritikusként besorolt sérülékenységek közé, és nem számol be aktív kihasználásukról.

Az átállási döntés másik szempontja a karbantartási idő. Az OpenSSL 4.1 olyan funkciókat kínál, amelyek a korábbi ágakban nem érhetők el, de rövidebb ideig kap nyilvános támogatást, mint a 3.5 LTS. Az OpenSSL támogatási és letöltési táblázata

Mit véd a DTLS 1.3, ha a hálózaton csomagok veszhetnek el?

A Datagram Transport Layer Security 1.3 a TLS 1.3 biztonsági megoldásaira épül, de olyan átviteli módokhoz készült, amelyek önálló adatcsomagokat, azaz datagramokat továbbítanak. UDP esetén egy csomag elveszhet, késve futhat be, vagy egy később elküldött csomag előtt érkezhet meg. A DTLS-nek ezekkel az esetekkel a kapcsolat felépítésekor és az azt követő protokollüzenetek feldolgozásakor is számolnia kell. IETF RFC 9147: DTLS 1.3

A protokoll a lehallgatás, a módosítás és az üzenethamisítás ellen nyújt védelmet, miközben megőrzi az átvitel datagramjellegét. Nem alakítja az UDP-t megbízható, sorrendtartó adatfolyammá. A sorrendre és a visszajátszás elleni védelemre vonatkozó tulajdonságai is eltérnek a TLS-étől. Ha tehát az alkalmazás működéséhez minden üzenetnek meg kell érkeznie, mégpedig meghatározott sorrendben, ezt az alkalmazás tervezésekor külön kell kezelni. A DTLS 1.3 szabvány biztonsági és átviteli garanciái

Egy hibátlan laborhálózaton sikeresen felépülő kapcsolat ezért csak az alapműködést igazolja. Az OpenSSL 4.1.0 esetében a csomagvesztés, a késleltetett nyugták, az újraküldések és az eltérő kliensmegvalósítások vizsgálatához a négy hibajegy konkrét teszthelyzeteket is ad.

Négy ismert DTLS-hiba: mi történik a kapcsolatban?

1. Kulcsfrissítéskor elmaradhat a még nem nyugtázott munkamenetjegyek újraküldése. A DTLS 1.3 a kezdeti kézfogás után is küld vezérlőüzeneteket. Ilyen a későbbi kapcsolódás folytatását segítő munkamenetjegy és a titkosítási kulcs frissítését jelző KeyUpdate. A két üzenet más célt szolgál: attól, hogy kulcsfrissítés érkezett, a másik fél még nem feltétlenül kapta meg a korábban küldött jegyeket.

A 4.1.0-ban egy KeyUpdate feldolgozásakor a még nyugtázatlan munkamenetjegyek kikerülhetnek az újraküldésre váró üzenetek közül, és az időzítőjük is leállhat. Ha egy jegy útközben elveszett, a rendszer így nem küldi újra. A hibajegy ezt olyan próbával szemlélteti, amelyben a jegyek anélkül törlődtek a várólistáról, hogy a hozzájuk tartozó nyugták beérkeztek volna. OpenSSL #32878

2. Végleges fogadási hibánál az alkalmazás tévesen újabb adatra várhat. A DTLS-kapcsolatokat fogadó listener végleges olvasási hiba után is visszaadhatja az SSL_ERROR_WANT_READ állapotot. Ez az alkalmazás számára normálisan azt jelenti, hogy később, újabb adat érkezésekor érdemes folytatni a műveletet. A hiba miatt azonban a program olyan állapotváltozásra várhat, amely már nem következhet be.

A hibajegy szerint az események lekérdezése és az újabb kapcsolatfogadási próbálkozás sem feltétlenül teszi egyértelművé, hogy a listener meghibásodott. Ilyenkor a várakozás helyett helyreállításra volna szükség. A reprodukció DTLS 1.2-vel is működött, ezért ezt az esetet azoknak is érdemes ellenőrizniük, akik az új listener API-t használják, de nem térnek át DTLS 1.3-ra. OpenSSL #33277

3. Átmeneti írási hiba miatt az alkalmazás lezárhat egy működő kapcsolatot. A listeneren keresztül elfogadott, nem blokkoló DTLS-kapcsolaton ennek éppen a fordítottja is előfordulhat. Ha az írás csak átmenetileg nem végezhető el, az alkalmazásnak SSL_ERROR_WANT_WRITE jelzést kellene kapnia, hogy később újrapróbálkozhasson. Ehelyett az OpenSSL SSL_ERROR_SYSCALL hibát adhat vissza, amelyet a hívó program végleges hibaként kezelhet.

A bemutatott próbában az írás sikerült, amikor a kliens kiolvasta a rá váró adatokat, és a kiszolgáló újból megkísérelte a műveletet. A másik API-útvonalon létrehozott hagyományos DTLS-kiszolgáló ugyanebben a helyzetben a várt újrapróbálkozási jelzést adta. A hiba tehát a lis­teneren elfogadott kapcsolat kezeléséhez kötődik, és szintén nem kizárólag DTLS 1.3-at érint. OpenSSL #33278

4. Egy szabályos nyugta is megszakíthatja a DTLS 1.3 kézfogását. Ha a szerver kezdeti kézfogási üzeneteinek csak egy része érkezik meg, a kliens nyugtázhatja azokat a rekordokat, amelyeket valóban megkapott. A hibajegy szerint az OpenSSL 4.1.0 szervere egy ilyen nyugtára unexpected_message riasztással válaszolhat, majd megszakíthatja a kapcsolat felépítését.

A kizárólag OpenSSL-klienst és OpenSSL-szervert összekapcsoló teszt nem feltétlenül hozza elő ezt a hibát, mert az OpenSSL kliensoldala másként kezeli az érintett szerverüzenetek nyugtázását. A hasznos próba ebben az esetben másik DTLS-megvalósítással működő kliens és részleges csomagvesztés együttes vizsgálata. OpenSSL #33242

GREASE: kiderülhet, ha egy eszköz hibásan kezeli az ismeretlen értékeket

A TLS-ben a kapcsolódó felek többféle képességet hirdethetnek meg, amelyek közül a másik fél kiválaszthatja a támogatottakat. A protokoll bővíthetőségéhez egyes mezőkben az ismeretlen értékeket figyelmen kívül kell hagyni. Ha egy régebbi kliens, szerver vagy köztes hálózati eszköz minden ismeretlen érték láttán megszakítja a kapcsolatot, egy későbbi, szabályos bővítés bevezetése is hibát okozhat.

A GREASE (Generate Random Extensions And Sustain Extensibility) erre ad próbát: az erre kijelölt bővítési pontokon szándékosan fenntartott értékeket hirdet meg. A másik félnek úgy kell folytatnia az egyeztetést, hogy ezeket nem választja ki. Így már azelőtt láthatóvá válhat egy kompatibilitási hiba, hogy egy valódi új képesség bevezetése függne a helyes működéstől. Különösen régi végpontokkal vagy a TLS-forgalmat vizsgáló hálózati eszközökkel érdemes ezt kipróbálni. IETF RFC 8701: GREASE

Gyorsabb kriptográfiai műveletek és változó fordítási beállítások

A 4.1.0 bizonyos műveleteket gyorsít a posztkvantum kriptográfiában használt ML-DSA digitális aláírásnál és az ML-KEM kulcslétesítésnél. A ppc64le architektúrán mindkét algoritmus számításainak egy része optimalizált megvalósítást kapott. x86_64 alatt az ML-DSA műveletei is gyorsultak; az AVX-512 utasításokat támogató processzorokon párhuzamosított SHAKE-műveletek segítik a feldolgozást. Az AES-CBC visszafejtéséhez ugyanezen az architektúrán AVX-512- és VAES-gyorsítás került a könyvtárba. Az OpenSSL 4.1.0 műszaki változásai

A kiadás támogatja az IKEv2 kulcsszármaztató függvényét, és megjelent az Elbrus2000 (e2k) architektúra kezdeti támogatása is. A saját OpenSSL-csomagot készítő csapatoknál emellett négy változás igényel figyelmet:

• Az új VC-WIN32-MSVC2013 és VC-WIN64A-MSVC2013 fordítási célok az MSVC 2013 hiányos C99-támogatását hidalják át.
• Kikerült a Windows-on-Itanium (VC-WIN64I) és a Windows CE (VC-CE) fordítási cél.
• Megszűntek a no-ecdsa és no-ecdh konfigurációs kapcsolók. A projekt szerint ezek korábban sem tiltották le ténylegesen a megvalósításokat. Az általános elliptikusgörbe-támogatás kikapcsolására a no-ec szolgál; ez szélesebb körű döntés, mint egyetlen aláírási vagy kulcscsere-eljárás mellőzése.
• A tsget segédprogram a már nem karbantartott WWW::Curl::Easy helyett a Net::Curl::Easy Perl-modult használja. Ahol a tsget része a munkafolyamatnak, az új függőséget a frissítés előtt telepíteni kell. A projekt kompatibilitási megjegyzései

A fordítás és a teljesítmény külön ellenőrzést kíván. Az előbbinél az számít, hogy a meglévő automatizálás a kívánt algoritmusokkal és függőségekkel állítja-e elő a csomagot. Az utóbbinál a valós terhelés a mérvadó: egy aláírási részművelet gyorsulása nem feltétlenül eredményez ugyanekkora javulást egy olyan szolgáltatásban, amely idejének nagy részét hálózati várakozással tölti.

Meddig támogatott az OpenSSL 4.1?

A projekt által megadott nyilvános támogatási határidők eltérő frissítési lehetőségeket jelentenek. A 2026. november 4-i állapot szerint a cikkben érintett ágak helyzete a következő. Az OpenSSL letöltési és támogatási táblázata · Az OpenSSL kiadási szabályzata

Ezek az OpenSSL projekt saját határidői. Ha a könyvtárat operációs rendszerrel vagy más gyártó termékével együtt szállítják, a telepített csomaghoz tartozó támogatást és a biztonsági javítások forrását az adott szállítónál is ellenőrizni kell.

Ahol a DTLS 1.3 indokolja a váltást, ott az átvételi próbák között legyen elveszett kézfogási üzenet, részleges nyugta és kulcsfrissítés is. Ahol a listener API a változás oka, ott azt kell igazolni, hogy az alkalmazás átmeneti hibánál újrapróbálkozik, végleges hibánál pedig helyreállítja a kiszolgálást. Ahol elsősorban hosszú karbantartási idő szükséges, a 3.5 LTS 2030-ig tartó támogatása lehet a döntő szempont. A megfelelő ág kiválasztását így az alkalmazás tényleges protokolligénye, hibakezelése és vállalt üzemideje határozza meg.

Eredeti cím: OpenSSL 4.1.0 Adds DTLS 1.3 and Cryptographic Optimisations