Tim Hudson, Presiden OpenSSL Corporation – Seri Wawancara

Tim Hudson adalah co‑author SSLeay dan salah satu penyelenggara OpenSSL Conference, Praha 13‑15 Oktober 2026. Ia memiliki lebih dari 30 tahun pengalaman dalam keamanan sistem dan jaringan serta menjabat sebagai Presiden OpenSSL Corporation dan Chief Technology Officer di Cryptsoft Pty Ltd. Sejak 1995, pekerjaannya meliputi co‑founding SSLeay bersama Eric Young, perpustakaan kriptografi yang menjadi OpenSSL Library, co‑founding pusat pengembangan RSA Security Australia, berkontribusi pada perubahan regulasi ekspor enkripsi AS, memimpin lebih dari 30 validasi FIPS 140, co‑chairing Komite Teknis OASIS KMIP dan SAM, serta menjadi pembicara di konferensi keamanan terkemuka, termasuk RSA Conference, AusCERT, ICMC, LinuxConf, dan OpenSSL Conference.

OpenSSL adalah proyek sumber terbuka kolaboratif global yang mengembangkan dan memelihara OpenSSL Library, salah satu perpustakaan kriptografi paling banyak digunakan di dunia. Digunakan di seluruh sistem operasi, platform cloud, perangkat lunak perusahaan, dan perangkat terhubung, OpenSSL Library membantu melindungi miliaran interaksi online yang aman setiap hari. Melalui OpenSSL Foundation dan OpenSSL Corporation, proyek ini berkomitmen untuk memajukan kriptografi yang dapat dipercaya, mendukung pengembangan sumber terbuka yang berkelanjutan, dan memperkuat keamanan internet.

Anda co‑found SSLeay bersama Eric Young pada 1995 setelah menyadari kebutuhan akan implementasi SSL non‑AS, dan pekerjaan itu pada akhirnya menjadi dasar OpenSSL. Masalah apa yang awalnya Anda coba selesaikan, dan apakah pada saat itu Anda sudah menyadari bahwa teknologi tersebut dapat menjadi bagian fundamental dalam mengamankan internet?

Masalahnya sepenuhnya konkret, dan pada awalnya merupakan masalah komersial sebelum menjadi apa pun. Saya bekerja di Mincom di Brisbane, dan kami memiliki pelanggan yang membutuhkan pengamanan komunikasi mereka. Tidak ada cara untuk membeli kemampuan tersebut. Kontrol ekspor AS atas kriptografi berarti produk Amerika tidak dapat disuplai kepada kami sama sekali atau datang dengan ukuran kunci yang sangat terbatas sehingga penggunaannya akan tidak jujur. Ini bukan keberatan filosofis terhadap kebijakan ekspor. Ini adalah masalah rekayasa di mana komponen yang saya butuhkan tidak ada dalam bentuk yang dapat saya beli, dan saya memiliki pelanggan yang menunggu.

Saya memiliki pengetahuan tentang sesuatu yang kebanyakan orang telah melupakan. Eric Young beberapa tahun sebelumnya telah menulis implementasi DES: kode yang baik, bersih, tersedia secara bebas, ditulis demi kepuasan pribadi dan sama sekali tidak terkait dengan hal ini. Eric tidak sedang mengerjakan SSL. Ia tidak mengetahui SSL. Ketika Netscape menerbitkan spesifikasinya, saya membacanya, pergi ke Eric dengan masalah tersebut, dan menyajikannya sebagai langkah yang relatif sederhana dari apa yang sudah ia kerjakan.

Itu bukan gambaran keseluruhan. Setiap bagian tampak sederhana tetapi ada sejumlah bagian yang signifikan. Implementasi DES memberi Anda satu cipher simetris. SSL memerlukan kriptografi kunci publik, aritmetika presisi tak terbatas, ASN.1, penanganan sertifikat X.509, dan mesin status protokol, semuanya harus benar, karena dalam kriptografi hampir benar dan rusak adalah hal yang sama. Saya memperkirakan skala pekerjaan secara optimis. Eric segera menyadari betapa banyaknya pekerjaan itu, dan ia menikmatinya, karena skala ternyata menjadi daya tarik bukan penghalang. Saya tidak yakin proyek ini akan dimulai dengan cara lain.

