OpenSSL 4.1.0: DTLS 1.3 Hadir, Disertai Empat Bug yang Perlu Diwaspadai

OpenSSL 4.1.0 adalah rilis fitur yang akhirnya menghadirkan DTLS 1.3 ke pustaka kriptografi OpenSSL. Rilis ini juga datang dengan peringatan. Proyek OpenSSL menerbitkan versi 4.1.0 pada 23 Oktober 2026. Rilis ini menambah Datagram Transport Layer Security versi 1.3, kriptografi pascakuantum yang lebih cepat, dan sejumlah perubahan build yang bisa merusak penyiapan lama (catatan rilis OpenSSL 4.1.0, proyek OpenSSL, diakses 27 Oktober 2026). Rilis ini bukan tambalan keamanan. Ini rilis fitur. Catatan rilisnya sendiri mencantumkan empat bug DTLS yang sudah diketahui. Tim perlu membacanya sebelum meningkatkan versi pada sistem produksi (Help Net Security, 26 Oktober 2026). Ringkasnya: pakai DTLS 1.3 untuk pekerjaan baru, uji empat kasus tepi yang didokumentasikan, dan periksa flag build sebelum peluncuran.

Poin Penting

• OpenSSL 4.1.0 diterbitkan pada 23 Oktober 2026 sebagai rilis fitur, bukan tambalan keamanan tersendiri. Rilis ini didahului alfa pada awal September dan dua build beta.

• Fitur utamanya adalah DTLS 1.3, yang ditetapkan dalam RFC 9147. DTLS 1.3 membawa keamanan setara TLS 1.3 ke transpor datagram seperti UDP.

• Catatan rilis mendokumentasikan empat bug DTLS yang sudah diketahui. Dua di antaranya bisa membuat aplikasi salah membaca keadaan koneksi.

• Algoritme pascakuantum ML-KEM dan ML-DSA mendapat operasi number theoretic transform yang dioptimalkan. Dekripsi AES-CBC pada x86_64 mendapat percepatan AVX-512 dan VAES.

• Perubahan build juga penting: opsi no-ecdsa dan no-ecdh dihapus, target Windows-on-Itanium dan Windows CE dihapus, dan tsget kini butuh modul Perl Net::Curl::Easy.

Jika Anda menjalankan apa pun yang melayani lalu lintas internet, OpenSSL kemungkinan ada di suatu tempat pada tumpukan Anda. OpenSSL dipakai server web, VPN, server surel, dan banyak alat baris perintah, meski Anda tidak pernah menyentuhnya langsung. Karena itu, rilis fitur pada pustaka ini penting, lebih dari sekadar daftar perubahannya. Rilis ini menentukan cara lalu lintas UDP terenkripsi generasi berikutnya dibangun. Karena itu pula catatan rilis kali ini layak dibaca cermat. Empat bug yang didokumentasikan pada kode DTLS baru bukan alasan panik. Namun, empat bug itu alasan untuk menguji sebelum peluncuran.

Apa Itu OpenSSL?

OpenSSL adalah pustaka kriptografi sumber terbuka dan perangkatnya. Pustaka ini menerapkan protokol TLS dan DTLS, beserta algoritme kriptografi dan penanganan sertifikat yang jadi sandaran koneksi aman. Pengembang menautkan aplikasi mereka ke pustaka ini, alih-alih menulis kode enkripsi sendiri. Bagian inilah yang paling mahal jika salah. Proyek OpenSSL memelihara pustaka ini, dan kode sumbernya diterbitkan terbuka, sehingga siapa pun bisa membaca, mengaudit, dan membangunnya.

Nomor versi OpenSSL punya arti. Rilis fitur seperti 4.1.0 menambah kemampuan baru di atas lini utama saat ini. Rilis tambalan memperbaiki bug tanpa mengubah fitur. Liputan rilis ini sepakat soal itu: 4.1.0 adalah rilis fitur, bukan tambalan keamanan tersendiri (Cyber Security News, 26 Oktober 2026). Tim yang hanya butuh perbaikan bisa bertahan pada versi saat ini. Tim yang menginginkan DTLS 1.3 atau kinerja pascakuantum punya alasan untuk pindah.

