SSL/TLS Protokol Güncellemeleri: Sürüm Kapatma, TLS 1.3 ve Modern Şifreler

SSL/TLS protokol güncellemeleri neden tam şimdi bu kadar kritik?

Birçok güvenlik denetiminde aynı tabloyla karşılaşıyoruz: Uygulama tarafında ciddi emek harcanmış, WAF kurulmuş, parola politikaları sıkı; ama sunucu tarafındaki SSL/TLS ayarları yıllardır el değmeden kalmış. Hâlâ TLS 1.0 açık, zayıf şifre paketleri (cipher suite) listede duruyor, hatta ara sıra SSLv3 izine bile rastlıyoruz. Sonuç: Tarayıcı uyarıları, PCI-DSS raporlarında kırmızı satırlar ve gereksiz güvenlik riski.

İşin güzel yanı şu: Doğru bir planla SSL/TLS protokol güncellemeleri hem teknik olarak yönetilebilir, hem de iş tarafında kesinti yaratmadan uygulanabilir. DCHost olarak paylaşımlı hosting, VPS, dedicated ve colocation ortamlarımızda tam da bunu yapıyoruz: Eski protokolleri kademeli kapatıyor, TLS 1.3 ve modern şifreleri varsayılan haline getiriyor, uyumluluk için net bir yol haritası sunuyoruz.

Bu yazıda, sürüm kapatma (deprecation) takvimlerini, TLS 1.3’e geçişte dikkat etmeniz gerekenleri, sunucu konfigürasyonunda pratik örnekleri ve DCHost altyapısında bu süreci nasıl yönettiğimizi adım adım anlatacağım. Amacım; “Hangi sürümü ne zaman kapatmalıyım, hangi şifreleri seçmeliyim, eski istemcilerim ne olacak?” gibi sorularınıza net, uygulanabilir cevaplar vermek.

SSL/TLS protokollerinin evrimi: Hangi sürümler hâlâ oyunda?

Önce tabloyu netleştirelim. Tarihsel sıralama kabaca şöyle:

• SSL 2.0 ve SSL 3.0: Tamamen kullanımdan kalkmış durumda, modern tarayıcılar desteklemiyor.
• TLS 1.0 ve TLS 1.1: Birçok regülasyon ve tarayıcı tarafından “deprecated” (artık güvenli kabul edilmeyen) statüsünde.
• TLS 1.2: Uzun yıllar altın standart oldu, hâlâ yaygın ve güvenli, doğru şifre paketleriyle birlikte kullanıldığı sürece.
• TLS 1.3: Güncel standart, daha hızlı el sıkışma (handshake), daha sade ve daha güvenli tasarım.

Bugün pratikte güvenli ve sürdürülebilir bir mimaride hedefiniz şu olmalı:

• SSL 2.0, SSL 3.0, TLS 1.0 ve TLS 1.1: tamamen kapalı
• TLS 1.2: geçiş dönemi boyunca açık, ama yalnızca modern şifre paketleriyle
• TLS 1.3: varsayılan ve tercih edilen sürüm

Bu tabloyu sadece “güvenlik modası” gibi düşünmeyin. Özellikle e-ticaret ve finans tarafında PCI-DSS gibi çerçeveler TLS 1.0 ve 1.1’i açık bırakmanıza artık izin vermiyor. PCI tarafında daha ayrıntılı bir checklist’e ihtiyacınız varsa, PCI DSS uyumlu e-ticaret hosting rehberimizi de mutlaka gözden geçirin.

Eski sürümleri kapatmak: TLS 1.0, 1.1 ve zayıf şifre paketlerinden kurtulma

Neden TLS 1.0 ve TLS 1.1’i mutlaka kapatmalısınız?

Bu sürümler tasarlandığı dönemde kabul edilebilir güvenlik sunuyordu; ama bugün bilinen pek çok açık var:

• POODLE, BEAST, CRIME gibi saldırı tekniklerine karşı zayıf kalıyorlar.
• CBC tabanlı eski şifre paketlerini devreden çıkarmak bu sürümlerle pratikte mümkün değil.
• Modern tarayıcılar ve kütüphaneler bu sürümleri artık ya tamamen bırakıyor ya da uyarı veriyor.

