SSL ve TLS Sürümlerinin Tam Tarihçesi: 1994’ten Bugüne

Otuz yılı aşkın bir süredir SSL ve TLS protokolleri milyarlarca çevrimiçi işlemi korumuştur. Netscape’in 1994’teki iddialı güvenlik projesi olarak başlayan süreç, günümüzün sofistike şifreleme standartlarına dönüştü. Bu SSL geçmişi, altı ana protokol sürümünü, sayısız güvenlik iyileştirmesini ve web güvenliği hakkındaki düşüncelerimizde temel bir değişimi kapsamaktadır.

SSL/TLS sürümlerini anlamak sadece hangi protokollerin kullanımdan kaldırıldığını bilmekle ilgili değildir. Her bir güvenlik açığının, saldırının ve atılımın TLS 1.3’ün şifrelenmiş web trafiğinin %95’ini güvence altına aldığı mevcut manzarayı nasıl şekillendirdiğini anlamakla ilgilidir.

---

İçindekiler

1. Netscape’te SSL Protokolünün Doğuşu
2. SSL 3.0 – Eksiksiz Bir Protokol Yeniden Tasarımı
3. TLS 1.0 – IETF Standardizasyon Dönemi
4. TLS 1.1 ve TLS 1.2 – Artan Güvenlik Geliştirmeleri
5. TLS 1.3 – Modern Güvenlik Standardı
6. SSL/TLS Versiyonlama Hakkında Yaygın Yanlış Anlamalar
7. SSL/TLS Evriminde Sertifika Yetkililerinin Rolü
8. HTTPS’nin Benimsenmesini Şekillendiren Sektörel Kilometre Taşları
9. Protokol Evrimine Yön Veren Başlıca Güvenlik Açıkları
10. SSL/TLS Protokollerinin Geleceği

---

---

Netscape’te SSL Protokolünün Doğuşu

SSL 1.0 – Yayınlanmamış İlk Deneme (1994)

Netscape‘in baş bilim adamı Taher Elgamal, 1994 yılında orijinal Secure Sockets Layer ‘ı tasarladı. Ancak SSL 1.0 hiçbir zaman gün ışığına çıkamadı. Netscape’teki güvenlik araştırmacıları, halka açık sürümden önce kritik kusurlar keşfetti; bu kusurlar, tüm sürümü hurdaya çıkaracak kadar ciddiydi.

Çıkarılacak ders açıktı: kriptografik protokoller uygulamaya konulmadan önce kapsamlı bir incelemeden geçirilmelidir. Bu aksilik sinir bozucu olsa da, gelecekteki SSL ve TLS gelişimini tanımlayacak titiz bir test modeli oluşturdu.

SSL 2.0 – İlk Halka Açık Sürüm (1995)

SSL ne zaman çıktı? Cevap, Netscape’in SSL 2.0 ‘ı Navigator 1.1 ile birlikte sunduğu Şubat 1995‘tir. Bu SSL sürümü bugün hala kullanılan temel kavramları tanıttı: SSL el sıkışması süreci, X.509 dijital sertifikaları ve sunucu kimlik doğrulaması.

Ancak SSL 2.0’ın sorunları vardı. Mesaj kimlik doğrulaması için MD5 ‘e dayanıyor, şifreleme ve kimlik doğrulama için aynı anahtarı kullanıyor ve el sıkışmanın kendisi için koruma sağlamıyordu. Saldırganlar her iki taraf da fark etmeden bağlantıları daha zayıf 40 bit şifrelemeye düşürebiliyordu.

IETF, Mart 2011′ de RFC 6176 aracılığıyla SSL 2.0’ı resmi olarak kullanımdan kaldırdı. O zamana kadar çoğu sunucu çoktan yoluna devam etmişti.

---

SSL 3.0 – Eksiksiz Bir Protokol Yeniden Tasarımı

SSL 2.0’a (1996) Göre Önemli İyileştirmeler

