SSL/TLS Protokol Güncellemeleri: Modern HTTPS İçin Net Yol Haritası

Bugün bir web projesi planlarken ya da mevcut bir altyapının güvenlik denetimini yaparken, masaya mutlaka şu soru geliyor: “Sunucularımızın SSL/TLS tarafı gerçekten güncel mi?” Tarayıcılar, ödeme sağlayıcıları, regülasyonlar ve güvenlik topluluğu; hepsi aynı yöne itiyor: eski protokolleri kapat, TLS 1.2’yi sertleştir, TLS 1.3’ü etkinleştir. Fakat bunu yanlış sırayla ya da eksik testle yaptığınızda, bir yandan güvenliği artırırken diğer yandan beklenmedik erişim sorunları, uyumluluk problemleri ve müşteri şikâyetleriyle karşılaşmak mümkün.

Bu yazıda DCHost ekibi olarak, sahada her gün uğraştığımız konuyu detaylı ama anlaşılır şekilde ele alacağız: SSL/TLS protokol güncellemeleri. Hangi sürümler artık tarihe karıştı, TLS 1.2’yi nasıl güvenli konfigüre etmelisiniz, TLS 1.3 size ne kazandırır, HTTP/2 ve HTTP/3 ile ilişkisi nedir ve tüm bunları Nginx/Apache üzerinde pratik olarak nasıl uygularsınız, adım adım konuşacağız. Amacımız; hem geliştirici hem sistem yöneticisi hem de teknik karar verici olarak, elinizde net bir yol haritası olması. Böylece bir sonraki güvenlik denetiminde ya da PCI DSS benzeri bir uyumluluk sürecinde, TLS tarafını “tamam” kutusuna gönül rahatlığıyla işaretleyebilin.

SSL/TLS Protokolleri Ne İş Yapar ve Neden Sık Güncellenir?

SSL/TLS kavramı çoğu zaman “SSL sertifikası” ile karıştırılıyor. Oysa sertifika, bu işin sadece kimlik doğrulama kısmı. Protokol dediğimiz şey ise tarayıcı ile sunucu arasında nasıl şifreli bağlantı kurulacağını, hangi sürümün ve hangi şifre paketlerinin (cipher suite) kullanılacağını tanımlayan kurallar bütünü.

TLS el sıkışma (handshake) sürecinde özetle şu adımlar gerçekleşir:

• Tarayıcı, desteklediği TLS sürümlerini ve şifre paketlerini sunucuya söyler.
• Sunucu, kendi destekledikleriyle kesişen en güçlü kombinasyonu seçer.
• Sertifika doğrulaması yapılır, anahtar değişimi olur ve şifreli kanal kurulur.

Güvenlik araştırmaları, saldırı teknikleri ve donanım gücü geliştikçe; eskiden “yeterince güvenli” kabul edilen algoritmalar, protokol davranışları veya sürümler zamanla zayıf hale geliyor. Bu nedenle TLS dünyası oldukça hareketli: yeni sürümler ekleniyor, eskileri devre dışı bırakılıyor, bazı şifreler yasaklanıyor, bazıları varsayılan hâle geliyor.

Daha önce genel çerçeveyi SSL/TLS güvenlik güncellemeleri ne zaman ve nasıl yapılmalı yazımızda anlatmıştık. Bu makalede odağı biraz daha daraltıp, protokol seviyesindeki değişiklikleri ve bunların güncel sunucu yapılandırmalarına etkisini konuşacağız.

Eski Sürümlerin Sonu: SSL 3.0, TLS 1.0 ve 1.1 Neden Artık Kullanılmamalı?

Önce kötü haberlerle başlayalım: SSL 2.0, SSL 3.0, TLS 1.0 ve TLS 1.1 artık modern dünyada güvenli kabul edilmiyor. Tarayıcı üreticileri bu sürümleri yıllardır kademeli olarak devre dışı bırakıyor, ödeme altyapıları da PCI DSS gereği bunları kabul etmiyor.