Dia mengerjakan inti kriptografi, itulah mengapa perpustakaan tersebut membawa inisialnya. Saya menangani bagian yang mengubah perpustakaan menjadi sesuatu yang dapat dipasang orang lain: integrasi aplikasi, pengujian, dokumentasi, dan sisi komunitas. Saya juga secara aktif mencari setiap perpustakaan enkripsi pesaing yang digunakan dan mengonversi atau menggantinya. SSLtelnet, SSLftp, NCSA httpd, dan banyak paket lain adalah hasil kerja saya, aplikasi yang dibangun di atas algoritma dan protokol kriptografi yang diimplementasikan Eric. Kombinasi itu memungkinkan kami masing‑masing fokus pada hal yang benar‑benar menarik bagi kami, yang saya rasa menjadi alasan utama proyek ini terus berlanjut.

Berada di Australia memungkinkan hal ini terwujud, dan kemudian ternyata banyak orang lain memiliki masalah yang sama karena alasan yang sama. Sesuatu yang dibangun untuk memenuhi kebutuhan spesifik pelanggan di Brisbane menjadi berguna bagi semua orang di luar Amerika Serikat, dan akhirnya juga bagi banyak orang di dalamnya.

Apakah kami tahu apa yang akan menjadi? Tidak. Tidak ada yang berniat membangun infrastruktur kritis. Infrastruktur kritis adalah apa yang Anda sadari telah Anda bangun, beberapa tahun kemudian, ketika Anda mengetahui siapa yang bergantung padanya. Apa yang kami pikirkan adalah menyelesaikan masalah yang ada di depan kami dan kemudian menjawab pertanyaan dari orang lain yang menemui kendala yang sama. Bagian menjawab pertanyaan ternyata sama pentingnya dengan kode.

Anda telah bekerja di bidang kriptografi dan keamanan internet selama lebih dari tiga dekade. Apa yang berubah paling dramatis dalam lanskap ancaman selama periode tersebut, dan masalah keamanan apa yang tetap mengejutkan serupa meskipun ada kemajuan teknologi yang luar biasa?

Perubahan terbesar adalah bahwa menyerang sistem telah menjadi profesi dengan model ekonomi di belakangnya. Pada pertengahan 1990‑an, orang‑orang yang membobol sistem kebanyakan melakukannya karena menarik. Saat ini ada industri, dengan spesialisasi, alat, rantai pasokan, dukungan pelanggan, dan dalam beberapa kasus pendanaan negara. Itu mengubah segala hal tentang cara berpikir, karena Anda tidak lagi melawan rasa ingin tahu. Anda melawan seseorang dengan anggaran, tenggat waktu, dan kasus bisnis.

Perubahan kedua adalah skala dan ketergantungan. Aplikasi rata‑rata pada 1995 adalah sesuatu yang Anda tulis. Aplikasi rata‑rata saat ini adalah sesuatu yang Anda rakit, dan mayoritas kode di dalamnya ditulis oleh orang‑orang yang belum pernah Anda temui dan tidak dapat Anda sebutkan namanya. Permukaan serangan berpindah dari kode Anda ke ketergantungan Anda, dan kebanyakan organisasi belum menyesuaikan pola pikir mereka.

Apa yang tetap luar biasa konstan adalah mode kegagalan. Kami masih menulis bug dalam kode yang mem‑parse input tidak terpercaya. Kami masih merilis sistem dengan pengaturan default yang tidak pernah ditinjau ulang. Sertifikat masih kedaluwarsa pada hari Sabtu. Kredensial masih berakhir di tempat yang tidak seharusnya. Dan kriptografi hampir tidak pernah rusak pada tingkat matematika. Ia dilewati, salah konfigurasi, atau hanya tidak diaktifkan. Jika Anda memberi saya daftar sepuluh penyebab utama pelanggaran pada 1996 dan daftar dari bulan lalu, Anda akan sulit membedakannya. Teknologi berubah total. Kesalahan tidak.

OpenSSL 4.0 dirilis pada April 2026, menandai rilis utama pertama proyek dalam beberapa tahun. Apa yang dapat kita pelajari dari rilis ini tentang arah infrastruktur kriptografi, dan perubahan apa yang Anda rasa akan paling penting bagi organisasi yang bergantung pada OpenSSL?

Hal paling berguna untuk dipahami tentang 4.0 adalah bahwa ia pada dasarnya merupakan rilis pengurangan, dan itulah tujuan utamanya.

