Tim Hudson, OpenSSL Corporation Başkanı – Röportaj Serisi

Tim Hudson SSLeay’in ortak yazarı ve OpenSSL Conference organizatörlerinden biridir, Prag 13‑15 Ekim 2026. Sistem ve ağ güvenliği alanında 30 yılı aşkın deneyime sahiptir ve OpenSSL Corporation Başkanı ve Cryptsoft Pty Ltd‘de Baş Teknoloji Sorumlusu (CTO) olarak görev yapmaktadır. 1995’ten beri çalışmaları arasında Eric Young ile birlikte SSLeay’i kurmak (daha sonra OpenSSL Library‘i oluşturmak, RSA Security Australia geliştirme merkezini kurmak, ABD şifreleme ihracat düzenlemelerindeki değişikliklere katkıda bulunmak, 30’dan fazla FIPS 140 doğrulamasına liderlik etmek, OASIS KMIP ve SAM Teknik Komitelerinin ortak başkanlığını yapmak ve RSA Conference, AusCERT, ICMC, LinuxConf ve OpenSSL Conference gibi önde gelen güvenlik konferanslarında konuşmak yer alıyor.

OpenSSL dünyanın en yaygın kullanılan kriptografik kütüphanelerinden biri olan OpenSSL Library’yi geliştiren ve sürdüren küresel bir işbirlikçi açık kaynak projesidir. İşletim sistemleri, bulut platformları, kurumsal yazılımlar ve bağlı cihazlar arasında kullanılan OpenSSL Library, her gün milyarlarca güvenli çevrimiçi etkileşimi korumaya yardımcı olur. OpenSSL Foundation ve OpenSSL Corporation aracılığıyla proje, güvenilir kriptografiyi ilerletmeyi, sürdürülebilir açık kaynak geliştirmeyi desteklemeyi ve internetin güvenliğini güçlendirmeyi taahhüt eder.

ABD dışında geliştirilmiş bir SSL uygulamasına ihtiyaç olduğunu fark ederek 1995’te Eric Young ile SSLeay’i kurdunuz; bu çalışma sonunda OpenSSL’in temelini oluşturdu. Başlangıçta hangi sorunu çözmeye çalışıyordunuz ve teknolojinin internet güvenliğinin bu kadar temel bir parçası olabileceğini o dönemde öngörüyor muydunuz?

Sorun tamamen somut ve öncelikle ticari bir sorundu. Brisbane’deki Mincom’da çalışıyordum ve iletişimlerini güvence altına almaları gereken müşterilerimiz vardı. Bu yeteneği satın almanın bir yolu yoktu. ABD’nin şifreleme ihracat kontrolleri, Amerikan ürünlerinin ya tamamen temin edilememesine ya da anahtar boyutlarının o kadar kısıtlı olmasına neden oluyordu ki bunları dağıtmak dürüst olmazdı. Bu, ihracat politikasına karşı felsefi bir itiraz değildi. İhtiyacım olan bileşen, satın alabileceğim herhangi bir biçimde mevcut olmayan bir mühendislik sorunu ve müşterilerimiz bekliyordu.

Elimde olan, çoğu kişinin unuttuğu bir bilgiydi. Eric Young, birkaç yıl önce bir DES uygulaması yazmıştı: iyi, temiz, ücretsiz olarak erişilebilir kod, sadece kendi amacı için yazılmış ve bununla tamamen alakasızdı. Eric SSL üzerinde çalışmıyordu. SSL’den haberi yoktu. Netscape spesifikasyonu yayınlandığında, onu okudum, problemi Eric’e götürdüm ve onun zaten sahip olduğu şeyden nispeten mütevazı bir adım olarak sundum.

Bu, tüm resmi yansıtıyordu. Her bir parça basitti ancak parçaların sayısı oldukça fazlaydı. Bir DES uygulaması size tek bir simetrik şifre verir. SSL ise açık anahtar kriptografisi, keyfi hassasiyetli aritmetik, ASN.1, X.509 sertifika işleme ve bir protokol durum makinesi gerektirir; hepsi doğru olmalıdır, çünkü kriptografide neredeyse doğru olan da kırılmıştır. Ölçeği iyimser bir şekilde sunmuştum. Eric, ne kadar çok şey olduğunu çabucak fark etti ve bundan keyif aldı, çünkü ölçek engel değil çekicilikti. Başka bir şekilde başlamış olacağına emin değilim.

O, kriptografik çekirdeği yaptı; bu yüzden kütüphane onun baş harflerini taşıyor. Ben ise kütüphaneyi diğer insanların gerçekten dağıtabileceği bir şey haline getiren parçaları üstlendim: uygulama entegrasyonu, testler, dokümantasyon ve topluluk yönü. Ayrıca rekabetçi bir şifreleme kütüphanesinin kullanıldığı her yeri aktif olarak bulup dönüştürdüm veya değiştirdim. SSLtelnet, SSLftp, NCSA httpd ve birçok başka paket benim çalışmamdı; Eric’in uyguladığı kriptografik algoritmalar ve protokoller üzerine inşa edilen uygulamalar. Bu birleşim, her birimizin gerçekten ilgi duyduğu konulara odaklanmasını sağladı; bunun devam etmesinin ana nedeni bu olduğunu düşünüyorum.

Avustralya’da olmak, sorunu çözmeyi mümkün kıldı ve daha sonra birçok kişinin aynı sorunu aynı sebeple yaşadığını gördük. Brisbane’de belirli bir müşteri ihtiyacını karşılamak için inşa edilen bir şey, ABD dışındaki herkes için faydalı oldu ve sonunda içinde de birçok kişi için yararlı hâle geldi.

Bunun ne olacağını biliyor muyduk? Hayır. Kimse kritik altyapı inşa etmeye niyet etmez. Kritik altyapı, yıllar sonra kimlerin ona bağımlı olduğunu fark ettiğinizde ortaya çıkan şeydir. Biz, önümüzdeki sorunu çözdüğümüzü ve aynı duvara çarpan diğer insanların sorularını yanıtladığımızı düşündük. Soruları yanıtlamak, kod kadar önemli oldu.

Otuz yılı aşkın süredir kriptografi ve internet güvenliği alanında çalışıyorsunuz. Bu dönemde tehdit ortamında en çarpıcı biçimde ne değişti ve teknolojideki büyük ilerlemelere rağmen hangi güvenlik sorunları şaşırtıcı ölçüde aynı kaldı?

En büyük değişiklik, sistemlere saldırmanın arkasında ekonomik bir model olan bir meslek haline gelmesidir. 90’ların ortalarında sistemlere giren kişiler çoğunlukla ilginç buldukları için bunu yapıyordu. Bugün ise uzmanlaşma, araçlar, tedarik zincirleri, müşteri desteği ve bazı durumlarda devlet fonlaması bulunan bir endüstri var. Bu, düşünme biçiminizi tamamen değiştirir; çünkü artık merak karşıtı savunma yapmıyorsunuz. Bütçesi, son teslim tarihi ve iş gerekçesi olan birine karşı savunma yapıyorsunuz.

İkinci değişiklik ölçek ve bağımlılıktır. 1995’te ortalama bir uygulama sizin yazdığınız bir şeydi. Bugün ortalama bir uygulama bir araya getirdiğiniz bir şeydir ve içindeki kodun çoğu, hiç tanımadığınız ve adını bile bilemediğiniz kişiler tarafından yazılmıştır. Saldırı yüzeyi kodunuzdan bağımlılıklarınıza kaydı ve çoğu kuruluş bu doğrultuda düşünce yapısını ayarlamadı.

Sürekli aynı kalan şey hata modlarıdır. Güvenilmeyen girdiyi işleyen kodda hâlâ hatalar yazıyoruz. Kimsenin gözden geçirmediği varsayılanlarla sistemler dağıtmaya devam ediyoruz. Sertifikalar hâlâ Cumartesi günleri sona eriyor. Kimlik bilgileri hâlâ bulunmaması gereken yerlere düşüyor. Ve kriptografi hâlâ matematiksel olarak neredeyse hiç kırılmıyor. Atlatılıyor, yanlış yapılandırılıyor ya da basitçe açılmıyor. 1996’daki en üst on ihlal nedeninin bir listesini ve geçen ayki bir listeyi bana verirseniz, aralarındaki farkı ayırt etmekte zorlanırsınız. Teknoloji tamamen değişti. Hatalar değişmedi.

OpenSSL 4.0 Nisan 2026’da yayımlandı ve projenin birkaç yıl aradan sonraki ilk büyük sürümü oldu. Bu sürüm, kriptografik altyapının gidişatı hakkında ne söylüyor ve hangi değişikliklerin OpenSSL’e bağımlı kuruluşlar açısından en önemli olacağını düşünüyorsunuz?

4.0 hakkında en faydalı şey, öncelikle bir çıkarma sürümü olması ve bunun amacının bu olmasıdır.

ENGINE arayüzünü tamamen kaldırdık. SSLv3 ve SSLv2 ClientHello’yu kaldırdık. Derleme zamanında eski eliptik eğrileri ve açık EC eğrilerini devre dışı bıraktık. ASN1_STRING’i opak hâle getirdik ve çok sayıda API imzasını sıkılaştırdık. Bunlar, insanlar için iş yaratacak ve önemli olan değişikliklerdir; çünkü sadece birikmeye devam eden bir kriptografik kütüphane güvenli kalamaz. Hayatta tuttuğunuz her eski kod yolu, sizin adınıza birinin sürdürdüğü ve kimsenin test etmediği bir saldırı yüzeyidir.

Eklemeler de var: Şifreli İstemci Selamı (Encrypted Client Hello), hibrit SM2/ML‑KEM grubunu içeren RFC 8998 desteği, cSHAKE, SNMP ve SRTP KDF’leri, TLS 1.2 için müzakere edilen FFDHE. Özellikle ECH, gerçek bir gizlilik açığını kapatıyor; çünkü Sunucu Adı Belirtimi (Server Name Indication), TLS 1.3 yayınlandığından beri ziyaret ettiğiniz her sitenin kimliğini sızdırıyordu. Ancak asıl hikaye kaldırılan özelliklerde.

Kuruluşların en çok anlamasını istediğim nokta şudur: 4.0 LTS sürümü değildir. Mayıs 2027’ye kadar desteklenecek. Şu anki uzun vadeli kararlı sürüm 3.5’tir, Nisan 2030’a kadar destekleniyor ve 3.5 zaten post‑kuantum algoritmalarını içeriyor. En yeni kodu istiyorsanız 4.0’ı kullanın. Beş yıllık bir geçiş planı oluşturabileceğiniz istikrarlı bir hedef istiyorsanız 3.5’i çalıştırın. Daha yüksek bir numarayı, sadece daha yüksek olduğu için seçmek, her döngüde insanların yaptığı bir hatadır.

Kuantum sonrası kriptografi bir araştırma sorunundan geçiş sürecinin yönetilmesi gereken bir alana dönüştü. OpenSSL hâlihazırda ML-KEM, ML-DSA ve SLH-DSA algoritmalarının yanı sıra hibrit kuantum sonrası anahtar değişimini destekliyor. Kuantum hesaplamanın hâlâ endişelenmeye değmeyecek kadar uzakta olduğunu düşünen iş dünyası liderleri bugün hangi riskleri gözden kaçırıyor?

En yaygın hata, bunu kriptografik açıdan ilgili bir kuantum bilgisayarının ne zaman ortaya çıkacağı sorusu olarak ele almaktır. Bu yanlış bir değişkendir. Doğru soru, verilerinizin ne kadar süre gizli kalması gerektiği ve geçişinizin ne kadar süreceğidir. İkinciyi birinciden çıkarırsanız gerçek son tarihinizi elde edersiniz ve birçok kuruluş için bu tarih zaten geçmişte.

Şifreli trafiği bugün yakalayabilir ve süresiz olarak depolayabilirsiniz. İçindeki bilgi yirmi yıllık bir hassasiyet ufku taşıyorsa (hasta kayıtları, personel dosyaları, fikri mülkiyet, diplomatik belgeler, finansal konumlar), bir düşmanın şu anda kuantum bilgisayarına ihtiyacı yoktur. Sonunda birine ihtiyaç duyacak ve bu arada ucuz depolama yeterli olacaktır. Bu spekülatif bir saldırı değil, bir dosyalama kararıdır.

İkinci göz ardı edilen şey, geçişin tek bir proje olmamasıdır. Anahtar değişimi kolay kısımdır ve büyük bir kısmı zaten gerçekleşmektedir: OpenSSL 3.5, hibrit post‑kuantum anahtar değişimini TLS varsayılanı yaptı, bu yüzden birçok kuruluş hâlâ bununla ilgili bir karar almadan post‑kuantum anahtar anlaşması yürütüyor. İmzalar ve sertifika hiyerarşisi zor kısmıdır; çünkü bunlar sertifika otoriteleri, donanım güven kökleri, firmware imzalama anahtarları, donanım güvenlik modülleri ve RSA’nın sonsuza kadar iyi olacağı varsayımıyla inşa edilen, on beş yıllık saha ömrüne sahip cihazları içerir.

Üçüncü şey, kimsenin bütçesine dahil etmediği kısıtlamadır: post‑kuantum imzaları büyüktür. Bir ML‑DSA‑65 imzası, bir ECDSA P‑256 imzasının yaklaşık elli katı büyüklüğündedir ve SLH‑DSA daha da büyüktür. Bu, el sıkışma boyutlarını, sınırlı cihazları, sabit alan limitli protokolleri, uydu ve IoT bağlantılarını bozar. Bu sorunları standart okuyarak değil, test ederek bulursunuz.

Kuantum sonrası kriptografiye geçişin zorluklarından biri, kuruluşların uygulamaları, altyapıları, cihazları ve üçüncü taraf bağımlılıklarında kriptografinin nerelerde kullanıldığını tam olarak bilmeyebilmesidir. Şirketler, bir sonraki büyük algoritma geçişinin acil duruma dönüşmemesi için kriptografik envantere ve kriptografik çevikliğe nasıl yaklaşmalı?

Rahatsız edici bir gerçekle başlayın: tedarikçilerinize bir anket göndererek kriptografik envanter oluşturamazsınız. Karşılığında pazarlama metni, dürüst belirsizlik ve üç sürüm önce doğru olan yanıtların bir karışımını alırsınız. Bunu, yakın zamanda ilgili bir alanda donanım tedarikçi belgelerini okurken geçirdiğim önemli zaman sayesinde söylüyorum; belgelerin iddia ettikleri ile bir ürünün gerçekte yaptığı arasındaki fark, çoğu alıcının varsaydığından daha büyüktür.

Bakmanız gerekir. Üç katman var ve her biri farklı teknikler gerektirir. Yazdığınız kod: statik analiz, bağımlılık taraması ve yıllar önce sabit kodladığınız algoritma tanımlayıcılarını arama (grep). Bağladığınız kod: yazılım malzeme listeleri, kriptografik malzeme listelerine genişletilmiş, CBOM çalışmasının gerçekten faydalı olduğu yer. Satın aldığınız veya bağladığınız şeyler: ağ gözlemi, çünkü sistemlerinizin kabloda gerçekte ne müzakere ettiğini gerçek durumdur ve çoğu zaman kimsenin inandığı şey değildir.

Esneklik konusunda prensip basittir ancak uygulama kolay değildir: algoritma bir yapılandırma kararı olmalı, kod değişikliği olmamalıdır. Bir şifreyi değiştirmek bir geliştirici, bir derleme, bir test döngüsü ve bir sürüm gerektiriyorsa, esnekliğiniz yoktur. Bir projeye sahipsiniz demektir. Kriptografik işlemleri kontrol ettiğiniz bir arayüzün arkasına merkezileştirin; böylece dört yüz yerine tek bir yerde değişiklik yapabilirsiniz.

Ve hemen hemen herkesin atladığı bölüm: bunu uygulayın. Sessiz bir hafta sonu seçin, üretim dışı bir ortamda bir algoritmayı kapatın ve neyin kırıldığını öğrenin. Bir şey kırılacaktır. Bunu zorunlu bir acil geçiş sırasında değil, kendi takviminizde keşfetmek daha iyidir.

Kullanışlı bir zorlayıcı faktör, sertifika ömrüdür. Endüstri, çok daha kısa ömürlü sertifikalara yöneliyor; bu da manuel sertifika yönetimini sürdürülemez kılıyor ve zaten ihtiyacınız olacak otomasyonu zorunlu kılıyor. Sertifika oluşturma ve döndürmeyi doğru bir şekilde otomatikleştirirseniz, gelecekteki bir algoritma geçişi için gereken çoğu altyapıyı inşa etmiş olursunuz.

Yapay zekâ hem siber güvenlik savunmasını hem de saldırganların elindeki imkânları değiştiriyor. Sizce yapay zekâ güvenlik denklemini nerelerde gerçekten değiştiriyor, kuruluşlar nerelerde daha temel zayıflıkları gözden kaçırarak teknolojiye gereğinden fazla odaklanıyor?

AI gerçekten bir şeyi değiştiriyor ve bu konuda doğrudan konuşabilirim çünkü bizimle de oldu.

Bu yıl OpenSSL’de açıklanan güvenlik açıklarının önemli bir kısmı AI destekli analizle bulundu. Ocak ayında on iki sorunu düzelten bir sürüm yayımladık; bunların neredeyse tamamı otomatik analiz kullanan bir araştırma grubundan geliyordu ve raporlarla birlikte yamalar sağladılar. Haziran ayında bir araştırmacının AI sistemiyle çalışırken bulduğu PKCS#7 doğrulamasındaki yüksek şiddette bir use‑after‑free hatasını düzelttik. Bu, yıllardır uzmanlar tarafından incelenen olgun C kodunda bellek güvenliği ve ayrıştırma hatalarını bulmadaki gerçek bir yetenek değişikliğidir. Aynı modeli diğer kriptografik kütüphanelerde de gördüm. Bu yılki bir Bouncy Castle CVE topluluğunu incelerken, otomatik kod analizinin parmak izi nettir.

Açık sonuç, bunun iki yönlü olduğu. Aynı teknikler, aynı kod tabanlarında, onları kullanmak isteyen herkesin eline ulaşabilir ve savunucuların özel erişimi yoktur.

Daha az belirgin sonuç, ve vurgulamak istediğim, bakımcılar üzerindeki yüküdür. Makul görünümlü bir güvenlik açığı raporu oluşturmak neredeyse ücretsiz hâle geldi. Bir raporu önceliklendirmek ise ücretsiz değil. Hâlâ bir insan uzmanının gerçek zamanını maliyetliyor. Genellikle küçük ve gönüllü olan açık kaynak güvenlik ekipleri, kalite açısından çok değişken raporların artan hacmini absorbe ediyor. Bahsettiğim araştırma gibi iyi raporlar yeniden üreticiler ve yamalarla birlikte gelir. Kötü raporlar ise size bağımlı olduğunuz kişilere yönelik bir hizmet reddi saldırısıdır. Kuruluşunuz açık kaynak koduna AI uyguluyorsa, diğer uçtaki önceliklendirme kapasitesine fon ayırın.

Dikkatin yanlış yönlendirildiğini düşündüğüm yer: AI sistemlerinizi yamalamaz. Varlık envanteri oluşturmaz, kimlik bilgilerinizi döndürmez, desteklenmeyen donanımınızı emekli etmez ya da gelecek ay süresi dolacak sertifika için birini sorumlu tutmaz. Bilinen, yamalanmamış güvenlik açıkları olan yazılımları çalıştırırken AI güvenlik araçları satın alan kuruluşlar sıralamayı yanlış yapıyor. Parlak olmayan işler hâlâ riskin bulunduğu yerdir.

Pek çok kuruluş araçlara büyük yatırımlar yapmasına rağmen yapılandırma hataları, eski sistemler, zayıf süreçler veya yetersiz olay hazırlığı nedeniyle savunmasız kalıyor. Görmeye devam ettiğiniz en ciddi güvenlik hataları neler ve yönetim ekipleri saldırı gerçekleşmeden önce neleri hazır bulundurmalı?

En sonuçsal hata, güvenliği bir satın alma faaliyeti olarak görmektir. Araçlar satın alınır, bütçeler karşılanır, panolar yeşildir ve kimse kuruluşun temel şeyleri gerçekten yapıp yapamayacağını sormamıştır.

İkinci hata, ne çalıştırdığınızı bilmemektir. Sahip olduğunuz yazılımı bilmeden yamalayamazsınız ve çoğu kuruluş bir olay sırasında varlıklarının gerçek içeriğini keşfeder. Bu yüzden malzeme listesi çalışması önemlidir; uyum belgesi olarak değil, kritik bir uyarı çıktığında ve birisi etkilenip etkilenmediğinizi sorduğunda sabah iki gibi başvurduğunuz şey olarak.

Üçüncü hata, varsayılanlardır. Sistemler kurulur, çalışır ve yapılandırma bir daha gözden geçirilmez. Beş yıl sonra bu yapılandırma bir sorumluluktur ve orijinal kararda yer alan kimse hâlâ orada çalışmaz.

Dördüncü hata, anahtar ve sertifika yönetiminin bireylere bırakılmasıdır. Kendi kendine neden olduğu kesintilerin çarpıcı bir oranı, bir kişinin iş değiştirmesine kadar sessizce bir elektronik tabloyla takip ettiği süresi dolmuş sertifikalardır.

Bir olaydan önce, liderliğin dört şeye ihtiyacı vardır. İşletmeyi kapatma yetkisine sahip, önceden belirlenmiş ve yazılı olarak atanmış bir karar verici; çünkü bu yetkinin kimde olduğu tartışması canlı bir ortamda olmak istemezsiniz. Dışarıdan adli bilişim ve uzman danışmanlık için önceden imzalanmış sözleşmeler; çünkü bu satın alma haftalar alır ve siz sadece saatleriniz olur. Olası saldırıya uğrayabilecek sistemlere bağlı olmayan bir iletişim kanalı. Ve uçtan uca gerçekten test edilmiş bir geri yükleme yeteneği; sadece işlerin başarılı bir şekilde tamamlandığı anlamına gelen bir yedekleme düzeni değil.

Ardından bunu prova edin. Yılda bir kez üst düzey yöneticilerle yapılan bir masaüstü tatbikatı, başka bir araçtan daha fazla gerçek eksikliği ortaya çıkarır.

Ciddi bir siber saldırı yaşandığında yöneticiler bir anda yoğun baskı altında teknik, hukuki, operasyonel ve iletişimle ilgili kararlar vermek zorunda kalabiliyor. Etkili karşılık veren kuruluşları, olayın çok daha kötüleşmesine izin verenlerden ayıran nedir?

İyi yöneten kuruluşlar, olayı önceden önemli kararları almışlardır; böylece olay sırasında tartışmak yerine yürütme aşamasındadırlar. Bu, büyük ölçüde bu kadarıdır.

Hazırlığın ötesinde, birkaç şey sürekli olarak iyi yanıtları kötü yanıtlardan ayırır.

Teknik soruşturmayı yönetsel ve iletişim akışından ayırırlar ve aralarında tanımlı bir arayüz bulunur. Aynı kişiler bir saldırıyı sınırlamaya ve müşteri bildirimini hazırlamaya çalıştığında, her iki iş de kötü yapılır.

Onarım yapmadan önce kanıtları korurlar. Ele geçirilen makineyi hemen yeniden inşa etme içgüdüsü güçlüdür ve kapsamı belirlemek için gereken bilgiyi yok eder. “Başka neye dokundular” sorusuna cevap veremezseniz, olaydaki herkes’e olayın bittiğini güvenilir bir şekilde söyleyemezsiniz.

Erken bilgilerin geçici olduğunu kabul eder ve buna göre iletişim kurarlar. Gözlemlediğim itibar zararı çoğu zaman ihlâlden değil, geri çekilmek zorunda kalan kendinden emin erken açıklamalardan kaynaklandı. “Şu anda bildiklerimiz, henüz bilmediklerimiz ve ne zaman güncelleyeceğimiz” demek zayıflık değildir. Geri almanız gerekmeyecek tek konum budur.

Ve kritik olarak: mühendislerin yöneticilere kötü haber söyleyebileceği koşulları yaratırlar. En sık gördüğüm başarısızlık modeli, yasal riskin o kadar belirgin olduğu bir kuruluşta, kimsenin gerçekte ne olduğunu yazmak istemediği durumdur. Olay sessizce daha da kötüleşir. Mühendisler olayı değil, kendi sorumluluklarını yönetiyorsa, araçların ne kadar çok olursa olsun çözemeyeceğiniz bir yönetişim sorununuz vardır.

OpenSSL, teknoloji ekosisteminin tamamında kullanılan kritik bir açık kaynak altyapısı olarak sıra dışı bir konumda. OpenSSL Corporation ise bağımsız olarak faaliyet gösteren OpenSSL Foundation ile birlikte ticari topluluklara hizmet vermeye odaklanıyor. Güvenlik ve uyumluluk kararları internetin bu kadar büyük bir bölümünü etkileyebilirken işletmelerin, geliştiricilerin, düzenleyicilerin ve daha geniş açık kaynak topluluğunun ihtiyaçlarını nasıl dengeliyorsunuz?

Dürüst cevap, her kararda herkesi mutlu etmeye çalışarak dengelemeye çalışmadığınız yönündedir. Dengeyi, yayınlanmış bir politika oluşturup bunu öngörülebilir şekilde uygulayarak sağlarsınız; böylece insanlar belirli bir sonucu beğenmeseler bile sizin etrafınızda plan yapabilirler.

Öngörülebilirlik, kullanıcılarımıza borçlu olduğumuz şeydir. Nisan ve Ekim aylarında özellik sürümleri yayınlarız. Hangi sürümün uzun vadeli kararlı olduğunu ve ne zamana kadar destekleneceğini önceden bildiririz. Önemli kaldırımları gerçekleşmeden çok önce duyururuz. 4.0’daki ENGINE kaldırımı, sürümden aylar önce kamuoyuna açıklanmış ve hem Şirket hem de Vakıf tarafından onaylanmıştır. Nisan’da buna şaşıranlar dikkat etmemiştir ve biz de dikkat etmeyi makul ölçüde kolaylaştırdık.

Yapısal cevap, ayrılığın kendisidir. Vakıf, açık kaynak kütüphaneyi ve etrafındaki topluluğu hizmet etmek için var. Şirket ise ticari gereksinimleri (destek taahhütleri, FIPS doğrulamaları, belirli zaman çizelgeleri) olan kuruluşları hizmet etmek ve tüm süreci finansal olarak sürdürülebilir kılmak için var. Bu iki yapıyı ayrı tutmak, ihtiyaçların birinin diğerinin lehine sessizce çözülmemesini sağlar. Kurumsal gereksinimler ve topluluk gereksinimleri gerçekten çeliştiğinde, bu çatışma bir kişinin kafasında değil, net görev tanımları olan iki organizasyon arasında gerçekleşir.

Diğer bölüm ise doğru dinlemektir; bu, varsayımlardan ziyade gerçek mekanizmalar gerektirir. Bu, bu Ekim ayında Prag’da gerçekleşecek konferans düzenlememizin ve topluluk altyapısının var olmasının büyük bir kısmını açıklar. Bakımcıların kullanıcıların neye ihtiyacı olduğu konusunda kendinden emin teoriler geliştirmesi çok kolaydır. Onlarla aynı odada olmak çok daha faydalıdır.

Önümüzdeki on yıla baktığınızda kuruluşların bugün hâlâ hangi güvenlik veya kriptografi geçişini hafife aldığını düşünüyorsunuz? Yöneticiler buna hazırlanırken SSL’in, OpenSSL’in ve son 30 yıllık internet güvenliğinin gelişiminden hangi dersleri uygulamalı?

Bence en çok hafife alınan geçiş, post‑kuantum kriptografinin bir algoritma sorunu olarak değil, makine kimliği ve her şeyin altındaki sertifika hiyerarşisinin olmasıdır.

Post‑kuantum anahtar değişimi büyük ölçüde varsayılanlarla çözülecek ve bunun çoğu zaten gerçekleşti. Varsayılanlarla çözülemeyecek olan ise güven altyapısıdır: donanımdaki kök sertifikalar, cihazlara yerleştirilmiş firmware imzalama anahtarları, on yıl daha hizmet verecek HSM’ler, üretim sırasında kriptografik varsayımlarla inşa edilen ve 2040’da hâlâ çalışacak endüstriyel ve tıbbi sistemler. Bunlar yeni bir kütüphane sürümüyle güncellenemez ve bazı durumlarda hiç güncellenemez. Bu değişim sorununun ölçeği hâlâ hiçbir kuruluşun sermaye planlamasında yer almıyor.

Bunun yanında bir düzenleyici geçiş de var. Avrupa’daki Cyber Resilience Act ve diğer bölgelerdeki benzer çerçeveler, yazmadığınız bileşenleri içeren yazılım dağıtımına ilişkin yükümlülükleri değiştirecek. Çoğu kuruluş, bunun açık kaynak bağımlılıkları ya da bakımını yapan kişiler için ne anlama geldiğini henüz değerlendirmedi.

1. Geçişler açıklanandan on yıl daha uzun sürer. SSLv3 2015’te kullanımdan kaldırıldı, 2016’da varsayılan olarak devre dışı bırakıldı ve kodu nihayet Nisan 2026’da kaldırdık. Bu, herkesin kırık olduğu kabul ettiği bir protokol için on bir yıldır. Post‑kuantum geçişini bu gerçeğe göre planlayın, basın bülteni yerine.
2. Büyük ölçekte işe yarayan tek güvenlik kontrolü varsayılan ayarlardır. Her yöneticinin doğru karar vermesini gerektiren her şey gerçekleşmez. Hibrit post‑kuantum anahtar değişiminin bu kadar hızlı dağıtılmasının nedeni, varsayılan olarak açık olması ve hiç karar gerektirmemesidir. Dokümantasyonunuzu hiç okumayacak insanlar için tasarlayın, çünkü bu neredeyse herkes.
3. Düşündüğünüzden daha az kişiye bağımlısınız. Dünyadaki hemen hemen her kuruluş, çok az sayıda birey tarafından bakım yapılan kriptografik koda güveniyor. Bu, Brisbane’de ikimiz olduğumuz zaman da doğruydu ve yapı, riskler katlanarak artsa da temelleri değişmedi. Önümüzdeki on yıl ne planlıyorsanız, bir kısmı hiç temasa geçmediğiniz ve finanse etmediğiniz bir bakımcıya dayanıyor. Onlara ihtiyacınız olacağını bilmek, onlara ihtiyaç duymadan önce değerli.

Harika röportaj için teşekkür ederiz. Daha fazla bilgi edinmek isteyen okuyucular OpenSSL sitesini ziyaret etmelidir.