Bu nedenle DCHost altyapısında paylaşımlı hosting ve yeni açılan VPS/dedicated sunucularda TLS 1.0 ve 1.1’i varsayılan olarak kapalı tutuyoruz. Eski bir özel uygulama sebebiyle bu sürümlere ihtiyaç duyan müşterilerimizle ise, sınırlı erişim senaryoları ve IP kısıtlamaları gibi ek güvenlik önlemleriyle geçici çözümler üretiyoruz.

Şifre paketlerini sadeleştirmek: RC4, 3DES ve eski CBC modlarına veda

Sürüm kadar önemli bir başka nokta da cipher suite seçimi. Güçlü bir TLS 1.2 bile zayıf şifre paketleriyle kullanılırsa ciddi risk taşıyabilir. Artık listenizden tamamen çıkarmanız gerekenler:

• RC4 içeren tüm şifre paketleri
• 3DES tabanlı şifre paketleri
• MD5 kullanan kombinasyonlar
• RSA key exchange (PFS sağlamayan) içeren eski paketler

Yerine odaklanmanız gerekenler ise:

• ECDHE tabanlı anahtar değişimi (Forward Secrecy için kritik)
• AES-GCM ve CHACHA20-POLY1305 gibi modern şifreler

Bunları Nginx tarafında sade bir şekilde şöyle görebilirsiniz:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
             ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:
             ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256";

Bu konuya daha derin girmek isterseniz, hem Nginx hem Apache için hazır örnek konfigürasyonlar paylaştığımız TLS 1.3 ve modern şifre ayarları rehberimize göz atabilirsiniz.

TLS 1.3: Daha hızlı, daha sade, daha güvenli

TLS 1.3’ü sadece “yeni sürüm” olarak değil, protokol tasarımında ciddi bir sadeleşme ve güvenlik iyileştirmesi olarak görmek gerekiyor.

Performans tarafı: Daha az tur, daha az gecikme

Önce işin pratik faydasından bahsedelim. TLS 1.2’de tipik bir HTTPS bağlantısı için tam el sıkışma 2 RTT (round-trip) gerektirirken, TLS 1.3 bunu 1 RTT’ye indiriyor. Bu da özellikle yüksek gecikmeli bağlantılarda (mobil, farklı kıta ziyaretçileri) TTFB tarafında gözle görülür bir iyileşme sağlayabiliyor.

DCHost tarafında HTTP/2 ve HTTP/3 desteğiyle beraber TLS 1.3’ü etkin kullanıyoruz. Bu üçlü (TLS 1.3 + HTTP/2 + HTTP/3) birleştiğinde gecikmeyi azaltma ve sayfa yükleme sürelerini iyileştirme potansiyeli oldukça yüksek. Bu etkinin SEO ve Core Web Vitals tarafına yansımasını merak ediyorsanız, HTTP/2 ve HTTP/3 desteğinin SEO’ya etkilerini anlattığımız yazıyı da inceleyebilirsiniz.

Güvenlik tarafı: Eski problemleri kökten temizlemek

TLS 1.3’ün en güzel yanı, pek çok “opsiyonel ama riskli” özelliği tamamen protokolden çıkarması:

• Eski RSA key exchange yöntemleri kaldırıldı; PFS sağlayan ECDHE tabanlı tasarım zorunlu hale geldi.
• CBC modlu eski şifreler yerine AES-GCM ve CHACHA20-POLY1305 gibi modern AEAD şifreleri kullanılıyor.
• Protokol karmaşıklığı azaltıldığı için yanlış yapılandırma riskleri de düşüyor.

Bu sayede, TLS 1.3’ü doğru etkinleştirdiğinizde protokol seviyesinde bir sürü “zayıf halka”yı otomatik olarak oyundan çıkarmış oluyorsunuz. Elbette hâlâ sertifika yönetimi, HTTP güvenlik başlıkları ve uygulama seviyesindeki hatalar gibi konulara dikkat etmek gerekiyor; ama protokol zemininiz çok daha sağlam oluyor.

Sadece protokol yetmez: Sertifika zinciri, OCSP Stapling ve HSTS

Güçlü bir TLS 1.3 konfigürasyonu bile, hatalı sertifika zinciri veya eksik tarayıcı işaretlemeleri yüzünden beklediğiniz etkiyi vermeyebilir. Özellikle üç başlık kritik:

Sertifika zinciri ve ara sertifikalar

Sertifika sağlayıcınız size genellikle şunları veriyor:

• Sunucu sertifikanız (leaf certificate)
• Ara sertifikalar (intermediate CA)
• Kök sertifikalar (root CA) – bunlar genelde işletim sistemlerinde veya tarayıcılarda zaten yüklü

Sunucuda doğru zinciri kurmazsanız bazı eski istemcilerde “certificate not trusted” ya da zincir hatası uyarıları alabilirsiniz. Özellikle özel mobil uygulamalar, gömülü cihazlar ve kurumsal ağlarda bu sıkça karşımıza çıkıyor. DCHost yönetilen hizmetlerinde bu zincirleri otomatik ve düzenli biçimde güncel tutuyoruz; kendi VPS’inizi yönetiyorsanız bunu elinizle takip etmeniz gerekiyor.

OCSP Stapling ve tarayıcı tarafı doğrulama

OCSP, istemcinin sertifikanın hâlâ geçerli olup olmadığını CA’ya sormasını sağlayan bir mekanizma. Bunu doğrudan tarayıcıya bırakırsanız:

• Her bağlantıda gecikme yaşanabilir.
• CA tarafındaki sorunlar sitenizin de ulaşılabilirliğini etkileyebilir.

OCSP Stapling etkinleştirildiğinde bu sorguları sunucu tarafında önceden yapıp sonucu TLS el sıkışmasına “ekliyorsunuz”. Böylece hem hız kazanıyor hem de CA tarafındaki anlık sorunların etkisini azaltıyorsunuz.

HSTS ve diğer HTTP güvenlik başlıkları

Protokol seviyesinde ne yaparsanız yapın, “http://” ile gelen trafiği otomatik olarak HTTPS’e zorlamıyorsanız, kullanıcılarınız bir süre daha şifresiz bağlantı riskine maruz kalabilir. Burada devreye HSTS (HTTP Strict Transport Security) ve diğer HTTP başlıkları giriyor. Doğru kullanım için HSTS ve diğer HTTP güvenlik başlıklarını doğru kurma rehberimizi incelemenizi öneririz.

Sunucu tarafında adım adım SSL/TLS güncelleme planı

Teoride her şey güzel; peki pratikte, bir üretim ortamını riske atmadan bu geçiş nasıl yapılır? DCHost olarak müşterilerimize önerdiğimiz tipik yol haritası şöyle:

1. Envanteri çıkarın: Hangi sürümler nerede açık?

Önce elinizdeki durumu görün:

• Hangi domain hangi sunucuda ve hangi TLS sürümleri açık?
• HTTP/2 destekliyor musunuz? HTTP/3 denemeleri var mı?
• Hangi sertifika sağlayıcılarını ve ACME istemcilerini kullanıyorsunuz?

Bu aşamada ssllabs.com gibi çevrimiçi testler ve komut satırında openssl s_client gibi araçlar işinizi kolaylaştırır. DCHost müşterileri, kontrol panelleri ve izleme araçları üzerinden bu bilgilerin çoğunu birkaç dakikada toplayabiliyor.

2. Hedef mimariyi belirleyin

Örneğin şu hedefi koyabilirsiniz:

• 3 ay içinde: TLS 1.0 ve 1.1 tamamen kapalı, TLS 1.2 + TLS 1.3 aktif
• 6–9 ay içinde: Eski istemciler analiz edildikten sonra, gerekirse sadece belirli alt alanlarda TLS 1.2 desteği bırakmak
• Ortak konfigürasyon: Modern cipher listesi, OCSP stapling, HSTS ve HTTP/2 zorunlu

Özellikle ajanslar veya çoklu müşteri barındıran yapılar için bu hedefleri önceden paylaşmak, “eski Android cihazlar”, “kurumsal intranet” gibi özel senaryolar için istisna planlaması yapmanızı sağlar.

3. Staging ortamında test edin

Doğrudan canlıya dokunmak yerine, DCHost üzerinde küçük bir VPS ya da ayrı bir staging alanında yeni TLS ayarlarınızı test etmek çok daha güvenli olacaktır. Özellikle:

• HTTP/2 ve HTTP/3 ile uyumluluk
• Eski kütüphane kullanan backend servislerin (örneğin eski Java veya .NET uygulamaları) yeni TLS sürümleriyle bağlantı kurabilmesi
• Load balancer veya reverse proxy arkasında TLS sonlandırmanın doğru çalışması