Apa Itu DTLS 1.3, dan Mengapa Penting?

DTLS (Datagram Transport Layer Security) adalah varian TLS untuk transpor datagram seperti UDP. Pada UDP, paket bisa tiba tak berurutan, ganda, atau hilang sama sekali. TLS mengasumsikan aliran yang andal dan berurutan, seperti yang disediakan TCP. DTLS mempertahankan enkripsi dan autentikasi TLS, sambil mentoleransi kekacauan UDP. Karena itu, DTLS cocok untuk komunikasi waktu nyata, gim daring, panggilan video, VPN, dan perangkat Internet of Things. Di semua itu, menunggu transmisi ulang lebih merugikan daripada kehilangan satu paket. For example, aplikasi panggilan video memakai DTLS untuk mengenkripsi aliran media, tanpa menunggu paket yang hilang.

DTLS 1.3, yang ditetapkan dalam RFC 9147, membawa DTLS ke tolok ukur keamanan TLS 1.3. Dibanding DTLS versi lama, DTLS 1.3 menawarkan keamanan lebih kuat, handshake lebih cepat, forward secrecy, dukungan bawaan untuk kriptografi pascakuantum, dan format header yang lebih ringkas, menurut liputan rilis ini (PBX Science, 24 Oktober 2026). Forward secrecy berarti sesi lama tetap tak terbaca meski kunci jangka panjang bocor. Sebab, tiap sesi memakai kunci sementara sendiri. Bagi aplikasi yang sudah berjalan lewat UDP, DTLS 1.3 adalah jalur peningkatan ke enkripsi modern tanpa mengorbankan latensi rendah.

OpenSSL 4.1.0 juga menambah dukungan DTLS ke API listener SSL. API inilah yang dipakai program server untuk menerima koneksi masuk. Rilis ini menyertakan panduan DTLS 1.3 sebagai halaman manual ossl-guide-dtlsv13. Jadi, pengembang yang memakai protokol baru ini punya dokumentasi resmi, bukan hanya daftar perubahan. Kombinasi ini, versi protokol baru, dukungan listener, dan panduan, yang mengubah fitur pustaka menjadi sesuatu yang bisa benar-benar dibangun pengembang aplikasi.

Empat Bug DTLS yang Diketahui, Dijelaskan Sederhana

Bagian paling berguna dari rilis ini mungkin kejujurannya. Proyek ini mendokumentasikan empat bug DTLS pada kode yang dikirimkan. Liputan independen menjelaskan tiap bug (Help Net Security, 26 Oktober 2026). Tak satu pun bug ini alasan untuk menghindari rilis ini sama sekali. Keempatnya alasan untuk menguji jalur tertentu yang terdampak, sebelum DTLS 1.3 dipakai di produksi.

• Koneksi mati bisa tampak masih menunggu. Kegagalan terima permanen pada listener DTLS bisa muncul sebagai SSL_ERROR_WANT_READ. Kode ini menyuruh program menunggu data lagi.

• Koneksi yang berjalan bisa tampak rusak. Kegagalan tulis yang bisa diulang pada koneksi nonblokir bisa muncul sebagai SSL_ERROR_SYSCALL. Aplikasi yang menganggap kode ini fatal bisa menutup koneksi yang masih berjalan.

• Handshake bisa gagal setelah paket hilang. Server DTLS 1.3 bisa membatalkan handshake dengan peringatan unexpected_message. Ini terjadi saat klien mengakui penerbangan pertama server lebih awal.

• Tiket sesi bisa hilang. Saat OpenSSL menerima pesan KeyUpdate, OpenSSL membuang rekaman pasca-handshake lain yang tertunda. Jika NewSessionTicket hilang pada pengiriman pertama, OpenSSL takkan mengirimnya lagi.