Kami menghapus antarmuka ENGINE sepenuhnya. Kami menghapus SSLv3 dan SSLv2 ClientHello. Kami menonaktifkan kurva eliptik yang sudah usang dan kurva EC eksplisit pada saat kompilasi. Kami menjadikan ASN1_STRING opak dan memperketat banyak tanda tangan API. Itulah perubahan yang menimbulkan pekerjaan bagi orang, dan itulah perubahan yang penting, karena perpustakaan kriptografi yang hanya menumpuk tidak dapat tetap aman. Setiap jalur kode yang sudah usang yang Anda pertahankan menjadi permukaan serangan yang dipelihara oleh orang lain dan tidak ada yang mengujinya.

Ada penambahan: Encrypted Client Hello, dukungan RFC 8998 termasuk grup hibrida SM2/ML‑KEM, cSHAKE, SNMP dan SRTP KDF, negosiasi FFDHE untuk TLS 1.2. ECH khususnya menutup celah privasi nyata, karena Server Name Indication telah membocorkan identitas setiap situs yang Anda kunjungi sejak TLS 1.3 diluncurkan. Namun penghapusanlah ceritanya.

Poin yang paling ingin saya sampaikan kepada organisasi adalah ini: 4.0 bukan rilis LTS. Ia didukung hingga Mei 2027. Rilis stabil jangka panjang saat ini adalah 3.5, didukung hingga April 2030, dan 3.5 sudah menyertakan algoritma pasca‑kuantum. Jika Anda menginginkan kode terbaru, gunakan 4.0. Jika Anda menginginkan target stabil yang dapat Anda rencanakan migrasi lima tahun, gunakan 3.5. Memilih nomor yang lebih tinggi hanya karena lebih tinggi adalah kesalahan yang kami lihat orang lakukan setiap siklus.

Kriptografi pasca‑kuantum telah beralih dari masalah riset menjadi tantangan migrasi, dengan OpenSSL sudah mendukung ML‑KEM, ML‑DSA, dan SLH‑DSA serta pertukaran kunci hibrida pasca‑kuantum. Bagi pemimpin bisnis yang menganggap komputasi kuantum masih terlalu jauh untuk dikhawatirkan, risiko apa yang mereka abaikan saat ini?

Kesalahan paling umum adalah memperlakukan ini sebagai pertanyaan tentang kapan komputer kuantum yang relevan secara kriptografi akan muncul. Itu variabel yang salah. Pertanyaan yang tepat adalah berapa lama data Anda perlu tetap rahasia, dan berapa lama migrasi Anda akan memakan waktu. Kurangi yang kedua dari yang pertama dan Anda mendapatkan tenggat waktu sebenarnya, dan bagi banyak organisasi tenggat waktu itu sudah lewat.

Traffic terenkripsi dapat ditangkap hari ini dan disimpan tanpa batas. Jika informasi di dalamnya memiliki horizon sensitivitas dua puluh tahun (rekam medis, berkas personel, kekayaan intelektual, materi diplomatik, posisi keuangan), maka penyerang tidak memerlukan komputer kuantum sekarang. Mereka hanya memerlukan satu kelak, dan penyimpanan murah sementara itu. Itu bukan serangan spekulatif; itu keputusan penyimpanan.

Hal kedua yang diabaikan adalah bahwa migrasi bukan satu proyek. Pertukaran kunci adalah bagian mudah, dan banyak sudah terjadi: OpenSSL 3.5 menjadikan pertukaran kunci hibrida pasca‑kuantum sebagai default TLS, sehingga banyak organisasi sudah menjalankan kesepakatan kunci pasca‑kuantum tanpa membuat keputusan tentangnya. Tanda tangan dan hierarki sertifikat adalah bagian sulit, karena melibatkan otoritas sertifikat, akar kepercayaan perangkat keras, kunci penandatangan firmware, modul keamanan perangkat keras, dan perangkat dengan masa pakai lapangan lima belas tahun yang dibangun dengan asumsi RSA akan tetap baik selamanya.

