SSL/TLS güvenlik güncellemeleri neden kritik?
Bir güvenlik denetimi toplantısında masaya oturduğunuzu düşünün: Pazarlama ekibi tarayıcıdaki “Güvenli değil” uyarılarından şikâyet ediyor, yazılım ekibi uyumluluk için hangi TLS sürümlerini kapatması gerektiğini soruyor, finans tarafı ise PCI DSS gibi güvenlik standartlarının baskısını hatırlatıyor. Konu dönüp dolaşıp aynı yere geliyor: SSL/TLS güvenlik güncellemeleri düzgün yönetilmiyorsa, hem güvenlik hem de iş tarafı risk altında.
SSL/TLS, istemci (tarayıcı, mobil uygulama, API istemcisi) ile sunucu arasındaki trafiği şifreleyen katman. Fakat bu mekanizma statik bir yapı değil; yıllar içinde yeni protokol sürümleri, şifre algoritmaları ve sertifika kuralları devreye giriyor, eskileri ise kullanımdan kalkıyor. Bu nedenle “Bir kere kurduk, bitti” yaklaşımı, günümüzde ciddi bir saldırı yüzeyi oluşturuyor.
SSL/TLS tarafında sadece sertifika süresi dolduğunda harekete geçmek yeterli değildir. Riskler, sertifikanın yanı sıra protokol sürümleri ve şifre takımlarından da kaynaklanabilir; yanlış yapılandırılmış HTTP güvenlik başlıkları da web güvenliğini etkiler. Bu yazıda, siteniz ve API’leriniz için SSL/TLS güvenlik güncellemelerini nasıl planlayabileceğinizi örnek senaryolar üzerinden ele alacağız.
Protokol sürümleri: TLS 1.0’dan TLS 1.3’e geçişin arka planı
Önce en temel katmandan başlayalım: Kullandığınız TLS sürümleri. TLS 1.0, TLS 1.1 veya SSLv3 hâlâ açıksa, bunları devreden çıkarmayı planlamalısınız. “Çalışıyor, ellemesek mi?” sorusunun cevabı artık çok net: Hayır, ellemeden olmaz.
Eski sürümler neden güvenli değil?
SSLv3, TLS 1.0 ve TLS 1.1 artık kullanılmamalıdır; ancak bilinen saldırılar bu sürümlerin tümünü aynı şekilde etkilemez. POODLE, SSLv3’ün CBC kullanımını; BEAST, SSLv3 ve TLS 1.0’ın CBC kullanımını hedefler. Lucky13 ise CBC uygulamalarına bağlıdır ve TLS 1.2’yi de etkileyebilir. Ayrıca SSLv3, TLS 1.0 ve TLS 1.1, AES-GCM veya ChaCha20-Poly1305 gibi modern AEAD şifre takımlarını desteklemez. Tarayıcı üreticileri ve uyumluluk standartları bu yüzden yıllardır aynı mesajı veriyor: Bu sürümler kapatılmalı.
- PCI DSS uyumluluğu için TLS 1.0’a güvenmeyin; geçerli standart sürümünün güçlü kriptografi gereksinimlerini, kapsamını ve istisnalarını değerlendirin.
- Modern tarayıcılar SSLv3 ve çoğu zaman TLS 1.0/1.1 desteğini zaten devre dışı bırakmış durumda.
- Birçok güvenlik tarama aracı, TLS 1.0/1.1 açık olan sunucuları doğrudan “zayıf yapılandırma” olarak işaretliyor.
Pratik tavsiye: Asgari sürüm TLS 1.2, idealde 1.2 + 1.3
Güncel bir web projesi için asgari seviyede TLS 1.2 ve mümkünse TLS 1.3 desteğini öneriyoruz. TLS 1.3’ün hız ve güvenlik avantajlarını daha önce detaylı olarak TLS 1.3 standartlarındaki güncellemeler ve sunucu tarafına etkileri yazımızda ele almıştık. Özetle:
- TLS 1.3 daha az el sıkışma (handshake) turu ile daha hızlı bağlantı kurulumu sağlar.
- Eski ve zayıf şifre takımlarını protokol seviyesinde tamamen dışarıda bırakır.
- 0-RTT, yeniden bağlantılarda gecikmeyi azaltabilir; ancak erken veri tekrar oynatma (replay) riski taşır. Ödeme veya veri değiştiren işlemler gibi tekrarlandığında yan etki doğuran isteklerde kullanılmamalıdır.
Yapılandırma tarafında genel strateji:
- SSLv3, TLS 1.0 ve TLS 1.1’i tamamen kapatın.
- Varsayılan olarak TLS 1.2 ve 1.3’ü açık tutun.
- Çok özel, eski istemci (legacy) bağımlılığınız varsa, geçiş süresince ayrı bir uç noktada ağ ve erişim kontrolleriyle sınırlandırın ve kaldırma tarihi belirleyin. Yalnızca farklı bir alt alan adı kullanmak güvenlik izolasyonu sağlamaz.
HTTP/2 ve HTTP/3 ile uyumluluk
HTTP/2 ve HTTP/3 (QUIC), modern tarayıcı performansı için kritik. Ancak bu protokoller, eski veya zayıf TLS yapılandırmalarıyla iyi çalışmıyor, hatta çoğu zaman hiç çalışmıyor. Örneğin TLS üzerinden HTTP/2 kullanımında bazı zayıf şifre takımları kısıtlanır; istemci veya sunucu bu takımlarla kurulan bağlantıyı reddedebilir. HTTP/3 için de TLS 1.3 zorunlu.
Eğer HTTP/3’ü devreye almayı planlıyorsanız, öncesinde TLS tarafını düzeltmek şart. Bu konuda HTTP/3 protokolünün web hosting performansına etkilerini anlattığımız rehber, TLS ve protokol ilişkisini anlamak için iyi bir tamamlayıcı olacaktır.
Şifre takımları (cipher suites) ve anahtar türleri
Protokol sürümlerini güncelledikten sonra sırada şifre takımları (cipher suites) var. Kontrol edilmesi gereken olası sorunlar şöyle:
- RC4, 3DES gibi eski algoritmalar hâlâ açık.
- Forward secrecy (PFS) sağlamayan şifreler kullanılmaya devam ediyor.
- Statik RSA anahtar değişimi ile ECDHE_RSA veya ECDHE_ECDSA gibi seçenekler birbirine karıştırılıyor. RSA/ECDSA burada kimlik doğrulamayla, ECDHE ise geçici anahtar değişimiyle ilgilidir; birlikte listelenmeleri tek başına bir güvenlik sorunu değildir.
Bağlantı kurulabilse bile, zayıf şifre takımlarının açık kalması saldırı yüzeyini genişletebilir ve güvenlik taramalarında bulgu oluşturabilir.
Öncelik: AEAD ve Forward Secrecy
Modern TLS yapılandırmalarında temel prensip:
- AEAD tabanlı şifreler kullanmak (AES-GCM, ChaCha20-Poly1305 gibi).
- Forward secrecy sağlayan ECDHE tabanlı anahtar değişimini zorunlu kılmak.
Örneğin TLS 1.2 tarafında şu tarz şifreler önceliklendirilir:
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS 1.3’te eski ve zayıf şifre takımları kaldırılmıştır; bu, yönetimi kolaylaştırır. Ancak kullanılacak TLS 1.3 takımları yine yapılandırılabilir. Nginx’te bunlar TLS 1.2 için kullanılan ssl_ciphers ayarından ayrı yönetilir.
RSA mı, ECDSA mı? Yoksa ikisi birden mi?
Günümüzde tarayıcı ve işletim sistemi desteği düşünüldüğünde, çoğu senaryo için RSA 2048+ hâlâ uyumlu bir seçenek. Ancak ECDSA sertifikalar performans açısından avantaj sağlayabilir:
- Benzer güvenlik düzeyinde daha küçük anahtar ve imzalar, el sıkışmada aktarılan veriyi azaltabilir; toplam boyut sertifika zincirine de bağlıdır.
- Sunucudaki imzalama işlemi daha düşük CPU maliyeti sağlayabilir; toplam kazanç donanım, TLS kütüphanesi ve bağlantı yüküne bağlıdır.
Peki seçim nasıl yapılmalı? Birçok projede en pratik yaklaşım, Nginx/Apache’de ECDSA + RSA ikili SSL kullanarak hem uyumluluk hem hız elde etmektir. Yani sunucu her iki sertifika türüyle yapılandırılır ve bağlantıda istemcinin yeteneklerine uygun sertifikayı seçer. Bu yaklaşım uyumluluğu genişletebilir; ancak eski cihazların sertifika zinciri ve TLS desteği ayrıca değerlendirilmelidir.
Kapatmanız gereken şifreler
Genel bir kontrol listesi olarak, aşağıdaki şifre ve algoritmaları devre dışı bırakmanız gerekir:
- RC4 tabanlı tüm şifreler
- 3DES (Triple-DES) tabanlı şifreler
- CBC modlu, özellikle de SSLv3/TLS 1.0 ile birlikte kullanılan şifreler
- Anonim veya export-grade (EXPORT) anahtar değişimi içeren şifreler
Birçok modern rehberde önerilen, “yalnızca güçlü şifreleri açık bırak, geri kalanını tamamen kapat” yaklaşımıdır. Karışık listeler yerine, gerçekten ihtiyacınız olan birkaç güçlü şifre takımına odaklanmak yönetimi kolaylaştırır.
Sertifika tarafındaki güncellemeler
SSL/TLS güvenliğinin bir diğer ayağı da sertifikalar ve sertifika otoriteleri (CA). Burada da son yıllarda önemli değişiklikler oldu ve olmaya devam ediyor.
SHA-1’den SHA-256’ya, RSA’da 1024 bit’ten 2048+’a
Bir dönem yaygın olan SHA-1 imzalı ve 1024 bit RSA anahtarlı sertifikalar artık modern tarayıcılar tarafından kabul edilmiyor veya uyarı ile gösteriliyor. Güncel durumda:
- Sertifika imzalarında SHA-256 gibi güvenli bir SHA-2 özet algoritması kullanılmalı.
- RSA anahtar uzunluğu en az 2048 bit olmalı (gereksinimlere göre 3072 bit de seçilebilir).
- ECDSA için P-256 veya P-384 gibi yaygın desteklenen eğriler tercih edilebilir.
Bu noktada “Benim sertifikam yeni, otomatik zaten böyle” diye düşünmek kolay, ancak özellikle özel CA kullanan iç ağ sistemlerinde (intranet, internal API vb.) eski algoritmalarla imzalanmış sertifikalar kalmış olabilir. Bu sertifikalar iç sistemlerde de güvenlik riski oluşturabilir.
Sertifika süreleri kısalıyor: Daha kısa geçerlilik, daha sık yenileme
Eskiden 3 yıla kadar sertifika alınabiliyordu; daha sonra genel güvenilen TLS sunucu sertifikalarında üst sınır 398 güne indirildi. Bu tarihsel sınır güncel üst sınır olarak alınmamalıdır; yeni sertifikalar için geçerli süre, düzenleme tarihindeki CA/B Forum ve tarayıcı kurallarına bağlıdır. 90 gün veya daha kısa geçerlilik süreleri de yenileme planında dikkate alınmalıdır. Daha kısa sürelerin gerekçeleri şöyle:
- Özel anahtar sızarsa, kısa geçerlilik süresi o sertifikanın kötüye kullanılabileceği süreyi sınırlar; ancak sızan anahtar yenilemede tekrar kullanılmamalıdır.
- CA politikalarındaki değişiklikler daha hızlı hayata geçer.
Süreler kısaldıkça manuel sertifika yönetimi zorlaşır. Bu nedenle ACME tabanlı otomatik SSL yönetimi ve sertifika yenileme süreçlerini merkezî olarak planlamak yararlıdır. Bu konunun organizasyonel tarafını, SSL sertifika güvenlik güncellemelerinin neden hep son dakikaya kaldığını ve nasıl planlanması gerektiğini anlattığımız yazıda detaylandırdık.
CAA kayıtları, OCSP Stapling ve revokasyon süreçleri
Sertifika tarafındaki daha “ince” güvenlik güncellemeleri ise genelde gözden kaçıyor:
- CAA kayıtları ile hangi CA’ların alan adınız için sertifika üretebileceğini sınırlamalısınız. Böylece yetkisiz CA’lerden sertifika alınması riskini azaltırsınız.
- OCSP Stapling, CA’nız ve sertifikanız OCSP destekliyorsa, istemcinin CA’ya doğrudan sorgu göndermeden iptal durumunu kontrol etmesine yardımcı olabilir. Let’s Encrypt, OCSP hizmetini 6 Ağustos 2025’te kapattı ve iptal bilgisini artık yalnızca CRL üzerinden yayımlıyor; bu CA’nın güncel sertifikalarında OCSP Stapling kullanılamaz.
- Özel anahtar sızıntısı gibi durumlar için, sertifikayı iptal etme, yeni bir özel anahtar üretme ve bu anahtarla yeni sertifika alıp devreye alma sürecini önceden planlamak gerekir.
OCSP Stapling ve HSTS gibi modern mekanizmaları web sunucusu tarafında nasıl devreye alacağınızı, Nginx/Apache’de TLS 1.3, OCSP Stapling ve HSTS Preload kurulumu rehberimizde adım adım anlattık. Buradaki yapılandırmaları, kendi ortamınıza uyarlarken referans alabilirsiniz.
Operasyonel bakış
Teknik konular kadar önemli olan diğer boyut, güncelleme sürecini nasıl yönettiğiniz. SSL/TLS tarafı için net bir sorumlu belirlemek ve periyodik bir kontrol listesi oluşturmak, bu sürecin temel adımlarıdır.
Yıllık değil, periyodik ve ölçülebilir kontroller
Eski yaklaşım şuydu: “Sertifikalar senede bir yenilenir, biter.” Günümüzde ise şunları yapmanız gerekiyor:
- 3-6 ayda bir SSL/TLS yapılandırma taraması (automated scan) çalıştırmak.
- Hangi TLS sürümleri ve şifre takımları açık, raporlamak.
- Tarayıcı ve kütüphane (OpenSSL, Node.js, Java) güncellemelerini takip ederek geriden gelmemek.
Bu kontrolleri manuel yapmak yerine, CI/CD sürecinize entegre etmek en sağlıklısı. Örneğin staging ortamına yeni bir Nginx/Apache yapılandırması deploy edildiğinde, otomatik olarak TLS testleri çalıştırılabilir.
Staging → Canlı yolculuğu: Test etmeden TLS güncellemesi yapılmaz
SSL/TLS güncellemeleri bazen beklenmedik uyumluluk sorunlarına yol açabilir. Özellikle:
- Eski Android cihazlar
- Eski masaüstü tarayıcılar
- Eski Java veya .NET kütüphaneleri kullanan entegrasyonlar
Bu nedenle, TLS yapılandırmasını doğrudan canlıya taşımak yerine, staging ortamında test etmek ve logları incelemek kritik. Zaten WordPress/Laravel gibi uygulamalar için geliştirme–staging–canlı yolculuğunu doğru kurduğunuzda, TLS değişikliklerini de aynı disiplin içinde yönetebiliyorsunuz.
Konfigürasyon yönetimi: Kopyala-yapıştır değil, versiyonlanmış yapı
En tehlikeli senaryolardan biri, “Geçen sene şu sunucuda işe yaramıştı” diyerek eski bir Nginx/Apache yapılandırmasını yeni sunucuya kopyalamak. Böylece eski zayıf şifreler, kapatmayı unuttuğunuz TLS sürümleri yıllarca yeni ortamlara taşınmaya devam ediyor.
Önerdiğimiz yaklaşım:
- Tüm TLS yapılandırmalarını versiyon kontrolüne (Git vb.) alın; özel anahtarları ve erişim sırlarını depoya koymayın, ayrı bir sır yönetimi mekanizmasında tutun.
- Her değişikliği code review sürecine sokun; özellikle şifre takımı/TLS sürümü açma–kapama değişikliklerini kayıt altına alın.
- CI/CD pipeline içinde basit TLS testleri (minimum protokol, sertifika süresi, hostname doğrulaması vb.) koşturun.
HTTP güvenlik başlıkları ile birlikte düşünün
Salt TLS güncellemesi çoğu zaman yetmez; HTTP güvenlik başlıkları ile beraber ele almak gerekir. Örneğin:
- HSTS (Strict-Transport-Security) ile, politikayı öğrenmiş tarayıcılara geçerlilik süresi boyunca sitenize yalnızca HTTPS üzerinden bağlanmalarını söylersiniz. Preload yoksa ilk bağlantı henüz bu politikayla korunmayabilir.
- Content-Security-Policy (CSP) ile XSS gibi saldırılara karşı ek katman eklersiniz.
- X-Frame-Options, X-Content-Type-Options, Referrer-Policy gibi başlıklarla saldırı yüzeyini daraltırsınız.
Bu başlıkların ne işe yaradığını ve ne zaman, nasıl uygulanması gerektiğini HTTP güvenlik başlıkları rehberi yazımızda ayrıntılı anlattık. TLS güvenlik güncellemelerinizi planlarken, bu başlıkları da aynı oyun planına dâhil etmek bütünsel güvenlik sağlar.
Farklı senaryolar için SSL/TLS güvenlik yol haritası
Her projenin ihtiyaçları farklı. Aşağıda e-ticaret, SaaS, e-posta ve API senaryoları için pratik yol haritaları yer alıyor.
E-ticaret siteleri ve PCI DSS gereksinimleri
Kart ödemesi alan, özellikle de PCI DSS kapsamına giren e-ticaret projelerinde TLS konusu daha sıkı kurallara tabidir:
- Güvenli bir temel olarak TLS 1.0 ve 1.1’i kapatıp TLS 1.2 ve 1.3 kullanın; PCI DSS uyumluluğunu yalnızca protokol sürümüne bakarak değerlendirmeyin.
- Zayıf şifre takımları (RC4, 3DES vb.) kesinlikle kapalı olmalı.
- Güçlü anahtar uzunlukları ve modern imza algoritmaları (RSA 2048+, SHA-256+) kullanılmalı.
- PCI DSS kapsamınızda ASV taraması gerekiyorsa, ilgili sıklık ve başarılı tarama koşullarını karşılayan dış güvenlik taramaları yaptırın.
PCI DSS tarafında “ne kadarını hosting’e, ne kadarını uygulamaya yüklemelisiniz?” sorusunu PCI DSS’i dert etmeden uyumlu kalma rehberimizde detaylandırdık. SSL/TLS güncellemeleri, bu uyumluluğun temel sütunlarından biri.
SaaS uygulamaları ve çok kiracılı mimariler
Çok kiracılı (multi-tenant) SaaS projelerinde iki önemli yönetim konusu vardır:
- Her kiracı için ayrı alan adları (custom domain) yönetimi
- Bu alan adları için otomatik SSL üretme ve yenileme ihtiyacı
Burada TLS güncellemeleri sadece tek bir sertifikayı değil, yüzlerce hatta binlerce alan adını etkileyebiliyor. Bu yüzden ACME tabanlı otomasyon ve merkezi sertifika yaşam döngüsü yönetimi önemlidir. Doğrulama yöntemini alan adı ve erişim koşullarına göre seçin; DNS-01 her özel alan adı için zorunlu değildir. Çok kiracılı ortamlarda özel alan adları ve otomatik SSL konusunu, SaaS’te özel alan adları ve otomatik SSL rehberimizde operasyonel açıdan detaylandırdık.
E-posta altyapıları: MTA-STS, TLS-RPT ve DANE ile ek güvenlik
SSL/TLS güncellemeleri sadece web tarafında değil, SMTP (e-posta) tarafında da kritik. Temel, fırsatçı STARTTLS tek başına TLS kullanımını zorunlu kılmaz; ek politika ve raporlama mekanizmaları şunlardır:
- MTA-STS ile, politikanızı edinip uygulayan gönderici sunucuların alan adınıza e-posta teslim ederken doğrulanmış TLS kullanmasını enforce modunda zorunlu kılabilirsiniz. Bu, tüm göndericileri veya giden postayı kapsayan bir garanti değildir.
- TLS-RPT ile, TLS bağlantı hataları hakkında rapor alarak sorunları hızlıca tespit edebilirsiniz.
- DANE/TLSA ile DNSSEC üzerinden TLS sertifikalarınızı doğrulatarak ek güvenlik katmanı ekleyebilirsiniz.
Bu mekanizmaların pratik kurulumunu ve hangi senaryoda ne kadar fayda sağladığını, MTA-STS, TLS-RPT ve DANE/TLSA ile SMTP güvenliği rehberimizde anlattık. Web tarafındaki TLS güncellemeleriyle beraber, e-posta altyapınızı da benzer standartlara getirmenizi öneriyoruz.
API’ler ve makine-makine trafiği
Mobil uygulamalar, mikroservisler ve harici entegrasyonlar genelde API üzerinden haberleşiyor. Burada iki ekstra noktaya dikkat etmek gerekir:
- Eski TLS kütüphanelerine sahip istemciler (eski Android SDK’ları, eski Java sürümleri) TLS 1.2/1.3 ile sorun yaşayabilir. Bu nedenle değişikliği duyurmak ve geçiş süresi tanımak önemlidir.
- İç servisler arasında mTLS (karşılıklı TLS) kullanarak tarafların sertifikalarını karşılıklı doğrulayabilirsiniz. Erişimi yalnızca izin verilen servislere açmak için doğrulanan sertifika kimliğine göre yetkilendirme de uygulayın. Bu yaklaşımı Nginx ve Caddy’de mTLS kurulumu yazımızda adım adım ele aldık.
Özet: Sağlam bir SSL/TLS güvenlik güncelleme planı nasıl görünür?
Artık net bir tablo var: SSL/TLS güvenliği, sadece tarayıcının sol tarafındaki kilit simgesini yakmak değil; sürekli bakım gerektiren bir altyapı bileşeni. Elinizde pratik bir kontrol listesi olması için ana maddeleri toparlayalım:
- SSLv3, TLS 1.0 ve TLS 1.1’i kapatın; TLS 1.2 ve 1.3’ü standart hâle getirin.
- Sadece güçlü, AEAD tabanlı ve forward secrecy sağlayan şifre takımlarını açık bırakın.
- RSA 2048+ veya ECDSA (mümkünse ikili yapı) ile modern anahtar ve imza algoritmalarını tercih edin.
- Sertifika sürelerini kısa tutun, otomatik yenileme (ACME) kurun ve CAA kayıtlarıyla yetkili CA’ları sınırlandırın. OCSP Stapling’i yalnızca CA ve sertifika desteği varsa kullanın.
- Yapılandırma değişikliklerini staging ortamında test edin, versiyon kontrolü ve CI/CD sürecine entegre edin.
- HTTP güvenlik başlıklarını (HSTS, CSP vb.) TLS güncellemeleriyle birlikte ele alın.
- Özel senaryolarda (e-ticaret, SaaS, SMTP, API) ilgili standart ve rehberlere uyum sağlayın.
İster paylaşımlı hosting, ister VPS veya dedicated sunucu, ister colocation altyapınız olsun; SSL/TLS tarafını güncel tutmak hem güvenlik hem de iş sürekliliği açısından kritiktir. Mevcut projelerinizde TLS yapılandırmanızdan emin değilseniz, önce küçük bir envanter çıkarın: Hangi alan adında hangi sertifika var, hangi TLS sürümleri ve şifreler açık, hangi tarayıcı veya istemciler bağlanıyor?
Bu tabloyu netleştirdikten sonra, burada anlattığımız adımları uygulayarak kademeli bir iyileştirme planı hazırlayabilirsiniz. DCHost üzerindeki mevcut hosting, VPS veya dedicated sunucularınız için TLS 1.3, mTLS, HSTS ve otomatik sertifika yenileme seçeneklerini değerlendirirken, hizmetinizin desteklediği özellikleri ve yapılandırma yetkilerinizi netleştirerek projenize uygun bir güvenlik yol haritası oluşturun.
