SSL/TLS Protokol Güncellemeleri ile Web Sitenizi Güncel ve Güvenli Tutmak

SSL/TLS protokol güncellemeleri neden artık opsiyon değil zorunluluk?

Tarayıcı üreticileri, ödeme kuruluşları ve regülasyon tarafı her yıl güvenlik çıtasını biraz daha yukarı çekiyor. Birkaç yıl önce TLS 1.0 kullanan bir web sitesi gayet normal sayılırken, bugün aynı konfigürasyon hem tarayıcılarda kırmızı uyarılar hem de PCI DSS gibi standartlar açısından uyumsuzluk anlamına geliyor. Kısacası, SSL/TLS protokol güncellemeleri artık sadece “güvenlik ekibinin işi” değil; doğrudan gelir kaybını, SEO’yu ve marka itibarını etkileyen bir konu.

DCHost tarafında yaptığımız güvenlik denetimlerinde en sık gördüğümüz tablo şu: Sertifikalar yenileniyor, HSTS ve HTTP güvenlik başlıkları bir noktaya kadar ayarlanmış oluyor, ama altta çalışan TLS sürümleri ve şifre paketleri (cipher suite) yıllardır el değmemiş halde kalıyor. Sonuç: Test araçları sitenizi “zayıf” veya “orta” dereceli, bazı tarayıcılar ise “güvenli değil” olarak işaretleyebiliyor.

Bu yazıda, eski SSL/TLS sürümlerini kapatmaktan TLS 1.3’e, modern şifre paketlerinden performans ve uyumluluk dengesine kadar tüm kritik güncellemeleri sade bir dille toparlayacağız. paylaşımlı hosting, VPS, dedicated ve colocation ortamlarında neleri nasıl değiştirmeniz gerektiğini, DCHost üzerinde uyguladığımız gerçekçi pratiklerle anlatacağız. Hedefimiz; hem geliştiricilerin hem de teknik tarafa mesafeli işletme sahiplerinin kendi sitelerinin TLS durumunu okuyup net bir yol haritası çıkarabilmesi.

SSL/TLS sürümleri: Hangi versiyon neden kapatıldı, hangileri kalmalı?

Önce tabloyu netleştirelim. Bugün itibarıyla pratik ve güvenli yaklaşım şu:

• Kesinlikle kapatılmalı: SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1
• Güncel ve yaygın: TLS 1.2
• Önerilen modern standart: TLS 1.3

SSL 2.0 ve 3.0 yıllardır tamamen devre dışı bırakılmış olması gereken, çok sayıda kritik zaafiyete sahip eski protokoller. TLS 1.0 ve 1.1 ise teoride hâlâ bazı çok eski istemciler tarafından kullanılabiliyor olsa da, günümüz dünyasında neredeyse her ciddi güvenlik kılavuzunda “kapatın” kategorisinde.

Eski sürümleri açık bırakmanın gerçek riskleri

Eski sürümleri açık tutmak sadece teorik bir risk değil; doğrudan sömürülebilen açıklar barındırıyor:

• BEAST, POODLE, Lucky 13 gibi saldırılar, SSL 3.0 ve TLS 1.0’ın CBC tabanlı şifre paketleri üzerinde çalışabiliyor.
• Zayıf şifreler ve protokol tasarımı nedeniyle saldırganlar oturum ele geçirme (session hijacking) benzeri senaryolara kapı aralayabiliyor.
• Bazı güvenlik tarama araçları eski sürümleri gördüğünde sitenizi doğrudan “uyumsuz” ve “zayıf” olarak işaretliyor; bu hem SEO araçlarında skorları hem de kurumsal güvenlik denetimi raporlarını olumsuz etkiliyor.

Özellikle ödeme alan sitelerde ve e-ticaret projelerinde, PCI DSS uyumlu e-ticaret hosting rehberi türü kılavuzlara baktığınızda TLS 1.0 ve 1.1’in devre dışı bırakılmasının artık temel şartlardan biri olduğunu görürsünüz.

Tarayıcı ve standart taraftaki zorunluluklar

Modern tarayıcılar TLS 1.0 ve 1.1 desteğini çoktan varsayılan olarak pasifleştirdi. Gelişmiş kullanıcılar ayarlardan tekrar açabiliyor olsa da, bu bizim açımızdan anlamlı bir hedef kitle değil. Yani, “ama bizim müşterilerden birkaçı eski tarayıcı kullanıyor olabilir” gerekçesi bugün artık teknik olarak savunulabilir değil.