Paul Kocher, Phil Karlton ve Alan Freier, Kasım 1996‘da yayınlanan 3.0 sürümü için SSL protokolünü tamamen yeniden yazdılar. Veri taşıma katmanını mesaj katmanından ayırdılar, Diffie-Hellman anahtar değişimi ve Fortezza şifre paketleri için destek eklediler ve uygun 128 bit anahtarlama uyguladılar.

SSL 3.0 ayrıca kayıt sıkıştırma ve daha esnek bir şifre paketi anlaşması da getirmiştir. IETF daha sonra bunu RFC 6101’de belgeleyerek tarihsel önemini kabul etti. Yaklaşık yirmi yıl boyunca, SSL 3.0 eski sistemler için bir yedek seçenek olarak hizmet verdi.

POODLE Güvenlik Açığı ve SSL 3.0’ın Kullanımdan Kaldırılması

Ekim 2014‘te Google’ın güvenlik ekibi şunları keşfetti POODLE (Padding Oracle on Downgraded Legacy Encryption). Saldırı, SSL 3.0’ın şifre blok zincirleme (CBC) modu dolgusunu nasıl işlediğinden faydalanıyordu. Saldırganlar, tarayıcıları TLS’den SSL 3.0’a düşürmeye zorlayarak güvenli HTTP çerezlerinin şifresini çözebiliyordu.

IETF hızlı bir şekilde yanıt vererek Haziran 2015 ‘te RFC 7568 aracılığıyla SSL 3.0’ı kullanımdan kaldırdı. Bu SSL döneminin sonunu işaret ediyordu. İnsanlar“en son SSL sürümünü” sorduklarında cevap SSL 3.0 oluyor, çünkü SSL’in kendisi bir daha hiç güncellenmedi. Meşale Aktarım Katmanı Güvenliği.

---

TLS 1.0 – IETF Standardizasyon Dönemi

SSL’den TLS’ye Geçiş (1999)

1990’ların sonunda IETF internet güvenlik protokollerini standartlaştırmak istedi. Tim Dierks ve Christopher Allen SSL’i açık bir standarda dönüştürme çabalarına öncülük etti. Microsoft ve Netscape isimlendirme konusunda uzlaşmaya vardılar -TransportLayer Security (Aktarım Katmanı Güvenliği ) bu uzlaşmanın bir parçası oldu.

Ocak 1999‘da RFC 2246 olarak yayınlanan TLS 1.0, aslında SSL 3.1’in yeni bir isimle ifade edilmiş haliydi. Farklılıklar küçüktü ancak uyumluluğu bozacak kadar anlamlıydı. Dikkatli bir uygulama olmadan SSL 3.0 istemcilerini TLS 1.0 sunucularıyla karıştıramazdınız.

SSL 3.0’dan Temel Farklılıklar

TLS 1.0 altta yatan kriptografiyi yükseltmiştir. SSL’in özel mesaj kimlik doğrulama kodunu (MAC) kriptograflar tarafından standartlaştırılan HMAC ile değiştirdi. Bazı teorik saldırıları önlemek için anahtar türetme işlevi değişti. Uyarı sistemi daha spesifik hata kodlarıyla genişletildi.

TLS 1.0 ayrıca DSS/DH şifre takımları için destek gerektirerek uygulamalara daha fazla esneklik kazandırdı. Bu değişiklikler küçük gibi görünse de, tescilli geliştirmeden topluluk güdümlü standardizasyona geçişi yansıtıyordu. IETF artık protokolün gelişimini kontrol ediyordu.

---

TLS 1.1 ve TLS 1.2 – Artan Güvenlik Geliştirmeleri

TLS 1.1 CBC Saldırılarına Karşı Koruma (2006)

Nisan 2006′ da RFC 4346 aracılığıyla yayınlanan TLS 1.1, belirli CBC güvenlik açıklarını ele aldı. En büyük değişiklik? Örtük IV’lerin yerini açık başlatma vektörleri (IV’ler) aldı. Bu, saldırganların IV’ü tahmin etmesini ve şifre blok zincirlemesini istismar etmesini engelledi.