Hal ketiga adalah kendala yang tidak ada yang menganggarkan: tanda tangan pasca‑kuantum berukuran besar. Tanda tangan ML‑DSA‑65 kira‑kira lima puluh kali ukuran tanda tangan ECDSA P‑256, dan SLH‑DSA lebih besar lagi. Itu memecah hal‑hal: ukuran jabat tangan, perangkat terbatas, protokol dengan batas bidang yang tetap, tautan satelit dan IoT. Anda menemukan masalah ini dengan menguji, bukan dengan membaca standar.

Salah satu tantangan migrasi pasca‑kuantum adalah organisasi mungkin bahkan tidak mengetahui di mana saja kriptografi digunakan di seluruh aplikasi, infrastruktur, perangkat, dan ketergantungan pihak ketiga mereka. Bagaimana perusahaan harus melakukan inventarisasi kriptografi dan mengadopsi crypto‑agility agar transisi algoritma besar berikutnya tidak menjadi keadaan darurat?

Mulailah dengan kebenaran yang tidak nyaman: Anda tidak dapat membuat inventaris kriptografi dengan mengirimkan kuesioner kepada vendor. Anda akan menerima campuran salinan pemasaran, ketidakpastian jujur, dan jawaban yang benar tiga rilis yang lalu. Saya mengatakan ini setelah menghabiskan banyak waktu baru-baru ini membaca dokumentasi vendor perangkat keras di bidang terkait, dan kesenjangan antara klaim dokumentasi dan apa yang sebenarnya dilakukan produk jauh lebih lebar daripada yang diasumsikan pembeli.

Anda harus melihat. Ada tiga lapisan, dan masing‑masing memerlukan teknik berbeda. Kode yang Anda tulis: analisis statis, pemindaian ketergantungan, dan pencarian identifier algoritma yang Anda hard‑code bertahun‑tahun lalu. Kode yang Anda tautkan: software bill of materials, diperluas menjadi cryptographic bill of materials, di mana pekerjaan CBOM benar‑benar berguna. Hal yang Anda beli atau hubungkan: observasi jaringan, karena apa yang sistem Anda benar‑benar negosiasikan di jaringan adalah kebenaran dasar dan seringkali tidak sesuai dengan yang diperkirakan.

Berkenaan dengan agility, prinsipnya sederhana namun praktiknya tidak: algoritma harus menjadi keputusan konfigurasi, bukan perubahan kode. Jika mengubah cipher memerlukan pengembang, proses build, siklus pengujian, dan rilis, Anda tidak memiliki agility. Anda memiliki proyek. Sentralisasikan operasi kriptografi di belakang antarmuka yang Anda kontrol, sehingga ada satu tempat untuk diubah, bukan empat ratus.

Dan bagian yang hampir semua orang lewati: praktikkan. Agility yang belum pernah Anda gunakan hanyalah klaim, bukan kemampuan. Pilih akhir pekan yang tenang, matikan algoritma di lingkungan non‑produksi, dan temukan apa yang rusak. Sesuatu pasti akan rusak. Lebih baik menemukannya pada jadwal Anda daripada saat transisi darurat yang dipaksa.

Salah satu fungsi paksa yang berguna adalah masa hidup sertifikat. Industri bergerak ke sertifikat yang berumur jauh lebih pendek, yang membuat manajemen sertifikat manual tidak dapat ditangani dan memaksa otomatisasi yang memang Anda perlukan. Jika Anda mengotomatisasi penerbitan dan rotasi sertifikat dengan tepat, Anda telah membangun sebagian besar mekanisme yang dibutuhkan transisi algoritma di masa depan.

AI mengubah baik pertahanan siber maupun kemampuan yang tersedia bagi penyerang. Menurut Anda, AI benar‑benar mengubah apa dalam persamaan keamanan, dan di mana organisasi mungkin terlalu fokus pada teknologi sambil mengabaikan kelemahan yang lebih mendasar?

AI benar‑benar mengubah satu hal, dan saya dapat berbicara langsung karena hal ini terjadi pada kami.

Sejumlah signifikan kerentanan yang diungkapkan di OpenSSL tahun ini ditemukan melalui analisis berbasis AI. Pada Januari kami merilis versi yang memperbaiki dua belas masalah, hampir semuanya dari satu grup riset yang menggunakan analisis otomatis, dan mereka menyumbangkan patch bersama laporan. Pada Juni kami memperbaiki use‑after‑free ber‑severitas tinggi dalam verifikasi PKCS#7 yang ditemukan oleh peneliti yang bekerja dengan sistem AI. Itu merupakan perubahan kemampuan nyata dalam menemukan bug memori‑safety dan parsing pada kode C matang yang telah ditinjau oleh ahli selama bertahun‑tahun. Saya melihat pola yang sama di perpustakaan kriptografi lain. Menganalisis sekumpulan CVE Bouncy Castle tahun ini, jejak analisis kode otomatis jelas terlihat.