Proyek ini sedang menyiapkan perbaikan untuk bug KeyUpdate. Untuk tiga bug lain, tak ada status perbaikan yang dicantumkan, menurut pembacaan Help Net Security atas catatan rilis. Saran praktis dari liputan itu tegas: kode yang menerima koneksi dari listener DTLS jangan menerima SSL_ERROR_WANT_READ atau SSL_ERROR_SYSCALL begitu saja, sampai OpenSSL memperbaiki dua bug itu. Jika aplikasi Anda sudah menangani kedua kode itu secara defensif, risikonya lebih rendah. Jika aplikasi Anda menganggapnya sebagai vonis akhir, tambahkan jalan keluar dulu.

Matematika Pascakuantum yang Lebih Cepat, dan Ekosistem TLS yang Lebih Tangguh

Kriptografi pascakuantum adalah kriptografi yang dirancang tetap aman terhadap penyerang dengan komputer kuantum yang berfungsi. Dua algoritme standarnya muncul pada rilis ini: ML-KEM, mekanisme enkapsulasi kunci untuk menyepakati rahasia bersama, dan ML-DSA, algoritme tanda tangan digital. OpenSSL 4.1.0 mengoptimalkan operasi number theoretic transform keduanya pada sistem ppc64le, menambah operasi ML-DSA yang dioptimalkan pada x86_64, dan menambah pemrosesan SHAKE AVX-512 untuk ML-DSA. Dekripsi AES-CBC pada x86_64 juga mendapat optimalisasi AVX-512 dan VAES.

Satu catatan jujur: catatan rilis tak menyertakan angka tolok ukur untuk optimalisasi ini. Jadi, belum ada yang bisa bilang seberapa cepat beban kerja nyata berjalan. Anggap kinerja ini sebagai rekayasa yang menjanjikan, bukan percepatan yang terukur, sampai tolok ukur independen muncul. Arahnya tetap jelas. Algoritme pascakuantum lebih berat daripada algoritme klasik yang kelak digantikannya. Jadi, tiap optimalisasi pada pustaka membantu adopsi.

GREASE (Generate Random Extensions And Sustain Extensibility) adalah mekanisme, yang ditetapkan dalam RFC 8701, yang mengirim nilai acak yang dicadangkan selama handshake TLS. Tujuannya membongkar server yang salah menangani nilai yang tak dikenalinya. Jika server tersendat pada nilai tak dikenal hari ini, server itu akan rusak saat ekstensi nyata memakai nilai itu esok. GREASE membongkar kerapuhan itu lebih awal, sehingga ekosistem TLS tetap bisa diperluas. OpenSSL 4.1.0 menambah dukungan GREASE, beserta fungsi derivasi kunci IKEv2 dan dukungan awal untuk arsitektur prosesor Elbrus2000.

Perubahan Build yang Bisa Merusak Penyiapan Anda

Rilis fitur kadang merusak build secara diam-diam. Versi 4.1.0 punya tiga perubahan yang layak diperiksa sebelum Anda meningkatkan jalur build. Pertama, opsi Configure no-ecdsa dan no-ecdh dihapus. Sebab, kedua opsi itu ternyata tak benar-benar menonaktifkan implementasi yang dinamainya. Build yang dikonfigurasi dengan salah satu flag itu tetap membawa kode yang seharusnya ditinggalkan. Proyek ini mengarahkan pengguna ke no-ec, yang menonaktifkan dukungan kurva eliptik sepenuhnya (Help Net Security, 26 Oktober 2026). Jika skrip build Anda memakai flag itu, perbarui skripnya, atau build Anda akan gagal.

Kedua, target build Windows-on-Itanium dan Windows CE dihapus. Target build baru ditambahkan untuk menjembatani kekurangan dukungan C99 pada MSVC 2013. Kebanyakan tim takkan menyadarinya. Namun, siapa pun yang masih menargetkan platform itu butuh rencana. Ketiga, utilitas penanda waktu tsget kini butuh modul Perl Net::Curl::Easy, menggantikan WWW::Curl::Easy yang sudah ditinggalkan. Siapa pun yang mengandalkan tsget harus memasang modul baru itu sebelum meningkatkan versi, atau alat itu berhenti bekerja.