Özetle: TLS 1.2 ve TLS 1.3’ü açık tutup, diğer tüm sürümleri kapatmak bugünün en mantıklı, güvenli ve gerçekçi varsayılan ayarıdır.

TLS 1.2 ve TLS 1.3: Güvenliğin güncel temeli

Bu noktadan sonra asıl odaklanmamız gereken iki sürüm var: TLS 1.2 ve TLS 1.3. Dünya üzerindeki HTTPS trafiğinin büyük çoğunluğu bu iki sürüm üzerinden dönüyor.

TLS 1.2, uzun yıllardır ana standart ve halen de çok geniş uyumluluk sağlıyor. Eski işletim sistemlerinden görece yeni mobil tarayıcılara kadar hemen her istemci tarafından destekleniyor. TLS 1.3 ise özellikle hız, gizlilik ve protokol sadeleştirmesi açısından önemli yenilikler getiriyor.

TLS 1.3’ün getirdikleri

TLS 1.3’e geçtiğinizde aşağıdaki kazanımları elde edersiniz:

• Daha hızlı el sıkışma (handshake): Bağlantı kurulurken gidiş-dönüş (RTT) sayısı azalır; bu da özellikle yüksek gecikmeli ağlarda hissedilir hız artışı demektir.
• Saldırı yüzeyinin küçülmesi: Eski ve zayıf şifre paketleri protokolden tamamen çıkarıldığı için yanlış konfigürasyon yapma şansınız azalır.
• Zorunlu Perfect Forward Secrecy (PFS): Tüm bağlantılarda geçici anahtarlar (ephemeral keys) kullanılır; uzun vadeli anahtarınız sızsa bile geçmiş trafiğin çözülmesi engellenir.
• Daha güçlü şifreler: AES-GCM ve ChaCha20-Poly1305 gibi modern, saldırı yüzeyi dar şifreler varsayılan hâle gelir.

TLS 1.3 hakkındaki teknik detaylara daha derin inmek isterseniz, DCHost blogunda yayınladığımız TLS 1.3 standart güncellemeleri ve sunucu tarafına etkileri yazısına da göz atabilirsiniz.

TLS 1.3’e rağmen TLS 1.2 neden hâlâ gerekli?

Pratikte tüm istemcilerin TLS 1.3 desteklediğini varsaymak bugün için hâlâ biraz iyimser olur. Özellikle:

• Kurumsal iç ağlarda çalışan eski Java client’lar
• Güncellenmemiş bazı gömülü cihazlar
• Çok eski ama hâlâ sahada olan bazı mobil işletim sistemleri

gibi senaryolarda TLS 1.2’ye ihtiyaç duyulabiliyor. Bu nedenle önerilen mimari:

• TLS 1.3: Açık ve öncelikli
• TLS 1.2: Açık ve güvenli şifre paketleriyle kısıtlanmış

Yani, uyumluluk için TLS 1.2’yi açık bırakıyor, ancak zayıf şifre paketlerini kapatarak hem güvenliği hem de performansı dengede tutuyoruz.

Modern şifre paketleri (cipher suite): Hangilerini kullanmalı, hangilerini kapatmalısınız?

Doğru TLS sürümlerini seçmek kadar önemli bir diğer konu da şifre paketleri. Aynı TLS 1.2 sürümü içerisinde bile çok zayıf ve çok güçlü seçenekler yan yana bulunabiliyor. Burada güncel yaklaşım şöyle özetlenebilir:

• Açık ve öncelikli tutulması önerilenler:
  • TLS 1.3 için: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256
  • TLS 1.2 için: ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-ECDSA-CHACHA20-POLY1305, ECDHE-RSA-CHACHA20-POLY1305
• Kapatılması gerekenler:
  • RC4, 3DES, IDEA, SEED gibi eski simetrik algoritmalar
  • CBC tabanlı birçok paket (özellikle TLS 1.0/1.1 ile kombinasyonları)
  • Anahtar değişimi için düz RSA (RSA key exchange), mümkün olduğunda ECDHE tercih edilmeli

ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) tabanlı şifre paketleri, hem performans hem de Perfect Forward Secrecy nedeniyle modern HTTPS’in temel yapı taşı hâline geldi. Bu nedenle, ECDHE içermeyen cipher suite’leri listeden temizlemek uzun vadede en güvenli yaklaşım.