Implikasi yang jelas adalah bahwa ini berdampak dua arah. Teknik yang sama tersedia bagi siapa pun yang ingin menggunakannya, pada basis kode yang sama, dan pembela tidak memiliki akses eksklusif.

Implikasi yang kurang jelas, dan yang ingin saya tekankan, adalah beban yang ditempatkan pada pemelihara. Membuat laporan kerentanan yang tampak masuk akal kini hampir gratis. Menilai satu laporan tidak. Masih membutuhkan waktu nyata seorang ahli manusia. Tim keamanan sumber terbuka, yang biasanya kecil dan sering sukarela, menyerap volume laporan yang meningkat dengan kualitas sangat bervariasi. Laporan yang baik, seperti riset yang saya sebutkan, disertai dengan reproducer dan patch. Laporan buruk adalah serangan denial‑of‑service terhadap orang yang Anda andalkan. Jika organisasi Anda menggunakan AI terhadap kode sumber terbuka, danaukan kapasitas triase di ujung lain.

Di mana saya rasa perhatian teralihkan: AI tidak memperbaiki sistem Anda. Ia tidak melakukan inventarisasi aset, tidak mengganti kredensial, tidak menonaktifkan perangkat keras yang tidak didukung, atau membuat seseorang bertanggung jawab atas sertifikat yang kedaluwarsa bulan depan. Organisasi yang membeli alat keamanan AI sambil menjalankan perangkat lunak dengan kerentanan yang diketahui tidak memperhatikan urutan yang tepat. Pekerjaan yang tidak glamor masih menjadi tempat risiko berada.

Banyak organisasi berinvestasi besar pada alat tetapi tetap rentan karena kesalahan konfigurasi, sistem usang, proses lemah, atau persiapan insiden yang buruk. Apa kesalahan keamanan paling konsekuensial yang terus Anda lihat, dan apa yang harus dimiliki tim kepemimpinan sebelum serangan benar‑benar terjadi?

Kesalahan paling konsekuensial adalah memperlakukan keamanan sebagai aktivitas pengadaan. Alat dibeli, anggaran terpenuhi, dasbor berwarna hijau, dan tidak ada yang menanyakan apakah organisasi benar‑benar dapat melakukan hal‑hal fundamental.

Kedua, tidak mengetahui apa yang Anda jalankan. Anda tidak dapat memperbaiki perangkat lunak yang tidak Anda ketahui ada, dan kebanyakan organisasi menemukan isi sebenarnya aset mereka selama insiden. Inilah mengapa pekerjaan bill‑of‑materials penting, bukan sebagai artefak kepatuhan melainkan sebagai hal yang Anda cari pada pukul dua pagi ketika advisory kritis muncul dan seseorang menanyakan apakah Anda terpengaruh.

Ketiga, default. Sistem dipasang, berfungsi, dan konfigurasi tidak pernah ditinjau kembali. Lima tahun kemudian konfigurasi itu menjadi liabilitas, dan tidak ada orang yang terlibat dalam keputusan awal yang masih bekerja di sana.

Keempat, manajemen kunci dan sertifikat diserahkan kepada individu. Proporsi luar biasa dari gangguan yang disebabkan sendiri adalah sertifikat kedaluwarsa yang satu orang diam‑diam lacak dalam spreadsheet hingga mereka pindah pekerjaan.

Sebelum insiden, kepemimpinan membutuhkan empat hal. Seorang pengambil keputusan yang bernama dengan wewenang menonaktifkan bisnis, diputuskan sebelumnya secara tertulis, karena argumen tentang siapa yang memiliki wewenang itu bukan hal yang ingin Anda hadapi secara langsung. Retainer yang sudah ditandatangani dengan forensik eksternal dan konsultan khusus, karena pengadaan itu memakan minggu dan Anda akan memiliki jam. Saluran komunikasi yang tidak bergantung pada sistem yang mungkin terkompromi. Dan kemampuan pemulihan yang benar‑benar telah diuji end‑to‑end, bukan sekadar regime backup yang hanya diverifikasi bahwa pekerjaan selesai dengan sukses.

