SSL/TLS tarafında her birkaç yılda bir yapılan küçük bir ayar değişikliğinin, tüm altyapınızı etkileyebildiğini muhtemelen deneyimlemişsinizdir. Bir yanda tarayıcıların eski protokolleri agresif şekilde devre dışı bırakması, diğer yanda PCI DSS, KVKK gibi regülasyonların minimum TLS sürümü ve şifre takımı (cipher suite) beklentileri… Sonuç: “HTTPS çalışıyor” demek artık yeterli değil; hangi SSL/TLS protokol güncellemelerini ne zaman, nasıl uyguladığınız kritik hale geldi.
DCHost olarak barındırdığımız yüzlerce projede gördüğümüz ortak nokta şu: Sorunların çoğu sertifikadan değil, protokol ve şifre ayarlarının güncel olmamasından kaynaklanıyor. Özellikle eski TLS sürümlerinin açık bırakılması, zayıf şifrelerin devreye girmesi, HSTS ve OCSP Stapling gibi modern özelliklerin eksikliği; hem güvenlik hem de performans tarafında sizi geriye çekiyor. Bu yazıda, teoriden çok pratiğe odaklanarak, modern HTTPS için net bir yol haritası çıkaracağız: Hangi TLS sürümlerini kapatmalı, hangilerini zorunlu kılmalı, hangi şifre takımlarını seçmeli ve tüm bunları paylaşımlı hosting, VPS ve dedicated sunucu ortamlarında nasıl hayata geçirmelisiniz?
İçindekiler
- 1 SSL ve TLS Kısaca: Neyi Güncelliyoruz?
- 2 Protokol Sürümlerinin Evrimi: SSL 2.0’dan TLS 1.3’e
- 3 Şifre Takımları (Cipher Suites) ve Güvenli Varsayılanlar
- 4 Tarayıcı ve Uygulama Ekosistemindeki Güncellemeler
- 5 Sunucu Tarafında Yapmanız Gereken Somut Ayarlar
- 6 PCI DSS, KVKK ve Regülasyon Perspektifinden TLS
- 7 DCHost Ortamında Güncel TLS Stratejisi
- 8 SSL Sertifika ve TLS Güncellemelerini Otomatikleştirmek
- 9 Adım Adım TLS Güncelleme Planı: Nereden Başlamalı?
- 10 Sonuç: TLS’i Bir Defalık Proje Değil, Sürekli Bir Süreç Olarak Görmek
SSL ve TLS Kısaca: Neyi Güncelliyoruz?
Önce resme uzaktan bakalım. SSL/TLS üç temel işi yapar:
- Sunucunun gerçekten iddia ettiği alan adına ait olduğunu kanıtlar (kimlik doğrulama)
- İstemci ile sunucu arasındaki trafiği şifreler (gizlilik)
- Verinin yolda değiştirilmediğini garanti eder (bütünlük)
Bu mekanizmanın nasıl işlediğini daha geniş bağlamda görmek isterseniz, domain, DNS, sunucu ve SSL’in birlikte nasıl çalıştığını anlattığımız rehbere de göz atabilirsiniz.
Protokol güncellemeleri dendiğinde aslında üç katmandan bahsediyoruz:
- Protokol sürümü: SSL 2.0/3.0, TLS 1.0/1.1/1.2/1.3 gibi
- Şifre takımları (cipher suites): ECDHE-RSA-AES128-GCM-SHA256 gibi, anahtar değişimi + şifreleme + özet algoritmasının kombinasyonu
- Ek güvenlik özellikleri: HSTS, OCSP Stapling, HTTP/2–HTTP/3, SNI, ALPN vb.
Modern bir HTTPS yapılandırması; yalnızca geçerli bir sertifikaya değil, güncel protokol sürümleri ve doğru seçilmiş şifre takımlarına dayanır. Birçok güvenlik açığı (POODLE, BEAST, CRIME, ROBOT vb.) doğrudan bu katmanlardaki zayıf noktalardan faydalanır.
Protokol Sürümlerinin Evrimi: SSL 2.0’dan TLS 1.3’e
SSL/TLS dünyasında “eski sürümleri kapatın” önerisini duymuşsunuzdur. Bunu ezberden değil, tarihsel gelişimi anlayarak yapmak çok daha sağlıklı.
Artık Kesinlikle Kapatmanız Gereken Eski Sürümler
- SSL 2.0 ve SSL 3.0: Yıllardır tamamen kırılmış durumda. POODLE gibi saldırılarla pratikte sömürülebiliyor. Her ortamda mutlaka kapalı olmalı.
- TLS 1.0: BEAST, Lucky13 gibi saldırılara açık; PCI DSS ve büyük tarayıcılar tarafından terk edildi. E-ticaret ya da KVKK kapsamındaki veriler için kesinlikle kabul edilemez.
- TLS 1.1: TLS 1.0’dan daha iyi ama modern standartlara göre zayıf. Büyük tarayıcılar zaten devre dışı bırakmış durumda.
Özetle: Bugün yeni bir yapılandırma yapıyorsanız, SSLv2, SSLv3, TLS 1.0 ve TLS 1.1 kesinlikle devre dışı olmalı. Eski bir kurumsal uygulama bu sürümleri istiyorsa, çözüm bunları açık bırakmak değil, uygulamayı güncellemektir.
Bugünün Gerçek Standardı: TLS 1.2 ve TLS 1.3
Güvenli ve performanslı bir HTTPS için odaklanmanız gereken iki sürüm var:
- TLS 1.2: Hâlâ fiili standart. Geniş uyumluluk, güçlü şifreler, HTTP/2 desteği sunuyor. Zayıf şifreleri kapattığınız sürece güvenli kabul ediliyor.
- TLS 1.3: Çok daha hızlı el sıkışma (handshake), daha sade protokol, yalnızca modern şifre takımlarına izin verme gibi avantajlara sahip. HTTP/3 için zorunlu.
Önerilen minimum yapılandırma:
- Yalnızca TLS 1.2 ve TLS 1.3’ü etkin bırakmak
- Zayıf TLS 1.2 şifre takımlarını (CBC, 3DES, RC4 vb.) kapatmak
- Mümkünse istemcileri otomatik olarak TLS 1.3’e yönlendirecek şekilde sunucu önceliğini ayarlamak
TLS 1.3’ün pratik etkilerini, HTTP/2 ve HTTP/3 ile ilişkisini daha detaylı incelemek isterseniz, HTTP/2 ve HTTP/3 desteğinin SEO ve performansa etkilerini anlattığımız yazı iyi bir tamamlayıcı olacaktır.
Şifre Takımları (Cipher Suites) ve Güvenli Varsayılanlar
Birçok güvenlik denetiminde gördüğümüz ortak hata: Protokol sürümleri güncel olsa da, zayıf şifre takımlarının açık bırakılması. Örneğin TLS 1.2 kullanırken hala CBC modlu, PFS (Perfect Forward Secrecy) sunmayan şifrelere izin vermek gibi.
Güncel Bir Yapılandırmada Olması Gereken Özellikler
- PFS (Perfect Forward Secrecy): ECDHE veya DHE anahtar değişimi kullanan şifreler tercih edilmeli. Böylece uzun vadeli sunucu anahtarınız sızsa bile geçmiş oturumlar çözülemez.
- AEAD şifreler: AES-GCM veya CHACHA20-POLY1305 gibi, hem şifreleme hem bütünlük sağlayan modern algoritmalar kullanılmalı.
- SHA-1 yerine SHA-256+: Özet (hash) kısmında SHA-1 değil, SHA-256 veya üstü tercih edilmeli.
- RSA + ECDSA desteği: Uyumluluk için RSA, performans ve modernlik için ECDSA sertifikalarına izin veren karma yapılandırmalar idealdir.
Tipik, güvenli bir TLS 1.2 şifre listesi şu öğeleri içermelidir (mantık düzeyinde):
- 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
Ve mutlaka şunları dışarıda bırakmalısınız:
- RC4 içeren tüm şifreler
- 3DES/DES tabanlı şifreler
- CBC modlu, PFS olmayan eski kombinasyonlar
TLS 1.3 tarafında ise iyi haber şu: Protokol kendi içinde yalnızca modern şifreleri destekleyecek şekilde tasarlandığı için, yanlış yapma alanınız çok daha dar. Yine de Nginx/Apache gibi sunucularda TLS 1.3 ve TLS 1.2 için şifre listelerini ayrı ayrı tanımlayıp test etmek önemli.
Tarayıcı ve Uygulama Ekosistemindeki Güncellemeler
SSL/TLS protokol güncellemelerini sadece “sunucu ayarı” olarak görmek eksik olur. Tarayıcılar, mobil uygulama SDK’ları, API istemcileri ve hatta IoT cihazları bu ekosistemin parçası. Son yıllardaki birkaç kritik değişiklik:
- Büyük tarayıcılar TLS 1.0 ve TLS 1.1 desteğini varsayılan olarak kapattı
- HTTP/2 için fiilen TLS 1.2+ zorunlu hale geldi
- HTTP/3 (QUIC) yalnızca TLS 1.3 üzerinde çalışıyor
- HSTS preload listeleri agresif şekilde yaygınlaştı
Bu da şu anlama geliyor: Siteniz sadece güvenlik için değil, performans ve SEO için de modern TLS konfigürasyonuna ihtiyaç duyuyor. Örneğin HTTP/2 ve HTTP/3 etkin değilse, özellikle mobil bağlantılarda Core Web Vitals metrikleriniz olumsuz etkilenebilir. Bu ilişkiyi detaylı anlattığımız Core Web Vitals’ı hosting tarafında iyileştirme rehberimiz de bu yazının doğal bir devamı niteliğinde.
CDN arkasında çalışan sitelerde ise, CDN ile origin (kaynak sunucu) arasındaki TLS ayarları ayrıca önem kazanıyor. “CDN zaten HTTPS sağlıyor” diye düşünmek yeterli değil; origin bağlantısının da TLS 1.2+ ve güvenli şifrelerle korunması kritik. Bu mimariyi uçtan uca ele aldığımız CDN arkasında gerçek HTTPS ve Full (Strict) SSL kurulumu rehberine mutlaka göz atmanızı öneririz.
Sunucu Tarafında Yapmanız Gereken Somut Ayarlar
Teoriyi pratiğe dökelim. Paylaşımlı hosting yerine kendi VPS veya dedicated sunucusunu yönetenler için, Nginx/Apache/LiteSpeed tarafında genellikle şu başlıkları ayarlamak gerekir:
- Protokol sürümleri: Sadece TLSv1.2 ve TLSv1.3 açık olacak şekilde yapılandırma
- Şifre listesi: Yukarıda bahsettiğimiz gibi PFS + AEAD odaklı modern şifreler
- Sunucu önceliği: “server cipher preference” etkinleştirilerek istemcinin değil sunucunun sıralamasının dikkate alınması
- OCSP Stapling: Sertifika geçerlilik kontrolünü hızlandırmak ve gizlilik kazanmak için origin tarafında etkinleştirmek
- HSTS: HTTP’den HTTPS’e kalıcı geçişi zorunlu kılmak ve downgrade saldırılarını önlemek
Nginx tarafında TLS 1.3, OCSP Stapling ve sıkıştırma ayarlarını detaylı anlattığımız adım adım TLS 1.3 rehberi, bu bölümde anlattıklarımızı uygulamaya dökerken size oldukça yardımcı olacaktır.
Bunlara ek olarak, HTTP güvenlik başlıkları (HSTS, CSP, X-Frame-Options, Referrer-Policy vb.) ile TLS yapılandırmanızı tamamlamak gerekiyor. Sadece protokolü güncellemek değil, tarayıcının bu protokole nasıl davranacağını da doğru başlıklarla yönlendirmek önemli. Bunun için de HTTP güvenlik başlıkları rehberimize mutlaka göz atmanızı tavsiye ederiz.
PCI DSS, KVKK ve Regülasyon Perspektifinden TLS
E-ticaret, ödeme sistemleri veya hassas kişisel veri işleyen projelerde, TLS ayarları sadece “iyi niyetli bir güvenlik önlemi” değil, aynı zamanda uyulması gereken bir yükümlülük haline geliyor.
- PCI DSS: Ödeme kartı verisi işleyen sistemler için TLS 1.0 ve 1.1 kullanımını yıllar önce yasakladı. Pratikte TLS 1.2 minimum, TLS 1.3 ise tavsiye edilen seviye.
- KVKK / GDPR: Kanun doğrudan TLS sürümü söylemez; ancak “güncel teknik önlemler” ibaresi, zayıf TLS sürümlerinin ve şifrelerinin kullanılması halinde sorumluluğu size yükler.
- Kurumsal güvenlik politikaları: Birçok kurum dahili politika ve denetimlerinde, TLS 1.2+ zorunluluğu ve belirli zayıf şifrelerin tamamen yasaklanmasını şart koşuyor.
Kart verisi işleyen projeler için hazırladığımız PCI DSS uyumlu e-ticaret hosting rehberinde, TLS konfigürasyonunun denetimlerde nasıl değerlendirildiğine dair sahadan örnekler paylaşıyoruz. TLS 1.0/1.1’in açık olduğu, RC4 veya 3DES’in hala listede bulunduğu sistemler; çoğu denetimde hiç tartışmasız “uyumsuz” olarak işaretleniyor.
DCHost Ortamında Güncel TLS Stratejisi
DCHost olarak hem paylaşımlı hosting hem de VPS/dedicated altyapımızda TLS konusunu “sertifika var mı yok mu” seviyesinin oldukça ötesinde ele alıyoruz. Sahada edindiğimiz tecrübeyle benimsediğimiz temel prensipler:
- Tüm yeni kurulumlarda yalnızca TLS 1.2 ve TLS 1.3 desteği vermek
- Paylaşımlı hosting sunucularında, zayıf TLS 1.2 şifre takımlarını varsayılan olarak devre dışı bırakmak
- Mümkün olan her yerde HTTP/2 ve HTTP/3 desteğini aktif etmek
- Origin–CDN arası bağlantılarda da Full (Strict) TLS politikası uygulamak
- VPS ve dedicated müşterilerimize, kendi Nginx/Apache/LiteSpeed yapılandırmalarını sertleştirmeleri için örnek konfigürasyon ve danışmanlık sağlamak
VPS, dedicated veya colocation tarafında kendi TLS mimarinizi tasarlarken desteğe ihtiyaç duyarsanız, DCHost ekibi olarak; sunucu boyutlandırmasından başlayarak, dedicated mi VPS mi sorusunun cevabından, canlıya çıkışta zero-downtime sertifika geçişine kadar yanınızda olabiliyoruz.
SSL Sertifika ve TLS Güncellemelerini Otomatikleştirmek
Protokol güncellemeleri genelde bir defalık iş gibi düşünülür; oysa pratikte şöyle olur: Sertifikalar yenilenir, yeni bir web sunucu versiyonuna geçilir, CDN politikaları değişir ve her seferinde TLS ayarlarınızı tekrar gözden geçirmeniz gerekir. Bu yüzden otomasyon, sürdürülebilir bir güvenlik için kritik.
- ACME tabanlı sertifika otomasyonu: Let’s Encrypt ve benzeri CA’lerle otomatik sertifika yenileme (ACME) kullanmak, expiré sertifika riskini ciddi biçimde azaltır.
- Otomatik testler: testssl.sh, sslscan gibi araçlarla periyodik tarama yapmak; yanlışlıkla açılmış eski protokolleri yakalamanızı sağlar.
- Konfigürasyon yönetimi: Birden çok sunucunuz varsa, TLS ayarlarını elle değil; Ansible, Terraform gibi araçlarla yönetmek daha güvenli ve tekrarlanabilir olur.
Bu alandaki güncel yaklaşımları ve çok kiracılı ortamlarda SSL/TLS otomasyonunu nasıl ölçeklendirebileceğinizi, SSL sertifika otomasyonu inovasyonları yazımızda detaylı olarak anlattık. Oradaki pratikler, bu yazıda bahsettiğimiz protokol güncellemelerini tekrar tekrar elle yapmak zorunda kalmamanız için çok önemli.
Adım Adım TLS Güncelleme Planı: Nereden Başlamalı?
Teorik olarak her şey net görünebilir, ama canlıda çalışan bir sistemde “TLS 1.0/1.1’i kapatalım, şifreleri sertleştirelim” demek çoğu ekip için riskli hissettirir. DCHost’ta sahada kullandığımız pratik bir yol haritasını özetleyelim:
- Envanter çıkarın: Hangi alan adları, hangi sunucular, hangi paneller (cPanel, DirectAdmin, Plesk vb.) ve hangi TLS sürümlerini kullanıyor, listeleyin.
- Mevcut durumu ölçün: testssl.sh, SSL Labs gibi araçlarla her host için rapor alın. Hangi protokoller açık, hangi şifreler kullanılıyor, not edin.
- Uyumluluk risklerini belirleyin: Çok eski tarayıcı veya gömülü cihaz kullanan kritik bir müşteri kitleniz varsa, önceden haberdar edin; alternatif erişim (ör. yalnızca iç ağdan erişilen eski endpoint) tasarlayın.
- Önce TLS 1.0/1.1’i devre dışı bırakın: Çoğu projede bu değişiklik sorunsuz geçer. Problemler genelde özelleştirilmiş eski API istemcilerinde ortaya çıkar.
- Şifre listesini temizleyin: RC4, 3DES, zayıf CBC şifrelerini kapatın; PFS + AEAD odaklı modern bir setle devam edin.
- TLS 1.3’ü etkinleştirin: Web sunucunuz destekliyorsa, TLS 1.3’ü açın ve HTTP/2–HTTP/3 ile entegrasyonunu test edin.
- Güvenlik başlıklarını ekleyin: HSTS, X-Content-Type-Options, Referrer-Policy ve mümkünse temel bir CSP ile tarayıcı tarafını sertleştirin.
- Sonuçları izleyecek metrik kurun: Hata logları, erişim logları ve monitoring araçlarıyla (örneğin Uptime monitörleri) değişiklik sonrası hata oranlarını takip edin.
Özellikle VPS veya dedicated sunucu kullanıyorsanız, bu planı uygularken VPS sunucu güvenliği kontrol listeleri gibi tamamlayıcı rehberlerden yararlanmanız, sadece TLS değil, tüm saldırı yüzeyinizi küçültmenize yardımcı olur.
Sonuç: TLS’i Bir Defalık Proje Değil, Sürekli Bir Süreç Olarak Görmek
SSL/TLS tarafında “sertifikam var, yeşil kilit çıkıyor” dönemi çoktan kapandı. Bugün oyun şöyle oynanıyor: Tarayıcılar ve güvenlik standartları belirli aralıklarla protokol ve şifre beklentilerini yukarı çekiyor, siz de altyapınızı buna uyumlu tutmak zorundasınız. TLS 1.0/1.1’i kapatmak, TLS 1.3’e geçmek, zayıf şifreleri listeden çıkarmak, HSTS ve OCSP Stapling eklemek; birer lüks değil, modern bir web projesinin asgari hijyen kuralları haline geldi.
DCHost olarak biz, bu hijyeni sağlamak için barındırma altyapımızı düzenli aralıklarla gözden geçiriyoruz: Paylaşımlı hosting sunucularında varsayılan TLS politikalarını güncelliyor, VPS ve dedicated müşterilerimize örnek konfigürasyonlar ve denetim önerileri sunuyoruz. Sizin tarafta da “Bu ay TLS ile ilgili neyi iyileştirdik?” sorusunu sormayı alışkanlık haline getirmenizi öneririz.
Eğer kendi projeniz için somut bir aksiyon planı çıkarmak isterseniz, önce mevcut durumu tespit edip, ardından bu yazıdaki adımları DCHost üzerindeki hosting paketinize, VPS’inize veya dedicated sunucunuza uygulayabiliriz. İhtiyacınız ister basit bir web sitesi olsun, ister yoğun trafikli bir e-ticaret altyapısı; güncel SSL/TLS protokol ayarları konusunda yanınızdayız. Bir sonraki bakım penceresinde, bu yazıyı checklist gibi açıp madde madde ilerlemeniz bile, güvenlik ve performans anlamında sizi bir nesil ileri taşıyacaktır.
