SSL’in 90’ların sonlarında neden TLS olarak yeniden adlandırıldığı

• 1990’ların ortasındaki tarayıcı savaşları sırasında Netscape’in SSL’i ile Microsoft’un PCT’sinin ayrışma ihtimali büyüyünce, sektör bunları tek bir açık standart altında toplamaya çalıştı
• İlk SSL sürümü kusurları nedeniyle yayımlanamadı; fiilen kullanılan ilk sürüm olan SSL 2 ise birkaç yıl kullanıldı ama kriptografik ve pratik sınırlamalar taşıyordu
• Microsoft’un PCT’si, SSL 2 temel alınarak IE ve IIS’e uygun kendi uzantılarıyla oluşturulmuştu; Netscape ise standart üzerindeki liderliği kaybetmemek için SSL 3.0 ile karşılık verdi
• Netscape ve Microsoft, IETF’nin açık standardizasyon süreci üzerinde uzlaştı, ancak IETF’nin Netscape protokolünü olduğu gibi onaylıyor görünmesinden kaçınılması gerekiyordu
• Sonuçta SSL 3.0’da bazı değişiklikler yapıldı ve adı da değiştirildi; TLS 1.0 ise fiilen SSL 3.1’e daha yakın bir biçimde başladı

---

Tarayıcı savaşları içinde SSL ve PCT

• 1990’ların ortasında Netscape ile Microsoft arasındaki tarayıcı rekabeti, güvenlik protokollerinin standardizasyonunu da etkiledi
• Netscape, SSL protokolünü geliştirdi
  • İlk sürüm, kriptografik kusurlar nedeniyle hızla kırıldı ve yayımlanmadı
  • İlk üretim sürümü SSL 2 idi ve birkaç yıl kullanıldı
  • SSL 2’de kriptografik ve pratik kusurlar vardı, ancak hemen değiştirilmesini gerektirecek kadar dramatik bir kriz söz konusu değildi
• Microsoft, SSL 2’yi değiştirip kendi eklemelerini yaparak PCT’yi tanımladı
  • PCT, SSL 2’den türetilmiş bir protokoldü
  • Destek kapsamı IE ve IIS ile sınırlıydı
• Netscape de SSL 2’nin sorunlarını düzeltmeye çalıştı, ancak Microsoft’un standart üzerinde liderlik ya da sahiplik kazanmasını istemiyordu
  • Bunun sonucunda daha büyük değişiklikler içeren SSL 3.0 geliştirildi

IETF standardizasyonu ve TLS adı

• Sektörden ve topluluktan birçok kişi, protokolün fork edilmesi durumunu önlemek istiyordu
• Consensus Development, Netscape ve Microsoft temsilcilerinin bir araya geldiği bir toplantı düzenledi
  • Tim Dierks o sırada Christopher Allen ile birlikte Consensus Development’ta çalışıyordu
  • Netscape sözleşmesi kapsamında SSL 3.0 referans uygulamasını yazdı
  • Toplantıya Bruce Schneier katıldı; SSL 3 protokolünü tasarlayan Paul Kocher da muhtemelen oradaydı ve Microsoft’u Barbara Fox temsil ediyordu
• Müzakere sonucunda Microsoft ve Netscape, IETF’nin protokolü devralıp açık bir süreçle standartlaştırmasına onay verdi
  • Bu süreç, Tim Dierks’in RFC’yi editör olarak hazırlamasıyla sonuçlandı
• Standardizasyon sürecinde SSL 3.0 üzerinde bazı değişiklikler yapıldı
  • Amaç, IETF’nin Netscape protokolünü yalnızca onaylıyor gibi görünmesini engellemekti
  • Aynı nedenle protokolün adı da değiştirildi
• Böyle doğan TLS 1.0, gerçekte SSL 3.1’e daha yakın bir sürümdü

[GN⁺]

Hacker News yorumları