Başlıca sebepler:

• Bilinen açıklar: POODLE, BEAST, Lucky13 gibi saldırılar, özellikle SSL 3.0 ve erken TLS sürümlerinin blok şifreleme (CBC) kullanımındaki zayıflıkları hedef alıyor.
• Zayıf şifreler: RC4, 3DES gibi algoritmalar günümüz donanımları karşısında kırılmaya çok daha yakın ve çoğu güvenlik dokümanında “kullanmayın” listesinde.
• Standart otoritelerin tavsiyeleri: IETF, ödeme kuruluşları ve büyük tarayıcılar, asgari seviye olarak TLS 1.2 kullanmanızı öneriyor; pek çok ortamda zorunlu bile tutuluyor.

Bunun pratik sonucu şu: Yeni bir hosting veya VPS kuruyorsanız, SSLv3, TLS 1.0 ve 1.1’i tamamen kapatmanız artık varsayılan yaklaşım olmalı. Eski bir sistemde bunlar hala açıksa, güvenlik testlerinde kırmızı bayrak yemeye hazır olun.

Protokol güncellemeleri kadar, sertifika tarafındaki değişiklikler de önemli. Bu konuya dair daha geniş bir bakışı SSL sertifika güvenlik güncellemeleri için hazırladığımız yol haritası yazımızda bulabilirsiniz.

TLS 1.2: Hâlâ Ana Taşıyıcı, Ama Doğru Konfigüre Edilirse

Bugün üretim ortamlarında hâlâ en yaygın kullanılan sürüm TLS 1.2. Modern tarayıcıların tamamı destekliyor, ödeme altyapıları ile uyumlu, HTTP/2 ile sorunsuz çalışıyor. Fakat “sadece TLS 1.2 açık” demek tek başına güvenli olduğunuz anlamına gelmez; hangi şifre paketlerine izin verdiğiniz en az sürüm kadar kritik.

TLS 1.2 İçin Önerilen Şifre Paketleri

Genel prensip: AEAD (örneğin AES-GCM, CHACHA20-POLY1305) kullanan, ileri gizlilik (PFS) sağlayan şifre paketlerini açık bırakmak; RC4, 3DES, düz AES-CBC gibi eskimiş seçenekleri kapatmak.

Örnek Nginx konfigürasyonu (yalnızca TLS 1.2 için):

ssl_protocols TLSv1.2;

ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:
             ECDHE-RSA-AES256-GCM-SHA384:
             ECDHE-ECDSA-AES128-GCM-SHA256:
             ECDHE-RSA-AES128-GCM-SHA256:
             ECDHE-ECDSA-CHACHA20-POLY1305:
             ECDHE-RSA-CHACHA20-POLY1305';

ssl_prefer_server_ciphers on;

Bu liste, modern tarayıcıları hedefleyen, RC4 ve 3DES içermeyen, PFS sağlayan güvenli bir temel örnek. Gerçek hayatta, desteklemek zorunda olduğunuz istemci kitlesine göre küçük oynamalar yapabilirsiniz.

Eski İstemcilerle Uyum Dengesi

Bazı kurum içi uygulamalar, eski mobil cihazlar veya gömülü sistemler halen TLS 1.0/1.1 ile sınırlı olabiliyor. Burada iki farklı strateji öne çıkıyor:

• Ayrı endpoint: Eski istemciler için sadece iç ağda erişilebilen, daraltılmış bir domain veya IP üzerinden, minimum izinli TLS 1.0/1.1 desteği sunmak.
• Tam ayrıştırma: Bu tip sistemleri internetten tamamen yalıtmak ve VPN gibi ek katmanlar ile korumak.

Genel internet trafiğine açık web siteleri için ise tavsiyemiz net: en düşük sürümü TLS 1.2 yapın. DCHost platformunda son yıllarda yeni kurulan projelerin neredeyse tamamı bu politikayla ilerliyor.