TLS 1.1 ayrıca dolgulu kayıtlar için hata işlemeyi de geliştirdi. Belirli dolgu hatalarını ortaya çıkarmak yerine, genel bir bad_record_mac uyarısı döndürdü. Bu değişiklikler, yıllar sonra 2011’de keşfedilen BEAST ‘e (Browser Exploit Against SSL/TLS) karşı koruma sağladı.

IANA parametre kayıtları oluşturularak şifre paketi yönetimi daha düzenli hale getirildi. Ancak benimsenmesi yavaş oldu. Birçok kuruluş TLS 1.1’i tamamen atlayarak TLS 1.2‘nin daha önemli iyileştirmelerini bekledi.

TLS 1.2 Geliştirilmiş Esneklik (2008)

TLS 1.2 ne zaman yayınlandı? Ağustos 2008, RFC 5246 aracılığıyla. Bu güncelleme SSL 3.0’dan bu yana en önemli değişiklikleri getirdi. Protokol, sabit kodlanmış MD5/SHA-1 kombinasyonlarından şifre-suite tarafından belirlenen sözde rastgele fonksiyonlara (PRF’ler) geçmiştir. SHA-256 yeni standart haline geldi.

TLS 1.2, AES-GCM ve ChaCha20-Poly1305 dahil olmak üzere ek veri ( AEAD ) şifre modları ile kimliği doğrulanmış şifrelemeyi tanıttı. Hash ve imza algoritmalarının seçiminde uygulamalara esneklik sağladı. Kriptografik standartlar geliştikçe bu uyarlanabilirliğin çok önemli olduğu kanıtlandı.

Protokol günümüzde yaygın olarak kullanılmaya devam etmektedir. Web sitelerinin yaklaşık %95,8’i hala TLS 1.2’yi desteklemekte ve genellikle TLS 1 .3 ile birlikte çalışmaktadır. Mart 2021‘de IETF, RFC 8996 aracılığıyla TLS 1.0 ve 1.1’i ortaklaşa kullanımdan kaldırarak TLS 1.2’yi kabul edilebilir minimum standart haline getirdi.

---

---

TLS 1.3 – Modern Güvenlik Standardı

Geliştirme Aşamasında Beş Yıl (2018)

TLS 1.3 ‘ün gelmesi on yıl sürdü. IETF, 28 taslak ve kapsamlı işbirliğinin ardından Ağustos 2018 ‘de RFC 8446’yı yayınladı. Basitlik ve performans yeniden tasarıma yön verdi. Çalışma grubu eski özellikleri kaldırdı, el sıkışmayı basitleştirdi ve tüm güvenlik açığı sınıflarını ortadan kaldırdı.

Google, Mozilla, Microsoft ve Apple hızlı bir şekilde destek ekledi. 2019 yılına gelindiğinde tüm büyük tarayıcılar TLS 1.3 bağlantıları için pazarlık yapabiliyordu. Cloudflare ve diğer CDN sağlayıcıları bunu varsayılan olarak etkinleştirdi. En son TLS sürümü yalnızca güvenliği artırmakla kalmadı, şifreli bağlantıları daha hızlı hale getirdi.

Devrim Niteliğinde Güvenlik İyileştirmeleri

TLS 1.3 kırılan veya zayıflatılan her şeyi kaldırdı. SHA-1, MD5, RC4, DES ve 3DES şifre paketleri? Gitti. Statik RSA ve Diffie-Hellman anahtar değişimi? Ortadan kaldırıldı. Protokol artık şunları gerektiriyor mükemmel ileri gizlilik tüm bağlantılar için geçici Diffie-Hellman kullanarak.

El sıkışma temelden değişti. ServerHello’dan sonraki her mesaj şifrelenerek anlaşmanın meraklı gözlerden gizlenmesi sağlandı. Anahtar türetme işlevi HMAC tabanlı Extract-and-Expand (HKDF) olarak değiştirilerek daha iyi kriptografik garantiler sağlandı.