• Sürüm numaraları protokol farklarını iyi göstermediği için daha da kafa karıştırıyor
  SSLv2 yaygın olarak dağıtılan ilk SSL’di ama çok sorunluydu; SSLv3 ise neredeyse yeni bir protokoldü
  TLS 1.0, SSLv3’e benzer ama IETF standartlaştırma sürecinde biraz düzeltilmişti; TLS 1.1 ise blok şifrelerin kullanım biçimindeki sorunu gideren çok küçük bir revizyondu
  TLS 1.2, MD5 ve SHA-1 zayıflıklarına yanıt olarak yeni hash’ler ve AES-GCM gibi AEAD şifre takımlarını ekleyen orta ölçekli bir revizyondu; TLS 1.3 ise TLS 1.2 öncesi bazı öğeleri yeniden kullansa da büyük ölçüde yeni bir protokole yakındı
  Bu protokollerin hepsi sürümü otomatik olarak müzakere edebilecek şekilde tasarlandığından, istemci ve sunucu bağlantıyı kaybetmeden bağımsız olarak yükseltilebiliyordu

  • TLS 1.0 “uzantı” kavramıyla modülerlik getirdiği için bunu önemsiz bir evrim olarak görmek zor
    Bunlardan biri, sunucular arasında senkronize durum saklama olmadan sunucu taraflı oturum sürdürmeyi mümkün kılan session ticket’tı; bir diğeri de sunucunun birden fazla sertifika kullanabilmesini sağlayan Server Name Indication idi
  • Otomatik sürüm müzakeresi onlarca yıl boyunca çeşitli downgrade saldırılarını da mümkün kıldı
  • TLS 1.0 değil, doğrudan TLS v4.0 denmeliydi
    Sonraki sürümlerin v1.1, v1.2, v1.3 yapılması, sürüm numarasını sıfırlamanın nesnel olarak yanlış olduğunu kabul etmemeye yönelik bir inat gibi de görünüyor
  • Yine de en azından sürümlere yıl numarası vermediler

• O dönemde Microsoft bambaşka bir yaratıktı; bu yüzden SSL/TLS adlandırma karmaşası o kadar da garip gelmiyor
  O zamanların M$’ı her şeyi ele geçirmeye çalışıyordu ve açık kaynak internet teknolojilerini yavaşlatma girişimlerini 2010’ların başına kadar bile bırakmadığını düşünüyorum
  Java Applet’i öldürmeyi başardılar; JavaScript ve CSS genelinde de yıllarca geri kalınmasına neden olduklarını düşünüyorum
  2000’lerin başında şirkette IE’nin en yeni “teknolojilerini” desteklememiz için baskı vardı; ama kritik JS hatası düzeltilir düzeltilmez Mozilla 3.0’ı desteklemeye başladık ve bu sonradan iyi bir karar oldu, çünkü bir Fortune 500 şirketi Mozilla/Firefox’u yaygınlaşmasından çok önce iç uygulamalarında kullanmaya başladı

  • Java Applet’i öldürenin Microsoft olduğunu düşünmüyorum
    IE’de her zaman çalışıyordu ve bu, Microsoft’un etkileyebileceği neredeyse tek yoldu
    Applet, “Java yavaştır” sözünün başlıca örneği hâline gelerek başarısız oldu; bu genel olarak her zaman doğru olmasa da Applet için indirme beklemesi ve JVM’in başlamasını bekleme yüzünden doğruydu
    Sonunda HTML/JS, eskiden Applet gerektiren dinamik işlevleri daha iyi yapar hâle geldi; HTML’in yetmediği kalan alanları da Flash alınca Applet ortadan kayboldu
  • Applet birçok nedenle öldü
    Küçük bir animasyon için bile JRE başlama süresi akıl almaz derecede uzundu; dönemin ölçülerine göre bellek gereksinimleri ve çökmeler de ciddiydi, Java platformunun erken sürümlerindeki uyumluluk sorunları da tuhaftı
    CA sertifikası alabilen aktörlerin iyi niyetli olacağı varsayımına dayanan güvenlik modeli de gülünçtü; yalnız IE’de değil, tarayıcılar genelinde sandbox teknolojisi de olgun değildi
  • “M$” lakabının günümüze daha çok yakıştığını düşünüyorum
  • Microsoft, PR departmanının daha iyi hâle gelmesi dışında o kadar da değişmedi
  • Amazon’da https://github.com/aws/s2n-tls de vardı
    s2n’den beklenti büyüktü ama AWS dışında pek tutunamamış gibi görünüyor