TLS 1.3 ile Gelen Yenilikler: Daha Hızlı, Daha Basit, Daha Güçlü

TLS 1.3, sadece “yeni bir sürüm” değil; protokol mantığı açısından da ciddi bir temizlik. Eski ve riskli özellikler tamamen atıldı, şifre paketleri sadeleştirildi, el sıkışma tur sayısı azaltıldı.

Performans: Daha Az Tur, Daha Kısa El Sıkışma

TLS 1.2’de standart bağlantı kurulumu genelde 2 el sıkışma turu (RTT) gerektirirken, TLS 1.3 bunu 1 RTT’ye indiriyor. Bu da özellikle mobil ve yüksek gecikmeli bağlantılarda sayfaların “ilk byte” süresini (TTFB) hissedilir biçimde iyileştirebiliyor.

Teknik detaylarını ve Nginx/Apache tarafında pratik kurulum adımlarını TLS 1.3 ve modern şifrelerin mutfağını anlattığımız rehberde oldukça detaylı işlemiştik. Burada daha çok protokol güncelleme perspektifinden bakacağız.

Güvenlik: Eski Yüklerden Kurtulma

TLS 1.3’te şu önemli değişiklikler var:

• RSA key exchange kaldırıldı: Artık sadece ECDHE gibi ileri gizlilik (PFS) sağlayan anahtar değişimi yöntemleri kullanılıyor.
• Zayıf şifreler atıldı: RC4, 3DES, AES-CBC tabanlı birçok seçenek tarihe karıştı; geriye AES-GCM ve CHACHA20-POLY1305 gibi modern şifreler kaldı.
• Handshake sadeleştirildi: Daha az mesaj, daha az karmaşıklık, daha küçük saldırı yüzeyi.

Bunların hepsi, “doğru şifre paketini seçtim mi?” gibi soruları protokol seviyesinde büyük ölçüde çözmenizi sağlıyor. Yani TLS 1.3 etkinleştirdiğinizde, elinizde “daha az ayar, daha az risk” denklemine yakın bir yapı oluyor.

0-RTT (Early Data) Konusu

TLS 1.3 ile gelen 0-RTT özelliği, istemcinin geçmiş bir bağlantıya dayanarak ilk isteğini beklemeden (ek RTT olmadan) göndermesine imkân veriyor. Fakat 0-RTT, yeniden oynatma (replay) riskleri nedeniyle herkese açık web uygulamalarında genelde kapalı tutuluyor.

Özetle:

• Statik içerik sunan, idempotent (tekrarlanabilir) GET istekleri için özel senaryolarda düşünülebilir.
• Genel amaçlı web uygulamalarında (login, ödeme, form gönderimi vs.) 0-RTT’yi devre dışı bırakmak daha güvenli bir yaklaşım.

Protokol Güncellemeleri Web Sunucunuza Nasıl Yansır?

Teoride “TLS 1.2/1.3 kullanın” demek kolay; asıl iş Nginx, Apache ve işletim sistemi seviyesinde bu politikayı doğru uygulamada. Çünkü:

• İşletim sistemi ve OpenSSL sürümü, destekleyebileceğiniz en yüksek TLS sürümünü belirler.
• Web sunucusu (Nginx/Apache) konfigürasyonu, hangi sürümlere ve şifre paketlerine izin vereceğinizi tanımlar.
• Üstündeki CDN, WAF veya ters proxy katmanları da kendi TLS politikalarına sahip olabilir.

Nginx İçin Örnek TLS 1.2 + 1.3 Konfigürasyonu

Aşağıdaki örnek, modern bir Linux + Nginx + güncel OpenSSL ortamında sık kullandığımız temel yapı taşlarından biri:

ssl_protocols TLSv1.2 TLSv1.3;

ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:
             ECDHE-RSA-AES256-GCM-SHA384:
             ECDHE-ECDSA-AES128-GCM-SHA256:
             ECDHE-RSA-AES128-GCM-SHA256:
             ECDHE-ECDSA-CHACHA20-POLY1305:
             ECDHE-RSA-CHACHA20-POLY1305';

# TLS 1.3 için OpenSSL kendisi modern şifre setini uygular
ssl_prefer_server_ciphers on;

ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;

Bu yapı:

• Eski TLS sürümlerini tamamen kapatır.
• TLS 1.2 için güvenli AES-GCM ve CHACHA20 şifrelerini etkin bırakır.
• TLS 1.3 için OpenSSL’in modern varsayılanlarını kullanır.

Eğer HTTP/2 de kullanıyorsanız, listen 443 ssl http2; satırını eklemeyi unutmayın. HTTP/2’nin TLS gereksinimlerine birazdan ayrıca değineceğiz.

Apache İçin Örnek TLS Konfigürasyonu

Apache’de benzer bir yaklaşım şu şekilde uygulanabilir:

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1

SSLCipherSuite         ECDHE-ECDSA-AES256-GCM-SHA384:
                       ECDHE-RSA-AES256-GCM-SHA384:
                       ECDHE-ECDSA-AES128-GCM-SHA256:
                       ECDHE-RSA-AES128-GCM-SHA256:
                       ECDHE-ECDSA-CHACHA20-POLY1305:
                       ECDHE-RSA-CHACHA20-POLY1305

SSLHonorCipherOrder    on

TLS 1.3 desteği Apache’nin ve altında çalışan OpenSSL’in sürümüne bağlıdır. Eski bir dağıtım kullanıyorsanız, bazen tek çare işletim sistemi yükseltmesi yapmaktır. DCHost üzerinde yeni nesil VPS ve dedicated sunucularımızda kullandığımız modern Linux dağıtımları, TLS 1.3 desteğini varsayılan olarak getiriyor.

İşletim Sistemi ve OpenSSL Sürümü

Pek çok ortamda karşılaştığımız durum şu: Uygulama güncel, Nginx/Apache nispeten güncel ama sunucunun OpenSSL kütüphanesi çok eski. Sonuç olarak TLS 1.3’ü açmak mümkün olmuyor. Protokol güncellemesi planlarken mutlaka şu soruları sorun:

• Sunucudaki OpenSSL sürümü nedir? TLS 1.3 destekliyor mu?
• Web sunucusu (Nginx/Apache) bu OpenSSL sürümü ile derlenmiş mi?
• Uygulama yığını (PHP-FPM, Node.js, Java vs.) TLS güncellemelerinden etkileniyor mu?

Bu yüzden biz DCHost tarafında, altyapı güncellemelerini sadece tek bir katmana değil; OS + OpenSSL + web sunucusu üçlüsüne birlikte bakarak planlıyoruz.

Protokol Güncellemeleri ile HTTP/2 ve HTTP/3 İlişkisi

SSL/TLS protokol sürümünüz, hangi HTTP sürümlerini ne kadar verimli kullanabileceğinizi de doğrudan etkiler.

HTTP/2 ve TLS Gereksinimleri

HTTP/2, teknik olarak TLS olmadan da çalışabilir; fakat tarayıcı dünyasında fiili standart şu: tarayıcılar HTTP/2’yi TLS üzerinden kullanıyor. Ayrıca büyük tarayıcılar, HTTP/2 için bazı zayıf şifreleri ve eski TLS sürümlerini reddediyor.

Pratikte şu kurallara uymak iyi bir başlangıç:

• HTTP/2 için minimum TLS 1.2 kullanın.
• RC4, 3DES ve zayıf AES-CBC şifrelerini devre dışı bırakın.
• ECDHE + AES-GCM veya CHACHA20-POLY1305 kombinasyonlarını tercih edin.

HTTP/2’nin performans etkilerini ve Nginx tarafında etkinleştirme adımlarını, hızlı ve güvenli HTTPS için hazırladığımız Nginx rehberinde daha detaylı anlattık.