Nginx için örnek modern TLS yapılandırması (genel mantık)

Aşağıdaki örnek, yapıyı anlamanız için sadeleştirilmiş bir Nginx konfigürasyon mantığıdır; tam değerler ortamınıza göre değişebilir:

• ssl_protocols TLSv1.2 TLSv1.3;
• ssl_prefer_server_ciphers on;
• ssl_ciphers ile sadece ECDHE ve GCM/CHACHA tabanlı güçlü paketlerin açık bırakılması;
• ssl_session_cache ve ssl_session_tickets ayarlarıyla performans dengesi kurulması;

Nginx/Apache/LiteSpeed tarafındaki teknik ayrıntıları ayrı yazılarda detaylandırıyoruz; bu yazıda asıl vermek istediğimiz mesaj şu: Şifre paketleri listesi, bir kere yazılıp unutulacak bir metin değil; periyodik olarak gözden geçirilmesi gereken bir güvenlik politikasıdır.

HTTP güvenlik başlıkları, HSTS ve TLS konfigürasyonu birlikte düşünülmeli

TLS sürümlerinizi ve cipher suite’lerinizi güncelledikten sonra, bağlantının üst katmanında çalışan HTTP tarafını da güçlendirmeniz gerekiyor. Özellikle:

• HSTS (HTTP Strict Transport Security)
• Content-Security-Policy (CSP)
• Referrer-Policy, X-Frame-Options, X-Content-Type-Options

gibi başlıklar hem tarayıcıya “bu siteyi her zaman HTTPS üzerinden aç” demenizi sağlar, hem de içerik enjeksiyonu gibi üst katman saldırılarını sınırlar. Bu başlıkları nasıl kademeli ve güvenli şekilde devreye alacağınızı, DCHost blogundaki HTTP güvenlik başlıkları rehberi yazımızda ayrıntılı anlatıyoruz.

Özellikle HSTS’yi preload seviyesine çıkaracaksanız, TLS konfigürasyonunuzun gerçekten sağlam olduğundan emin olmanız şart; aksi durumda hatalı veya süresi dolmuş bir sertifika tüm alan adınızı kullanılamaz hâle getirebilir.

Hosting türüne göre pratik TLS güncelleme adımları

DCHost tarafında farklı ölçek ve ihtiyaçlar için paylaşımlı hosting, VPS, dedicated ve colocation çözümleri sunuyoruz. TLS güncellemeleri bu ortamların her birinde biraz farklı yönetiliyor, ancak mantık aynı: Envanter çıkar, test et, kademeli geçiş yap.

Paylaşımlı hosting ortamlarında (cPanel, DirectAdmin vb.)

Paylaşımlı hosting’te TLS sürümleri ve cipher suite listesi genellikle sunucu düzeyinde tek noktadan yönetilir. Bu da son kullanıcı olarak işi bir nebze kolaylaştırır:

• Panelde sadece sertifika türünü ve alan adlarını yönetirsiniz.
• Destek ekibi, web sunucusu (Apache/LiteSpeed/Nginx) ve OpenSSL tarafındaki protokol güncellemelerini merkezi olarak yapar.

DCHost olarak yeni kurulan paylaşımlı hosting sunucularında varsayılan olarak TLS 1.2 + TLS 1.3 açık, SSL 3.0 ve TLS 1.0/1.1 ise kapalıdır. Eğer çok eski bir entegrasyon kullanıyorsanız, bunu önceden destek ekibiyle paylaşmanız ve alternatif bağlantı yöntemleri düşünmeniz en sağlıklı yaklaşım olur.

VPS ve dedicated sunucularda

VPS veya dedicated sunucu kullandığınızda, yetki sizde olduğu için esneklik de sorumluluk da artar. TLS tarafında tipik yapılması gerekenler şunlardır:

• OpenSSL veya kullanılan kriptografi kütüphanesinin güncel olduğundan emin olmak
• Web sunucusu (Nginx/Apache/LiteSpeed/Caddy) konfigürasyonlarında ssl_protocols ve ssl_ciphers değerlerini güncellemek
• Gerekirse test ortamında farklı TLS ayarlarını deneyip yük testleri ve uyumluluk testleri yapmak