• TLS ile SSL’i keskin biçimde ayıran biri bu farkı biliyor ve karşı tarafın da bilmesi gerektiğini düşünüyor demektir; ama pratikte bu .doc ile .docx farkına benziyor
  Temelde farklılar, ama sıradan kullanıcıya birbirinin yerine geçebilir gibi görünüyorlar; sahada da çoğunlukla HTTPS’in çalışıp çalışmadığıyla ilgileniliyor, iç işleyiş pek umursanmıyor

  • Sıradan kullanıcıya TLSv1.0’ın SSLv2/SSLv3’ten daha yeni ve daha iyi olduğunu anlatmak başlıca zorluktu
    Sayı daha büyükse daha iyidir diye düşünen insanlarla epey tartıştığımı hatırlıyorum
  • SSL kullanımdan kalkalı çok oldu ama insanlar şifreli ağ trafiği için hâlâ SSL adını kullanıyor
    Modern şifreli ağ trafiğinin tamamına TLS denip, sadece gerçek legacy sistemler yüzünden SSL kullanıldığında SSL denirse işler çok daha kolay olurdu

• Az önce beynimin farkında olmadan SSL ile TLS’i ayırt etmekte zorlandığını fark ettim
  20 yıl sonra bunun nedenini anlamış oldum

  • Ben de aynıyım
    Bu sektörde 15 yıl geçirdikten sonra ssl ile tls’nin aynı şey olduğunu doğru düzgün fark edince kendimi aptal gibi hissettim
  • 2010 civarında öğrendim ama ondan önce ben de bilmiyordum
    Bunu fark etmeme neden olan şey, Java’da bugün TLSv1.3 kullanırken bile şifreli bağlantı başlatmak için hâlâ SSLSocket kullanılmasıydı

• “Transport Layer Security” isim olarak daha iyi
  “TLS” demek de güzel; S harfinin iki kez art arda geldiği SSL yılan gibi duyuluyor

  • Sorun şu ki TLS zaten thread local storage kısaltması olarak yaygın biçimde kullanılıyordu
    Transport Layer Security’nin 1999’da başladığı yaygın biçimde belgelenmiş durumda; “Thread Local Storage” içinse en az 1996’ya kadar giden kaynaklar var
    O dönemde Microsoft tarafında, belki IBM/OS/2 tarafında daha yaygın bir terimdi; Pthreads ve genel Unix dünyasında ise “thread-specific data” denme eğilimi vardı
    2001 tarihli Itanium ABI belgesi bu terimi daha geniş Unix dünyasına yaymış olabilir, ama Sun da Solaris ve Java tarafında bu terimi daha önceden kullanıyormuş gibi görünüyor
  • Aksine SSL’in daha uygun bir isim olduğunu düşünüyorum
    Teoride TLS, IPSec gibi üstüne herhangi bir protokol bindirilebilen bir taşıma katmanı güvenlik mekanizması olabilir; ama pratikte neredeyse TCP socket’lerine bağlı
    UDP varyantı DTLS ya da QUIC de TLS belirtiminin parçası değil; Linux’un kernel TLS’i veya Windows’un benzer altyapısı da var, ama tek bir socket bayrağıyla TLS’i açmak kadar kolay değil
  • “SSL”de üç harf arasında dilin konumu neredeyse hiç değişmediği için “TLS”den daha kolay telaffuz ediliyor
  • En iyi isim, ilk çıkıp yerleşen isimdir