TLS 1.3 ayrıca 0-RTT (sıfır gidiş-dönüş süresi) modunu da getirmiştir. İstemciler ilk mesajda şifrelenmiş verileri daha önce iletişime geçilen sunuculara gönderebilir ve el sıkışma gecikmesini ortadan kaldırır. Basitleştirilmiş durum makinesi, uygulamaların hataya daha az eğilimli olmasını sağladı. ECC, RSA-PSS gibi yeni imza algoritmalarıyla birlikte temel spesifikasyona taşındı.

Mevcut Benimseme ve Birlikte Varoluş

En son TLS sürümü nedir? TLS 1.3 bu unvanı elinde tutuyor. Ancak TLS 1.2 yakın zamanda hiçbir yere gitmiyor. Kuruluşların sunucuları yükseltmek, uyumluluğu test etmek ve istemci yazılımını güncellemek için zamana ihtiyacı var. Güvenlik bilincine sahip çoğu site artık her ikisini de destekliyor ve istemcilerin mevcut en iyi seçeneği seçmesine izin veriyor.

Birlikte var olma iyi çalışır. Sunucular karşılıklı olarak desteklenen en yüksek sürüm üzerinde anlaşırlar. TLS 1.3 ile başa çıkamayan istemciler TLS 1.2’ye geri dönerler. Bu kademeli geçiş yaklaşımı, daha önceki geçişlerde yaşanan uyumluluk felaketlerini önler.

---

SSL/TLS Versiyonlama Hakkında Yaygın Yanlış Anlamalar

Neden TLS 2.0 Yok

TLS 2.0’ın çıkış tarihi nedir? Öyle bir şey yok. TLS 2.0 mevcut değildir ve asla da olmayacaktır. IETF aşamalı versiyonlama kullanır: TLS 1.0, 1.1, 1.2, 1.3. Bir sonraki sürüm, eğer gelirse, TLS 1.4 veya muhtemelen TLS 2.0 olacaktır, ancak SSL 3.0’dan sonra doğrudan “TLS 2.0 “a atlamak büyük bir karışıklığa neden olurdu.

İnsanlar genellikle protokollerin büyük sürüm numaraları kullanmasını bekler (sürüm 1’den sürüm 2’ye atlayan yazılımlar gibi). Ancak kriptografik protokoller daha muhafazakar bir şekilde gelişir ve her sürüm bir öncekinin üzerine inşa edilir.

SSL ve TLS Terminolojisi

“SSL sertifikası” istediğinizde TLS 1.2 ve TLS 1.3 ile çalışan bir sertifika alırsınız. Sektör hala pazarlamada “SSL” kelimesini kullanıyor çünkü tanıdık geliyor. Mevcut SSL sürümü teknik olarak mevcut olmasa da (SSL 3.0 sürümünde sona ermiştir), bu terim kalıcı olmuştur.

DigiCert ve Sectigo gibi sertifika yetkilileri yalnızca TLS protokollerini kullanan “SSL sertifikaları” satmaktadır. Kafa karıştırıcı ama zararsız. Unutmayın: 2026’da biri SSL’den bahsettiğinde, neredeyse kesinlikle TLS’yi kastediyordur.

---

SSL/TLS Evriminde Sertifika Yetkililerinin Rolü

Doğrulama Türleri Geliştirme

İlk SSL sertifikaları pahalı ve yavaştı. İşletme Doğrulaması günler ya da haftalar süren manuel doğrulama gerektiriyordu. GeoTrust 2002 yılında Etki Alanı Doğrulamasıe-posta veya DNS kayıtları aracılığıyla alan adı sahipliğini doğrulayarak süreci otomatikleştirmek.

Genişletilmiş Doğrul ama sertifikaları 2007 yılında ortaya çıktı ve tarayıcılarda yeşil adres çubuklarıyla en yüksek güvenceyi vaat etti. Let’s Encrypt 2015‘te piyasaya sürüldü ve otomatik yayınlama yoluyla ücretsiz Alan Doğrulama sertifikaları sundu. Cloudflare kendi ücretsiz sertifika programıyla bunu takip etti. Bu değişiklikler demokratikleşti HTTPSşifrelemeyi küçük web siteleri için erişilebilir hale getiriyor.