VPS üzerinde kendi TLS konfigürasyonunuzu kurarken, aynı zamanda SSL sertifika otomasyon araçları ile sertifika yenileme sürecini de otomatikleştirmeniz çok önemlidir. Güvenli bir protokol konfigürasyonu, süresi dolmuş bir sertifika yüzünden işe yaramaz hâle gelmesin.

Colocation ve hibrit mimarilerde

Kendi fiziksel sunucunuzu DCHost veri merkezinde colocation ile barındırıyorsanız, TLS konfigürasyonu tamamen sizin işletim sisteminiz ve uygulama yığını üzerinde yapılır. Ancak ağ seviyesindeki cihazlar (load balancer, reverse proxy, WAF gibi) da işin içine girdiği için, şu iki noktaya özellikle dikkat etmenizi öneririz:

• Edge cihazlar ile backend sunucuların TLS yetenekleri arasında uyumsuzluk kalmamalı.
• Hem dış dünyaya açık uçta (örneğin Cloudflare gibi bir CDN’in arkasındaki origin sunucu), hem de iç bağlantılarda (servisler arası mTLS) güncel sürümleri destekleyecek tasarım yapılmalı.

Cloudflare, CDN ve TLS: Origin tarafında neye dikkat etmeli?

Birçok sitede HTTPS terminasyonu doğrudan web sunucusunda değil, bir CDN veya reverse proxy katmanında gerçekleşiyor. Cloudflare bu mimarinin en yaygın örneklerinden biri. Ancak burada yapılan tipik hata şu: CDN ile ziyaretçi arasındaki bağlantı TLS 1.3 iken, CDN ile origin (kendi sunucunuz) arasındaki bağlantıda hâlâ eski protokollerin açık tutulması.

DCHost blogunda bu konuyu detaylı olarak anlattığımız Cloudflare DNS ve SSL ayarlarını doğru yapmak rehberine göz atmanızı öneririz. Özetle:

• CDN tarafında Full (Strict) mod kullanmaya çalışın; bu, origin’de geçerli ve güvendiğiniz bir sertifika olmasını gerektirir.
• Origin sunucunuzda da TLS 1.2 + 1.3 ve modern cipher suite’ler açık olmalı; “nasıl olsa CDN var” diye bu katmanı ihmal etmeyin.

HTTP/2, HTTP/3 ve TLS ilişkisi

Modern web performansının önemli bir kısmı HTTP/2 ve HTTP/3’ten geliyor. Her iki protokol de pratikte TLS ile birlikte düşünülüyor:

• HTTP/2: Genellikle TLS 1.2 ve üzeri ile birlikte kullanılıyor; eski şifre paketlerinin açık olması bazı tarayıcıların HTTP/2’yi devre dışı bırakmasına yol açabiliyor.
• HTTP/3 (QUIC): Protokol tasarımı gereği yalnızca TLS 1.3 üzerinde çalışıyor. Yani HTTP/3’ten faydalanmak istiyorsanız, TLS 1.3 desteği zorunlu.

Bu ilişkinin detaylarını merak ediyorsanız, DCHost üzerinde yayınladığımız HTTP/3 ve web hosting performansı odaklı yazımıza da göz atabilirsiniz. Kısaca: Performans için HTTP/2/3 istiyorsanız, altındaki TLS yapı taşlarını modernleştirmek zorundasınız.

Mixed content ve TLS güncellemeleri: Protokolü güncelledikten sonra unutmayın

TLS sürümlerini ve cipher’ları modernleştirip sertifikaları düzgün kurduğunuz hâlde, tarayıcıda “güvenli değil” uyarısı görebilirsiniz. Bunun yaygın sebebi mixed content, yani HTTPS sayfa içinde HTTP ile çağrılan görsel, JS veya CSS dosyalarıdır.

Özellikle HTTP’den HTTPS’ye geçiş yaptıktan sonra, eski protokole ait URL’lerin kalıp kalmadığını kontrol etmeniz gerekir. Bu konuda adım adım anlatım için SSL sonrası mixed content ve güvensiz içerik hatalarını düzeltme rehberimizi kullanabilirsiniz. Protokol tarafında her şeyi doğru yapsanız bile, içerik tarafındaki bu küçük detaylar kullanıcı deneyimini tamamen gölgeleyebilir.