Apa Kata Liputan Independen

Liputan independen soal 4.1.0 luar biasa konsisten. Liputan itu sepakat dengan proyek itu sendiri: ini rilis fitur yang solid dengan sisi kasar yang didokumentasikan, bukan darurat keamanan yang wajib dipasang. Liputan Help Net Security berpusat pada empat bug DTLS dan penghapusan flag build. Liputan itu berakhir dengan saran yang sama seperti tersirat pada catatan rilis: baca catatan rilis, lalu uji. Liputan PBX Science menekankan riwayat rilis: alfa pada awal September dan dua build beta pada September dan Oktober, sebelum penandaan final pada 23 Oktober 2026. Itu irama yang normal dan hati-hati untuk pustaka yang dipakai seluas ini.

Konteks itu penting. Sebab, OpenSSL ada pada infrastruktur kritis, sehingga administrator wajar bersikap hati-hati pada tiap rilisnya. Namun, 4.1.0 adalah jenis rilis yang berbeda dari tambalan keamanan. Risikonya didokumentasikan, spesifik, dan bisa diuji. Itulah yang Anda inginkan dari rilis fitur pada pustaka yang dipakai luas.

Metodologi artikel ini sederhana. Kami membandingkan catatan rilis resmi dengan liputan Help Net Security (26 Oktober 2026) dan PBX Science. Kami lalu memeriksa empat bug yang diketahui dengan daftar bug proyek itu sendiri. Pada daftar itu, bug KeyUpdate tercatat dengan perbaikan yang sedang disiapkan. Jika liputan dan catatan rilis berbeda penekanan, kami mengikuti catatan rilis. Karena itu, empat bug di atas dijelaskan dengan istilah proyek itu sendiri. Karena itu pula klaim kinerja disertai catatan soal tidak adanya angka tolok ukur.

Contoh konkret menunjukkan mengapa urutan itu penting. For example, tim kecil yang menjalankan layanan suara lewat UDP meningkatkan versi di produksi dulu. Galat listener bisa membuat penelepon menggantung pada koneksi mati, dan tim itu akan menyalahkan jaringan. Jika tim itu meningkatkan versi di staging dulu, tim itu bisa mensimulasikan paket hilang, memaksa KeyUpdate, dan mengamati apa yang sebenarnya dilakukan penanganan galatnya. Empat bug yang sama, jika ditemukan di staging, menjadi daftar periksa. Jika ditemukan di produksi, empat bug itu menjadi gangguan layanan.

Siapa yang Harus Meningkatkan Versi, dan Siapa yang Harus Menunggu

Tingkatkan versi segera jika Anda membangun produk yang berbicara lewat UDP dan butuh enkripsi modern: VPN, produk video atau suara, gim dengan permainan berjaringan, atau armada IoT. DTLS 1.3 adalah standar saat ini untuk lalu lintas itu. OpenSSL 4.1.0 adalah cara langsung untuk mendapatkannya. Tingkatkan dulu di staging. Uji empat jalur yang didokumentasikan: penanganan galat listener, tulis nonblokir, handshake saat paket hilang, dan kelanjutan sesi setelah KeyUpdate. Jalankan uji staging itu di dalam kontainer sekali pakai, supaya build yang buruk tak bisa menyentuh lingkungan asli Anda. Jika kontainer masih baru bagi Anda, penjelasan Docker kami membahas apa itu kontainer dan mengapa pengembang memakainya.

Tunggu, atau tingkatkan hanya di staging, jika aplikasi Anda menganggap SSL_ERROR_WANT_READ atau SSL_ERROR_SYSCALL sebagai vonis akhir, jika build Anda memakai no-ecdsa atau no-ecdh, atau jika Anda bergantung pada tsget tanpa Net::Curl::Easy terpasang. Tak satu pun hal itu penghalang permanen. Tiap hal itu perbaikan kecil. Namun, tiap hal itu akan menggigit jika Anda menemukannya di produksi. Jika Anda hanya butuh perbaikan keamanan, bertahanlah pada versi didukung Anda saat ini, sampai rilis tambalan, atau rilis 4.1.x berikutnya, menangani empat bug yang diketahui itu.