Sertifika Geçerlilik Süresi Azaltımı

Sertifika geçerlilik süreleri daralmaya devam etti. Temel gereklilikler 2015 yılında azami geçerlilik süresini beş yıldan üç yıla düşürmüştür. İki yıl 2018’de sınır haline geldi. Apple’ın Safari’si 2020’de bir yıllık maksimum süreyi zorunlu kıldı ve diğer tarayıcıları da bunu takip etmeye zorladı.

Şimdi endüstri daha da kısa sertifika yaşam döngülerine doğru ilerliyor. CA/Browser Forum sertifika geçerlilik sürelerinde net bir azalma tanımladı: 15 Mart 2026‘dan itibaren 200 gün,15 Mart 2027’den itibaren 100 gün ve 15 Mart 2029’a kadar sadece 47 gün.

Bu değişim, manuel sertifika yönetimini kullanışsız hale getirerek kurumları doğrulama, düzenleme ve yenilemenin otomatik olarak gerçekleştirildiği ACME tabanlı Hizmet Olarak Sertifika (CaaS) gibi otomatik çözümlere doğru itmektedir.

---

HTTPS’nin Benimsenmesini Şekillendiren Sektörel Kilometre Taşları

Google’ın HTTPS Zorlaması

Ağustos 2014′te Google HTTPS’yi bir sıralama sinyali olarak duyurdu. Bu tek karar SSL tarihini değiştirdi. Şifrelemeyi görmezden gelen web yöneticilerinin birdenbire önemsemeleri için iş nedenleri oldu. 2016 yılına gelindiğinde, tüm web trafiğinin yarısı şifrelenmişti.

Chrome 68, Temmuz 2018‘de bir sonraki adımı atarak tüm HTTP sitelerini “Güvenli Değil.” Bu uyarı, şifrelenmemiş her sayfa için adres çubuğunda beliriyordu. Bugün web trafiğinin %95 ‘inden fazlası HTTPS kullanıyor. Google, şifrelemeyi en iyi güvenlik uygulamasından bir iş gerekliliğine dönüştürdü.

Tarayıcı Güvenlik Göstergeleri Evrimi

Genişletilmiş Doğrulama’nın yeşil adres çubuğunu hatırlıyor musunuz? O artık yok. Chrome, araştırmaların kullanıcıların bunu fark etmediğini veya anlamadığını göstermesinin ardından 2020’de kaldırdı. Asma kilit simgesinin kendisi de kayboluyor ve yerini HTTPS’yi ödüllendirmek yerine normalleştiren nötr göstergelere bırakıyor.

Chrome 69 “Güvenli” metnini kaldırarak sadece asma kilidi bıraktı. Mevcut tarayıcılar güvenli bağlantıları övmek yerine güvensiz bağlantılar hakkında uyarı vermeye odaklanıyor. Mesaj: HTTPS varsayılan beklentidir, özel bir şey değildir.

---

Protokol Evrimine Yön Veren Başlıca Güvenlik Açıkları

SSL/TLS’ye Yönelik Önemli Saldırılar

POODLE, 2014 yılında SSL 3.0’ı vurarak CBC modundaki dolgu oracle güvenlik açıklarından yararlandı. Saldırganlar, bağlantıları düşürerek ve şifreli metni tekrar tekrar değiştirerek güvenli çerezlerin şifresini çözebiliyordu. Saldırı SSL 3.0’ı aylar içinde öldürdü.

BEAST, 2011 yılında benzer bir CBC zayıflığı kullanarak TLS 1.0’ı hedef almıştır. Saldırganlar, istemci tarafı kodu enjekte ederek ve şifrelenmiş yanıtları gözlemleyerek HTTPS çerezlerinin şifresini çözebiliyordu. Düzeltme, TLS 1.1’de açık IV’lerin uygulanmasını gerektiriyordu.