Denetim, izleme ve otomasyon: TLS konfigürasyonu yaşayan bir dokümandır

Bir kere TLS 1.2 + 1.3’e geçip cipher’ları temizledikten sonra iş bitmiyor. Protokol güncellemeleri, yeni zafiyetler ve tarayıcı davranışlarındaki değişiklikler nedeniyle bu yapılandırmayı periyodik olarak gözden geçirmeniz gerekiyor.

Pratikte önerebileceğimiz yaklaşım:

• 3 veya 6 ayda bir SSL/TLS taraması yapmak (farklı araçlarla)
• Yeni zafiyet duyurularını ve tarayıcı değişikliklerini takip etmek
• Sertifika bitiş tarihlerini izlemek ve otomatik yenileme yapılarını test etmek

Çok sayıda alan adı yöneten ajans veya kurumsal ekipler için, onlarca alan adı için sertifika süre sonu izleme ve otomatik yenileme stratejisi yazımızda anlattığımız gibi merkezi bir takip sistemi kurmak büyük fark yaratıyor.

DCHost ortamında önerdiğimiz SSL/TLS stratejisi

DCHost olarak hem kendi altyapımızda hem de müşterilerimizin projelerinde yıllardır benzer bir yol haritası uyguluyoruz. Özetle önerdiğimiz yaklaşım şöyle:

1. Tüm SSL 2.0, SSL 3.0, TLS 1.0 ve TLS 1.1 sürümlerini kapatın.
2. TLS 1.2 ve TLS 1.3’ü birlikte açık tutun, TLS 1.3’e öncelik verin.
3. CBC, RC4, 3DES gibi zayıf cipher suite’leri tamamen devre dışı bırakın.
4. ECDHE + AES-GCM ve ECDHE + ChaCha20-Poly1305 gibi modern paketlere öncelik verin.
5. HTTP güvenlik başlıklarını (özellikle HSTS) kademeli olarak devreye alın.
6. Sertifika yenileme süreçlerini ACME/otomasyon ile yönetin ve düzenli test edin.

Küçük işletme siteleri için paylaşımlı hosting, daha çok özelleştirme isteyen ekipler için VPS, yüksek trafik ve özel gereksinimleri olan projeler için dedicated veya colocation kullansanız da, bu prensipler değişmiyor. Fark; bu ayarları sizin mi yapacağınız, yoksa DCHost ekibinin sizin için mi yöneteceği.

Özet ve uygulanabilir yol haritası

SSL sertifikası kurmak artık tek başına “güvenli HTTPS” anlamına gelmiyor. Protokol sürümleri, şifre paketleri, HTTP güvenlik başlıkları, CDN/origin ilişkisi ve otomatik yenileme süreçleri; hepsi bir arada ele alınması gereken parçalar. SSL/TLS protokol güncellemelerini erteledikçe, hem tarayıcıların gözünde hem de güvenlik denetimlerinde siteniz daha geri bir noktaya düşüyor.

Gerçekçi bir ilk adım olarak şunları öneriyoruz:

• Mevcut sitenizin TLS sürümü ve cipher durumunu birkaç farklı araçla tarayın.
• Sunucu türünüze (paylaşımlı hosting, VPS, dedicated, colocation) göre hangi ayarları nerede değiştireceğinizi netleştirin.
• Önce test/staging ortamında, ardından da kademeli olarak canlı ortamda TLS 1.2 + 1.3’e geçin.
• Ardından HSTS ve diğer HTTP başlıklarını devreye alarak üst katmanı güçlendirin.

Eğer DCHost üzerinde bir hosting, VPS, dedicated sunucu veya colocation hizmeti kullanıyorsanız, projeye özel TLS stratejisini birlikte tasarlayabiliriz. Mevcut altyapınızı inceleyip hangi sürümlerin kapatılması, hangi modern şifrelerin açılması ve hangi otomasyonun kurulması gerektiğini net bir plan hâline getiriyoruz. Böylece hem bugünün kurallarına uyumlu, hem de birkaç yıl sonra çıkacak yeni TLS güncellemelerine hazır bir HTTPS mimarisine sahip olmuş oluyorsunuz.