SSL/TLS Güvenlik Güncellemeleri: Ne Zaman, Nasıl ve Neyi Değiştirmelisiniz?

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 regülasyonları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.

DCHost tarafında gördüğümüz en yaygın problemlerden biri, işletmelerin SSL/TLS tarafında sadece sertifika süresi dolduğunda harekete geçmesidir. Oysa riskler çoğu zaman sertifikanın kendisinden değil, protokol versiyonları, şifre takımları ve yanlış yapılandırılmış güvenlik başlıklarından kaynaklanıyor. Bu yazıda, sitenizi ve API’lerinizi gerçekten güvenli tutmak için SSL/TLS güvenlik güncellemelerini nasıl planlamanız gerektiğini, sahadaki gerçek senaryolar üzerinden anlatacağım.

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. Çoğu sunucuda hâlâ TLS 1.0 ve 1.1’in açık olduğunu, bazen de SSLv3 kalıntılarını görebiliyoruz. “Ç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; POODLE, BEAST, Lucky13 gibi birçok bilinen zafiyete karşı savunmasız. Ayrıca bu protokoller modern şifreleme standartlarını (örneğin AEAD tabanlı GCM modları, ChaCha20-Poly1305 gibi) düzgün şekilde desteklemiyor. Tarayıcı üreticileri ve uyumluluk standartları bu yüzden yıllardır aynı mesajı veriyor: Bu sürümler kapatılmalı.

• PCI DSS 3.2 ve sonrası, kart verisi işleyen sistemlerde TLS 1.0’ı yasaklıyor.
• 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 gibi özelliklerle bazı senaryolarda ek performans kazancı sunar (doğru yapılandırma şartıyla).

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, bunu izole bir endpoint veya alt alan adı ile sınırlı tutun.

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 HTTP/2, belirli zayıf şifre takımlarını tamamen reddediyor. 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: Sadece açık/kapalı değil, nasıl?

Protokol sürümlerini güncelledikten sonra sırada şifre takımları (cipher suites) var. Birçok sunucuda gördüğümüz tablo şöyle:

• RC4, 3DES gibi eski algoritmalar hâlâ açık.
• Forward secrecy (PFS) sağlamayan şifreler kullanılmaya devam ediyor.
• RSA tabanlı şifreleme ile ECDHE/ECDSA karışık, tutarsız bir şekilde listelenmiş.

Bunların hepsi tek başına tarayıcıyı çökertmeyebilir, fakat saldırı yüzeyinizi gereksiz yere genişletir ve güvenlik taramalarında puanınızı düşürür.

Ö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 ise şifre takımları protokolün içine gömülü ve zaten zayıf seçenekler listede yok. Bu da yönetimi bir nebze kolaylaştırıyor.

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â en yaygın ve uyumlu seçenek. Ancak performans ve modernlik tarafında ECDSA sertifikalar ciddi avantaj sağlıyor:

• Daha küçük sertifika boyutu → Daha hızlı handshake.
• Daha düşük CPU yükü → Özellikle yoğun trafikli sitelerde fark edilir performans kazancı.

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, hem RSA hem ECDSA sertifika sunar; istemci hangisini destekliyorsa onu kullanır. Böylece eski cihazları kırmadan modern tarafa da yatırım yapmış olursunuz.

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: Algoritma, süre, CA ve politika değişiklikleri

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, 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:

• İmza algoritması olarak SHA-256 veya üzeri kullanılmalı.
• RSA anahtar uzunluğu en az 2048 bit olmalı (kurumsal projelerde 3072 bit de sıkça tercih ediliyor).
• ECDSA için P-256 ve üzeri eğriler standart hâle geldi.

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.) hâlâ eski algoritmalarla imzalanmış sertifikalar görüyoruz. Bu da iç sistemlerin saldırılara daha açık hâle gelmesine yol açıyor.

Sertifika süreleri kısalıyor: 3 yıldan 1 yıla, oradan 90 güne

Eskiden 3 yıla kadar sertifika alınabiliyordu; bugün tarayıcılar ve CA/B Forum kuralları gereği genel olarak 398 gün civarında bir üst limit söz konusu. Orta vadede hedeflenen ise 90 gün veya daha kısa süreli sertifikalara geçiş. Bunun arkasındaki sebep basit:

• Özel anahtar sızsa bile, kısa süreli sertifikalarda hasar penceresi daralır.
• CA politikalarındaki değişiklikler daha hızlı hayata geçer.

Bu tablo, manuel sertifika yönetiminin sürdürülemez hâle geldiğini gösteriyor. Tam da bu yüzden, DCHost olarak ACME tabanlı otomatik SSL yönetimi ve sertifika yenileme süreçlerini altyapımızda merkezî olarak tasarlıyoruz. 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 etkinleştirerek, istemcinin sertifika iptal (revocation) durumunu daha hızlı ve gizliliği bozmadan kontrol etmesini sağlayabilirsiniz.
• Özel anahtar sızıntısı gibi durumlar için, sertifika iptal ve yeniden çıkarma sürecini önceden planlamak gerekir.

OCSP Stapling ve HSTS gibi modern mekanizmaları uygulama 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ış: SSL/TLS güvenlik güncellemelerini sürece dönüştürmek

Teknik konular kadar önemli olan diğer boyut, güncelleme sürecini nasıl yönettiğiniz. DCHost’ta müşteri ortamlarına dokunduğumuzda en sık gördüğümüz sorun, SSL/TLS tarafının net bir sorumluya ve periyodik bir kontrol listesine sahip olmaması.

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.
• 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 tarayıcılara sitenize her zaman HTTPS üzerinden bağlanmalarını söylersiniz.
• 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ı. Yine de DCHost tarafında karşılaştığımız en yaygın senaryolar için birkaç pratik yol haritası paylaşabiliriz.

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:

• TLS 1.0 ve 1.1’in tamamen kapatılması artık fiili bir gereklilik.
• 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ı.
• Periyodik olarak dış güvenlik taramaları (ASV scan) yapılmalı.

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 genelde iki zorluk görüyoruz:

• 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 mutlaka ACME tabanlı otomasyon, DNS-01 doğrulama ve merkezi sertifika yaşam döngüsü yönetimi kurmak gerekiyor. Ç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 STARTTLS desteği artık yetmiyor; özellikle:

• MTA-STS ile, alan adınız için e-posta trafiğinin mutlaka TLS ile iletilmesini zorunlu kılabilirsiniz.
• 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 sadece sertifikaya sahip servislerin iletişim kurmasına izin verebilirsiniz. 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/OCSP Stapling gibi modern mekanizmaları etkinleştirin.
• 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.

DCHost olarak, ister paylaşımlı hosting, ister VPS veya dedicated sunucu, ister colocation altyapınız olsun; SSL/TLS tarafını güncel tutmanın hem güvenlik hem de iş sürekliliği açısından ne kadar kritik olduğunu sahada her gün görüyoruz. 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. İsterseniz DCHost üzerindeki mevcut hosting, VPS veya dedicated sunucularınızda, TLS 1.3’ten mTLS’e, HSTS’ten otomatik sertifika yenilemeye kadar tüm bu bileşenleri birlikte gözden geçirip, projenize uygun bir güvenlik yol haritasını beraber tasarlayabiliriz.