Lalu latihlah. Latihan tabletop di level eksekutif, setahun sekali, akan mengungkap lebih banyak kesenjangan nyata daripada alat lain.

Ketika serangan siber serius terjadi, eksekutif dapat tiba‑tiba harus membuat keputusan teknis, hukum, operasional, dan komunikasi di bawah tekanan besar. Apa yang membedakan organisasi yang merespons secara efektif dari yang membiarkan insiden menjadi jauh lebih buruk?

Organisasi yang menanganinya dengan baik telah membuat keputusan penting sebelum insiden, sehingga selama insiden mereka mengeksekusi bukan berdebat. Itu sebagian besar.

Selain persiapan, beberapa hal secara konsisten memisahkan respons baik dari yang buruk.

Mereka memisahkan investigasi teknis dari jalur eksekutif dan komunikasi, dengan antarmuka yang jelas di antara keduanya. Ketika orang yang sama mencoba menahan intrusi dan menyiapkan notifikasi pelanggan, kedua pekerjaan dilakukan dengan buruk.

Mereka menjaga bukti sebelum memperbaiki. Dorongan untuk segera membangun kembali mesin yang dikompromikan sangat kuat dan menghancurkan informasi yang diperlukan untuk menentukan ruang lingkup. Jika Anda tidak dapat menjawab “apa lagi yang mereka sentuh,” Anda tidak dapat memberi tahu siapa pun bahwa insiden telah selesai dengan kredibel.

Mereka menerima bahwa informasi awal bersifat sementara dan berkomunikasi sesuai. Sebagian besar kerusakan reputasi yang saya amati bukan berasal dari pelanggaran melainkan dari pernyataan awal yang yakin dan kemudian harus ditarik kembali. Mengatakan “ini yang kami ketahui, ini yang belum kami ketahui, ini kapan kami akan memperbarui Anda” bukan kelemahan. Itu satu‑satunya posisi yang tidak perlu Anda balikkan.

Dan secara kritis: mereka menciptakan kondisi di mana insinyur dapat memberi tahu eksekutif berita buruk. Pola kegagalan yang paling sering saya lihat adalah organisasi di mana eksposur hukum begitu jelas sehingga tidak ada yang ingin menjadi orang yang menuliskan apa yang sebenarnya terjadi. Insiden kemudian memburuk dalam diam. Jika insinyur Anda mengelola liabilitas mereka sendiri alih-alih insiden, Anda memiliki masalah tata kelola yang tidak dapat diperbaiki dengan alat apa pun.

OpenSSL berada pada posisi tidak biasa sebagai infrastruktur sumber terbuka kritis yang digunakan di seluruh ekosistem teknologi, sementara OpenSSL Corporation fokus melayani komunitas komersial bersama OpenSSL Foundation yang beroperasi secara independen. Bagaimana Anda menyeimbangkan kebutuhan perusahaan, pengembang, regulator, dan komunitas sumber terbuka yang lebih luas ketika keputusan tentang keamanan dan kompatibilitas dapat memengaruhi sebagian besar internet?

Jawaban jujur adalah Anda tidak menyeimbangkan mereka dengan mencoba menyenangkan semua orang dalam setiap keputusan. Anda menyeimbangkannya dengan memiliki kebijakan yang dipublikasikan dan menerapkannya secara konsisten, sehingga orang dapat merencanakan di sekitar Anda meskipun mereka tidak menyukai hasil tertentu.

Prediktabilitas adalah apa yang kami berikan kepada pengguna. Kami merilis rilis fitur pada April dan Oktober. Kami menyatakan sebelumnya rilis mana yang stabil jangka panjang dan sampai kapan. Kami mengumumkan penghapusan signifikan jauh sebelum terjadi. Penghapusan ENGINE pada 4.0 diumumkan secara publik berbulan‑bulan sebelum rilis, dan disetujui oleh Corporation dan Foundation. Siapa pun yang terkejut pada April belum memperhatikan, dan kami telah membuatnya semudah mungkin untuk memperhatikan.