HTTP/3 (QUIC) ve TLS 1.3

HTTP/3, TCP yerine QUIC adı verilen UDP tabanlı yeni bir taşıma protokolü üzerinde çalışıyor. QUIC’in güvenlik katmanı ise doğrudan TLS 1.3 protokolüne dayanıyor. Yani HTTP/3 kullanmak istiyorsanız, protokol seviyesinde otomatik olarak TLS 1.3 dünyasına adım atmış oluyorsunuz.

HTTP/3’ün web hosting performansına etkilerini, hangi senaryolarda fark yarattığını merak ediyorsanız, HTTP/3 protokolünün hosting performansına etkilerini anlattığımız yazıya mutlaka göz atın.

Özetle:

• HTTP/3 = QUIC + TLS 1.3 (başka sürüm yok).
• HTTP/3 için altyapınızı hazırlarken, önce mevcut TLS 1.2 konfigürasyonunuzu temizleyip, ardından TLS 1.3’ü sorunsuz devreye almanız mantıklı.
• CDN veya ters proxy kullanıyorsanız, HTTP/3 terminasyonu çoğu zaman bu katmanda gerçekleşir; origin (kaynak) sunucunuz ise TLS 1.2/1.3 ile çalışmaya devam eder.

SSL/TLS Protokol Güncellemeleri İçin Pratik Yol Haritası

Saha deneyimimiz gösteriyor ki, en çok sorun teknik detaylardan değil, yanlış sıralanmış adımlardan çıkıyor. Aşağıdaki yol haritası, küçük bir web sitesinden büyük bir SaaS altyapısına kadar çoğu senaryoda iş görüyor.

1. Envanter Çıkarın: Nerede, Hangi TLS Sürümü Kullanılıyor?

Önce elinizde ne olduğunu bilin:

• Hangi domain’leriniz hangi sunucularda yayın yapıyor?
• Bu sunucuların işletim sistemi sürümleri ve OpenSSL versiyonları nedir?
• Üstünde hangi web sunucusu (Nginx, Apache, vs.) ve hangi TLS konfigürasyonu var?

Dış dünyadan bakarak bunu görmek için openssl s_client ile testler yapabilir, online TLS test araçlarını kullanabilirsiniz. İç ağdaki servisler için ise mümkünse konfigürasyon dosyalarını doğrudan incelemek daha net sonuç verir.

2. Hedef Politikanızı Belirleyin

Genel bir “en iyi uygulama” politikası kabaca şöyle olabilir:

• Sürüm: TLS 1.2 + TLS 1.3 açık, diğerleri kapalı.
• Şifreler: PFS sağlayan ECDHE tabanlı, AES-GCM / CHACHA20-POLY1305.
• HTTP sürümleri: Uygunsa HTTP/2 ve zamanla HTTP/3 desteği.

Eğer özel regülasyonlarınız, eski cihazlarınız veya kurumsal entegrasyonlarınız varsa; bunları da hesaba katarak istisnaları dokümante edin. Böylece ileride “bu neden açık kalmıştı?” sorusuna net cevap verebilirsiniz.

3. Staging Ortamında Test Edin

Protokol güncellemelerini doğrudan canlıya uygulamak, özellikle yüksek trafikli sitelerde riskli olabilir. Bunun yerine:

• Mevcut konfigürasyonu klonlayıp staging ortamı kurun.
• Yeni TLS ayarlarını önce burada deneyin.
• Otomatik testler (integration test), manuel kullanıcı senaryoları ve tarayıcı testleri yapın.

Bu yaklaşım, HTTP güvenlik başlıkları, HSTS ve CSP gibi ek sıkılaştırmalar ile birlikte uygulandığında çok daha güvenli bir geçiş süreci sağlar.

4. Canlıya Kontrollü Geçiş ve Geri Dönüş Planı

Canlıya alırken şu adımlar kritik:

• Konfigürasyon değişikliğinden önce mutlaka sürüm kontrollü yedek alın (git, rsync vs.).
• Önce daha az kritik sitelerde yeni TLS politikasını deneyin.
• Logları ve hata oranlarını yakından izleyin; beklenmedik istemci hataları için alarmlar kurun.
• Bir sorun çıkarsa geri dönüş planınız hazır olsun: eski konfigürasyonu hızla geri alabilmelisiniz.

DCHost altyapısında, TLS konfigürasyonu değişikliklerini genellikle bakım pencereleri içinde, planlı ve geri dönüş adımları tanımlı olacak şekilde yapıyoruz. Kendi ortamınızda da benzer bir disiplinle ilerlemek, kesinti riskini ciddi şekilde azaltır.

DCHost Altyapısında TLS Protokol Politikamız

Bu kadar teoriden sonra, biz DCHost olarak kendi altyapımızda neler yaptığımızdan da kısaca bahsedelim:

• Yeni açılan hosting, VPS ve dedicated sunucularda varsayılan olarak TLS 1.2 ve TLS 1.3 etkin, eski sürümler kapalı gelir.
• Güncel Linux dağıtımları ve OpenSSL sürümleri kullanarak TLS 1.3 desteğini standart hâle getiriyoruz.
• Müşterilerimiz, ihtiyaç hâlinde kendi Nginx/Apache konfigürasyonlarını daha sıkı veya daha esnek hale getirebiliyor; biz de bu süreçte danışmanlık sağlıyoruz.
• Otomatik SSL yenileme, ACME entegrasyonları ve sertifika yönetimi için de özel çözümler sunuyoruz; detaylı anlatımı SSL sertifika otomasyonundaki yenilikler yazımızda bulabilirsiniz.

Yeni bir proje planlıyorsanız veya mevcut sitenizin TLS tarafı sizi tedirgin ediyorsa, DCHost üzerinde kuracağınız modern bir hosting veya VPS altyapısında; bu yazıda anlattığımız protokol politikalarını baştan doğru kurgulamak çok daha kolay olacaktır.

Özet ve Son Adım: Protokol Güncellemelerini Ertelemeyin

SSL/TLS tarafında güncelleme dendiğinde çoğu kişi sadece “sertifika süresi bitmesin” diye düşünüyor. Oysa asıl kritik kısım, hangi TLS sürümlerine izin verdiğiniz ve hangi şifre paketlerini kullandığınız. Eski protokolleri açık bırakmak, yalnızca teorik bir risk değil; gerçek dünyada exploit edildiğini defalarca gördüğümüz saldırı vektörleri yaratıyor.

Bu yazıda; SSL 3.0, TLS 1.0 ve 1.1’in neden artık devre dışı kalması gerektiğini, TLS 1.2’nin nasıl güvenli konfigüre edileceğini, TLS 1.3’ün güvenlik ve performans avantajlarını, HTTP/2/HTTP/3 ile ilişkisini ve tüm bunları Nginx/Apache üzerinde nasıl pratiğe dökebileceğinizi konuştuk. Bir sonraki adım sizde: Ortam envanterinizi çıkarın, hedef TLS politikanızı belirleyin, staging üzerinde test edin ve kontrollü şekilde canlıya geçin.

Eğer bu süreci kendi başınıza yönetmek istemiyorsanız ya da kritik bir e-ticaret, SaaS veya kurumsal siteniz varsa; DCHost üzerindeki modern hosting, VPS ve dedicated sunucu çözümlerimizle birlikte bu geçişi planlayabiliriz. TLS 1.3, HTTP/2 ve HTTP/3 destekli, güncel güvenlik başlıklarıyla sertleştirilmiş bir altyapı kurmak için bizimle iletişime geçmeniz yeterli. Protokol güncellemelerini son dakikaya bırakmak yerine, bugün adım atın; hem güvenliği hem performansı aynı anda yukarı taşıyın.