BREACH 2013 yılında HTTP sıkıştırmasını kötüye kullandı. Saldırı TLS protokolünün kendisini hedef almadı ancak uygulama katmanı kararlarının güvenliği nasıl etkilediğini gösterdi. Heartbleed, 2014 yılında keşfedildi ve kritik bir OpenSSL özel anahtarları ve kullanıcı verilerini sızdıran uygulama hatası.

Çıkarılan Dersler

Her güvenlik açığı aynı noktayı kanıtladı: geriye dönük uyumluluk tehlikelidir. Eski sistemler için eski protokolleri canlı tutmak saldırı vektörleri yaratır. Sektör agresif bir şekilde kullanımdan kaldırmayı ve yükseltmeleri zorlamayı öğrendi.

Güvenlik araştırmacıları da övgüyü hak ediyor. Güvenlik açıklarının kamuya açıklanması iyileştirmeleri hızlandırdı. POODLE olmasaydı, SSL 3.0 bugün hala sunucu yapılandırmalarında gizleniyor olabilirdi.

---

SSL/TLS Protokollerinin Geleceği

Kuantum Sonrası Kriptografi

Kuantum bilgisayarlar mevcut şifreleme algoritmalarını tehdit ediyor. Kuantum makineleri yeterli ölçeğe ulaştığında RSA ve eliptik eğri kriptografisi geçersiz hale gelebilir. NIST, kuantum saldırılarına karşı koymak için tasarlanmış kuantum sonrası algoritmaları standartlaştırıyor.

TLS’nin kuantuma dayanıklı bu algoritmaları desteklemek için güncellemelere ihtiyacı olacaktır. Kuantum sonrası kriptografi daha büyük anahtarlar ve farklı matematiksel yaklaşımlar kullandığından geçiş kolay olmayacaktır. Ancak bizi SSL 2.0’dan TLS 1.3’e getiren protokol evrimi, topluluğun büyük geçişlerin üstesinden gelebileceğini kanıtladı.

Gelişen Teknolojiler

DTLS (Datagram Transport Layer Security) TLS’yi UDP bağlantılarına genişletir. QUICGoogle tarafından geliştirilen ve IETF tarafından standartlaştırılan TLS, şifrelemeyi doğrudan taşıma katmanına entegre eder. Bu protokoller, farklı kullanım durumlarına uyum sağlarken TLS’nin kriptografik temelleri üzerine inşa edilmiştir.

Remme gibi blok zinciri tabanlı alternatifler dağıtılmış PKI ile denemeler yapıyor. Sertifika yetkilileri gelişmeye devam ediyor, daha fazla süreci otomatikleştiriyor ve daha kısa geçerlilik sürelerini destekliyor. TLS 1.3’ten sonra ne olacak? Muhtemelen tam bir yeniden tasarım yerine aşamalı iyileştirmeler. TLS 1.3 çoğu şeyi doğru yaptı.

---

SSL Dragon’un TLS 1.3’e Hazır Sertifikaları ile Güncel Kalın

Protokol evrimini anlamak bir şeydir. Modern şifreleme standartlarını uygulamak başka bir şeydir. SSL Dragon, TLS 1.3 ve TLS 1.2 ile tam uyumlu dijital sertifikalar sunarak en yeni şifreleme protokollerini ve şifre takımlarını destekler.

DigiCert, Sectigo ve GeoTrust gibi önde gelen sertifika yetkilileriyle yaptığımız ortaklıklar sayesinde hızlı sertifika verme, güçlü şifreleme ve %99,99 tarayıcı güveni sunuyoruz. Otomatik sertifika yönetimi çözümlerimiz, manuel yenileme güçlükleri olmadan yaklaşan 47 günlük yaşam döngülerinin üstesinden gelmenize yardımcı olur.

Kullanımdan kaldırılan protokollerden geçiş mi yapıyorsunuz? Özel destek ekibimiz geçiş sürecinde size rehberlik eder. Her satın alma 25 günlük para iade garantisi içerir. Sertifika portföyümüzü keşfedin ve altyapınızı en son TLS sürümü ile güvence altına alın.