Gerekirse, staging domaininizi sadece belirli IP bloklarına açarak gerçek kullanıcı trafiğini etkilemeden pilot testler yapabilirsiniz.

4. Üretime kademeli geçiş

Canlıda değişiklik yaparken önerdiğimiz yaklaşım:

1. Önce şifre paketlerini sadeleştirin, ama TLS sürümlerini hemen kapatmayın.
2. Log’lar üzerinden başarısız el sıkışma (handshake) oranını takip edin.
3. Sonrasında TLS 1.0 ve 1.1’i kapatın; yine log’lar ve hata raporlarıyla birkaç gün izleyin.
4. Son adımda TLS 1.3’ü etkinleştirin ve performans/güvenlik taramalarını tekrar çalıştırın.

DCHost tarafında, yüksek trafikli projelerde bu geçişleri çoğu zaman gece düşük trafikli saatlerde ve ayrıntılı geri dönüş planıyla (rollback) gerçekleştiriyoruz. Kendi VPS veya dedicated sunucunuzda da benzer bir yaklaşımı izlemeniz, olası uyumluluk sorunlarını minimumda tutar.

Uygulama katmanında dikkat etmeniz gerekenler

SSL/TLS protokol güncellemeleri sadece web sunucusunun konfigürasyonu değildir; uygulama katmanında da etkileri vardır.

1. Mixed content ve içerik güvenliği

HTTP’den HTTPS’e geçiş yaparken veya sertifika yenilerken en sık gördüğümüz problem, mixed content uyarıları. Sayfanız HTTPS ile açılıyor ama içindeki bir CSS, JS veya görsel “http://” ile çağrılıyorsa tarayıcı bunu güvensiz olarak işaretliyor. Bu, TLS 1.3’e geçmiş olsanız bile kullanıcıya “tam güvenli” görünmeyen bir site demek.

Bu konuyu detaylı anlattığımız mixed content hatalarını düzeltme rehberimizi adım adım uyguladığınızda, protokol tarafındaki iyileştirmelerin kullanıcıya da net biçimde yansıdığını göreceksiniz.

2. Eski kütüphaneler ve API istemcileri

Web tarayıcıları genelde TLS 1.2 ve 1.3’ü sorunsuz destekliyor; esas sürprizler genelde şuralardan geliyor:

• Eski PHP, Java veya .NET sürümleriyle yazılmış backend servisler
• Yıllar önce derlenmiş masaüstü uygulamaları
• IoT cihazları veya gömülü sistemler

Bu istemciler, yeni protokol ve şifre paketlerini desteklemeyebiliyor. TLS 1.0 ve 1.1’i kapatmadan önce, sunucunuzun erişim loglarını analiz ederek bu tür eski client fingerprint’lerini tespit etmekte fayda var. Gerekirse bu sistemler için geçici bir legacy alt alan adı (örneğin legacy-api.example.com) tanımlayıp daha uzun vadeli bir geçiş planı yapabilirsiniz.

3. HTTP/2 ve HTTP/3 ile entegrasyon

TLS ayarlarını güncellediğinizde, HTTP/2 ve HTTP/3’ü de devreye almanız neredeyse her zaman mantıklı. Zaten modern tarayıcılar, HTTPS üzerinden gelen sitelerde HTTP/2’yi varsayılan olarak tercih ediyor. DCHost altyapısında HTTP/2 desteği standart, HTTP/3 ise giderek daha fazla projede etkinleştirdiğimiz bir özellik.

HTTP/2/3, TLS 1.3 ve modern şifre paketleriyle bir arada düşünülmeli. Bu dengeyi doğru kurduğunuzda hem güvenlik testlerinden temiz çıkarsınız hem de performans tarafında Core Web Vitals metriklerine gözle görülür katkı sağlarsınız.

Sertifika yönetimi ve otomasyon: Güncellemeleri insan hatasından kurtarmak

Protokolü güncellediniz, şifre paketlerini sadeleştirdiniz; peki sertifika süreleri, yenilemeler, ara sertifika değişimleri? Bunları insan takvimine bıraktığınız sürece, “sertifika süresi bitti, site çöktü” senaryosunu tamamen hayatınızdan çıkaramıyorsunuz.