Jawaban struktural adalah pemisahan itu sendiri. Foundation ada untuk melayani perpustakaan sumber terbuka dan komunitas di sekitarnya. Corporation ada untuk melayani organisasi dengan kebutuhan komersial (komitmen dukungan, validasi FIPS, timeline spesifik) dan membuat seluruh ekosistem berkelanjutan secara finansial. Menjaga keduanya terpisah berarti tidak ada satu set kebutuhan yang diselesaikan diam‑diam demi kepentingan yang lain. Ketika kebutuhan perusahaan dan komunitas benar‑benar bertentangan, konflik itu terjadi antara dua organisasi dengan mandat yang jelas, bukan di dalam kepala satu orang.

Bagian lain adalah mendengarkan dengan tepat, yang memerlukan mekanisme nyata bukan asumsi. Itulah mengapa kami menyelenggarakan the conference, yang di Praha bulan Oktober ini, dan mengapa infrastruktur komunitas ada. Sangat mudah bagi pemelihara mengembangkan teori percaya diri tentang apa yang dibutuhkan pengguna. Lebih berguna berada di ruangan bersama mereka.

10. Melihat dekade berikutnya, transisi keamanan atau kriptografi apa yang Anda percaya masih diremehkan oleh organisasi saat ini, dan pelajaran apa dari evolusi SSL, OpenSSL, serta 30‑tahun keamanan internet yang harus diterapkan pemimpin saat mempersiapkannya?

Transisi yang saya rasa paling diremehkan bukan kriptografi pasca‑kuantum sebagai masalah algoritma. Itu adalah identitas mesin dan hierarki sertifikat di bawah semua hal.

Pertukaran kunci pasca‑kuantum akan sebagian besar terselesaikan oleh default, dan banyak yang sudah terjadi. Apa yang tidak akan terselesaikan oleh default adalah infrastruktur kepercayaan: sertifikat root di perangkat keras, kunci penandatangan firmware yang dibakar ke perangkat, HSM dengan sisa layanan satu dekade, sistem industri dan medis yang masih beroperasi pada 2040 dengan asumsi kriptografi yang dibangun saat manufaktur. Itu tidak dapat diperbarui dengan mengirimkan versi perpustakaan baru, dan dalam beberapa kasus tidak dapat diperbarui sama sekali. Skala masalah penggantian itu belum tercermin dalam perencanaan modal siapa pun.

Seiring dengan itu ada transisi regulasi. Cyber Resilience Act di Eropa, dan kerangka serupa di tempat lain, akan mengubah kewajiban terkait pengiriman perangkat lunak dengan komponen yang tidak Anda tulis. Kebanyakan organisasi belum menelusuri apa artinya bagi ketergantungan mereka pada sumber terbuka, atau bagi orang yang memeliharanya.

Three lessons from thirty years:

1. Transisi memakan waktu satu dekade lebih lama daripada yang diumumkan. SSLv3 dihentikan pada 2015, dinonaktifkan secara default pada 2016, dan kami akhirnya menghapus kodenya pada April 2026. Itu sebelas tahun, untuk protokol yang semua orang setuju rusak. Rencanakan migrasi pasca‑kuantum berdasarkan realitas itu, bukan berdasarkan siaran pers.
2. Default adalah satu‑satunya kontrol keamanan yang berfungsi pada skala. Apa pun yang mengharuskan setiap administrator membuat keputusan yang tepat tidak akan terjadi. Alasan pertukaran kunci hibrida pasca‑kuantum dapat diterapkan secepat itu karena diaktifkan secara default dan tidak memerlukan keputusan apa pun. Rancang untuk orang‑orang yang tidak akan pernah membaca dokumentasi Anda, karena hampir semua orang termasuk dalam kategori itu.
3. Anda bergantung pada lebih sedikit orang daripada yang Anda kira. Hampir setiap organisasi di dunia bergantung pada kode kriptografi yang dipelihara oleh sejumlah kecil individu. Itu benar ketika hanya kami berdua di Brisbane, dan struktur belum berubah secara fundamental meskipun taruhannya meningkat berlipat ganda. Apa pun yang Anda rencanakan untuk dekade berikutnya, sebagian darinya bergantung pada pemelihara yang belum pernah Anda hubungi dan tidak Anda danai. Itu penting untuk diketahui sebelum Anda membutuhkannya.

Terima kasih atas wawancara yang luar biasa. Pembaca yang ingin mempelajari lebih lanjut sebaiknya mengunjungi OpenSSL.