Bagi tim yang memelihara perkakas keamanan lain, kalkulasi peningkatan ini terasa familier. Penjelasan PHP2Shell kami membahas kasus berbeda, dua celah PHP kritis, ketika menambal secepatnya adalah satu-satunya saran yang waras. OpenSSL 4.1.0 adalah kasus sebaliknya: rilis fitur ketika langkah yang tepat adalah menguji dulu, sebab proyek ini sudah memberi tahu Anda persis ke mana harus melihat.

Pertanyaan yang Sering Diajukan

Apakah OpenSSL 4.1.0 pembaruan keamanan yang harus segera dipasang? Tidak. OpenSSL 4.1.0 adalah rilis fitur, bukan tambalan keamanan tersendiri. Rilis ini menambah DTLS 1.3, GREASE, kinerja pascakuantum, dan perubahan build, serta mendokumentasikan empat bug DTLS yang diketahui. Pasanglah sesuai jadwal Anda, setelah pengujian, bukan sebagai tambalan darurat.

Apa itu DTLS 1.3? DTLS 1.3, yang ditetapkan dalam RFC 9147, adalah versi terbaru Datagram Transport Layer Security. DTLS 1.3 membawa enkripsi dan autentikasi setara TLS 1.3 ke transpor datagram seperti UDP, ketika paket bisa tiba tak berurutan atau hilang. DTLS 1.3 cocok untuk komunikasi waktu nyata, gim, panggilan video, VPN, dan perangkat IoT.

Apa empat bug yang diketahui pada OpenSSL 4.1.0? Pertama, kegagalan terima permanen pada listener bisa muncul sebagai SSL_ERROR_WANT_READ. Kedua, kegagalan tulis yang bisa diulang bisa muncul sebagai SSL_ERROR_SYSCALL. Ketiga, handshake bisa batal setelah paket hilang. Keempat, KeyUpdate bisa membuang rekaman pasca-handshake yang tertunda sehingga tiket sesi yang hilang tak pernah dikirim ulang. Perbaikan untuk bug KeyUpdate sedang disiapkan.

Apakah OpenSSL 4.1.0 merusak build yang sudah ada? Bisa, dalam tiga cara spesifik. Opsi Configure no-ecdsa dan no-ecdh dihapus, pakai no-ec sebagai gantinya. Target build Windows-on-Itanium dan Windows CE dihapus. Dan tsget kini butuh modul Perl Net::Curl::Easy, bukan WWW::Curl::Easy yang sudah ditinggalkan.

Haruskah saya memakai DTLS 1.3 untuk produk baru? Ya, jika produk Anda berjalan lewat UDP dan butuh enkripsi. DTLS 1.3 adalah standar saat ini, dengan forward secrecy dan dukungan pascakuantum bawaan. Bangunlah dengan OpenSSL 4.1.0, ikuti halaman manual ossl-guide-dtlsv13, dan uji empat kasus tepi yang didokumentasikan di staging sebelum produksi.

Kesimpulan

Singkatnya, OpenSSL 4.1.0 adalah rilis yang membawa pustaka kriptografi internet ini up to date untuk lalu lintas UDP. Rilis ini juga jujur soal sisi kasarnya sendiri. DTLS 1.3, GREASE, dan matematika pascakuantum yang lebih cepat adalah kemajuan nyata. Empat bug DTLS yang didokumentasikan dan tiga perubahan build adalah pekerjaan rumah yang nyata. Kerjakan pekerjaan rumah itu di staging, dan kemajuan itu jadi milik Anda. Mulailah dari catatan rilis OpenSSL 4.1.0 dan liputan independen Help Net Security, atau baca versi bahasa Inggris artikel ini.