Bu yüzden, DCHost olarak hem paylaşımlı hosting hem de VPS/dedicated müşterilerimizde ACME tabanlı otomatik sertifika yenileme süreçlerini teşvik ediyoruz. Özellikle çok alan adlı ve çok kiracılı yapılarda ACME + DNS-01 challenge kombinasyonuyla sertifika yönetimini büyük ölçüde otomatikleştirmek mümkün. Detaylarını SSL sertifika otomasyonu ve ACME inovasyonları yazımızda adım adım anlattık.

Otomasyonun protokol güncellemeleriyle ilişkisi net: Sertifika tarafını güvenilir biçimde otomatize ettiğinizde, eliniz rahatlar; enerjinizi TLS 1.3’e geçiş, HTTP/3 aktivasyonu, HSTS gibi daha stratejik geliştirmelere ayırabilirsiniz.

DCHost altyapısında SSL/TLS protokol güncellemelerini nasıl yönetiyoruz?

DCHost olarak hem kendi çekirdek altyapımızda hem de müşterilerimizin projelerinde SSL/TLS’i “tek seferlik kurulum” değil, sürekli bakım gerektiren bir bileşen olarak ele alıyoruz. Uyguladığımız temel prensipler:

• Yeni açılan tüm hosting, VPS ve dedicated sunucularda TLS 1.0 ve 1.1 kapalı, TLS 1.2 ve 1.3 aktif.
• Varsayılan şifre paketleri, güncel tarayıcı ve güvenlik rehberleriyle uyumlu modern listelerden seçiliyor.
• HTTP/2 desteği varsayılan, HTTP/3 desteği ise proje ihtiyacına göre devreye alınabiliyor.
• OCSP Stapling, HSTS ve benzeri gelişmiş özellikler, özellikle e-ticaret ve kritik kurumsal projelerde standart hale getiriliyor.
• Periyodik güvenlik taramaları ve dış bağımsız testler ile konfigürasyonlarımızı düzenli olarak gözden geçiriyoruz.

Kendi VPS veya dedicated sunucusunu yöneten müşterilerimiz için de, teknik dökümantasyon, hazır konfigürasyon örnekleri ve gerektiğinde doğrudan danışabileceğiniz bir ekip ile bu geçişleri birlikte planlıyoruz. İsterseniz sadece “rehberlik” şeklinde, isterseniz de “tam yönetilen” modelle tüm süreci bizim üstlenmemizi tercih edebilirsiniz.

Özet ve net yol haritası: Şimdi ne yapmalısınız?

Anlatılanları bir eylem planına dökmek gerekirse, bugün itibarıyla atmanız gereken adımlar kabaca şöyle:

• Tüm siteleriniz ve servisleriniz için mevcut TLS sürümlerini ve cipher listelerini tespit edin.
• En geç kısa vadede SSLv3, TLS 1.0 ve TLS 1.1’i tamamen kapatacak bir takvim belirleyin.
• TLS 1.2’yi sadece modern şifrelerle kullanın, TLS 1.3’ü etkinleştirerek performans ve güvenlik kazanımı sağlayın.
• Sertifika zincirinizi, OCSP stapling ve HSTS gibi özelliklerle tamamlayın; detaylar için TLS 1.3 rehberimizi referans alın.
• Mixed content, HTTP güvenlik başlıkları ve benzeri uygulama katmanı konularını HTTP güvenlik başlıkları rehberi ve mixed content yazımız ile tamamlayın.
• Sertifika yenileme ve dağıtım süreçlerinizi manuel işlerden kurtarmak için ACME tabanlı otomasyon yaklaşımlarını devreye alın.

DCHost olarak, ister basit bir kurumsal site, ister yoğun trafikli bir WooCommerce mağazası, ister çok kiracılı bir SaaS uygulaması olsun; SSL/TLS protokol güncellemelerini projelerinizin kesintisiz bir parçası haline getirmek için yanınızdayız. Mevcut altyapınızı birlikte analiz etmek, hangi sürümü ne zaman kapatmanız gerektiğini net bir planla ortaya koymak veya TLS 1.3 + HTTP/3 gibi modern özellikleri devreye almak isterseniz, destek ekibimizle iletişime geçmeniz yeterli. Güvenlik tarafında “yarım kalan” işleriniz ne kadar az olursa, hem ekiplerinizin hem kullanıcılarınızın geceleri o kadar rahat uyuduğunu göreceksiniz.