• Birine bir web sitesine güvenli şekilde bağlanması gerektiğini söylerken ya da TLS/SSL terimini kullanmanın uygun olduğu bir durumda genelde ne dendiğini merak ediyorum

  1. SSL mi deniyor, TLS mi
  2. Kaç yaşındasınız ya da 1999’dan önce çalışıyor muydunuz
  • Genelde SSL diyorum
    Uzun süre TLS’nin “aynı şey” olduğunu bile bilmiyordum; artık bilsem de 10 seferin 9’unda hâlâ SSL diyorum
    38 yaşındayım ve 2011’de çalışmaya başladım, ama ağ programlamayı ilk kez 2004~2005 civarında denemiştim
    Az önce başka bir ekrana baktım; birkaç dakika önce if deyimi eklediğim fonksiyonun adı bile sslCertNotBefore idi
    Programcıların genelde TLS ile doğrudan uğraşmaması da sorunun bir parçası gibi geliyor
    HTTPS bağlantılarından ayrıntılı sertifika bilgilerini çıkaran bir sistem yapmıştım; Java standart kütüphanesinden gereken bilgileri çekip almak epey zahmetliydi
    Otomatik olarak görünmez biçimde halledilince hata yapmak zorlaşır, ama TLS’nin gerçekte nasıl çalıştığına dair derin anlayışın yayılması açısından bu kara kutulaşma pek yardımcı olmuyor
  • Çoğu kişinin buna SSL demesinin nedeni, güvenli iletişimle ilgilenen kütüphanelerin adında SSL geçmesi gibi görünüyor
    En baskın olan OpenSSL başta olmak üzere BoringSSL, LibreSSL, wolfSSL vb. var
    Adında TLS geçen kütüphaneler arasında GnuTLS, mbedTLS, s2n-tls, RustTLS var, ama görece daha az kullanılıyorlar
  • Genelde SSL diyorum
    Daha doğru olan TLS’ye kıyasla anlaşılma olasılığı daha yüksek ve artık gerçekten SSL 3.0 kullanan kimse yok
    OpenSSL gibi klasik kütüphane adlarında da SSL geçiyor
    Yine de 1990’lardaki kripto savaşları döneminde SSL’i öğrenmiş olmamın ve düzgün SSL şifrelemesi kullanmak için “US only” Netscape sürümünü edinmek zorunda kaldığımız zamanlardan kalma bir alışkanlık da olabilir
  • Genelde “https” diyorum
    Çünkü sıradan kullanıcıların bile bunun ne anlama geldiğini bildiği durumlar olabiliyor
  • Bu aralar giderek daha çok “TLS” diyorum, ama sadece 1~2 yıl öncesine kadar neredeyse hep “SSL” derdim
    Yine de ara sıra ağzımdan SSL çıkıyor
    51 yaşındayım ve 90’ların ortasında IT işine başladım

• TLS 1.0’ın SSL 3.0’a göre epey büyük iyileştirmeler içerdiğini sanıyordum
  Yazıya bakınca, sanki sadece farklı görünmek için birkaç şeyi değiştirmişler gibi duruyor

  • Başlıca fark padding tarafında
    POODLE saldırısının yalnızca SSL3’ü etkilediği, TLS1.0’ı etkilemediği önceden açıklandığında, yalnızca bu bilgiden bile bunun bir padding oracle olacağı tahmin edilebiliyordu
    İkisi oldukça benzer; birkaç “hata düzeltmesi” içerdiğini söylemek adil olur
    Üzerinden uzun zaman geçtiği için bazı şeyleri unutmuş olabilirim; SSL3 ve TLS1.0’ı hep birlikte implemente ettiğimiz için ayrıntıları kaçırmış da olabilirim
  • Değişiklikler küçüktü; diğer tüm sürüm revizyonlarından da daha küçüktü
    Genel olarak IETF’nin SSL 3.0 protokolünü olduğu gibi onaylamayıp kendi alanını işaretlemesi gibiydi
  • Anlamlı değişiklikler ve iyileştirmeler elbette vardı, ama SSL 3.0 gibi baştan aşağı bir yeniden tasarım değildi

• İlgili bir yazı olarak Dr. Dobb's Journal’ın Ocak 1996 tarihli “Randomness and the Netscape Browser” yazısı var
  https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.ht...
  1996’da yazılmış bir metin, ama kullanılan dil bugünün yayınlarından şimdiden epey farklı hissettiriyor; insan kendini yaşlanmış hissediyor

  • Hangi yayınlara baktığınıza bağlı
    1996’da olduğu gibi, bugün LWN yazıları [1] gibi şeyler oldukça benzer bir üslupla okunuyor
    Sadece biraz daha genel okuru hedeflediği için azıcık daha az ağır olabilir
    [1] https://lwn.net/
  • O yazının yazarları bu güvenlik sorununu buldukları için New York Times’ın kapağına da çıkmıştı: https://www.nytimes.com/2012/02/15/technology/researchers-fi...

• Eric Rescorla’nın “SSL and TLS: Designing and Building Secure Systems” kitabının TLS’nin tarihini ve bugünkü noktaya nasıl gelindiğini anlamakta gerçekten faydalı olduğunu hatırlıyorum
  2001’de çıkan bir kitap; sonradan CVE olan bazı sorunlara daha o zaman dikkat çekmişti ve ikinci el birkaç dolara bulunabiliyor

• 2014 civarında SSL 2.0’ın ciddi biçimde kusurlu olduğu konusunda fikir birliğinin çok sağlam olduğunu düşünüyorum
  Handshake bile doğru dürüst doğrulanmıyordu