SSL/TLS Protokol Güncellemeleri: Nginx ve Apache

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 SSL/TLS protokol güncellemelerini ele alacağız. 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ı. Bu yol haritası, güvenlik denetimleri ve PCI DSS benzeri uyumluluk süreçlerinde TLS yapılandırmasını değerlendirmenize yardımcı olur; tek başına uyumluluk kanıtı değildir.

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, ortak desteklenen seçenekler arasından yapılandırılmış tercih ve kısıtlamalara göre bir kombinasyon 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

Ö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ında ayrıca sağlayıcının TLS politikasını ve geçerli PCI DSS gereksinimlerini değerlendirmek gerekiyor; tüm bu sürümlerin aynı gerekçeyle reddedildiği varsayılmamalı.

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 ve 3DES gibi algoritmaların bilinen güvenlik zayıflıkları var; modern TLS yapılandırmalarında bunları kullanmamak gerekir.
• 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, SSL 2.0, SSL 3.0, 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: Uyumluluk İçin Önemli, Ama Doğru Konfigüre Edilirse

TLS 1.2, eski istemcilerle uyumluluk için önemini koruyor. Modern tarayıcılar tarafından destekleniyor ve uygun şifre paketleri ile ALPN desteği sağlandığında HTTP/2 için kullanılabiliyor. Ödeme altyapılarıyla uyumluluk ise ilgili sağlayıcının gereksinimlerine bağlı. 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. Öncelik bu istemcileri güncellemek veya değiştirmek olmalı. Geçiş hemen tamamlanamıyorsa, süreli istisnalar için iki risk azaltma seçeneği değerlendirilebilir:

• Ayrı endpoint: Eski istemcileri, yalnızca gerekli iç ağ istemcilerine güvenlik duvarı kurallarıyla açılan ayrı bir uç noktaya yönlendirmek. Farklı bir domain veya IP tek başına erişim kısıtlaması sağlamaz.
• Tam ayrıştırma: Bu sistemleri doğrudan internet erişiminden yalıtmak ve gerekiyorsa erişimi güncel bir VPN ile sınırlandırmak. Bu önlemler eski TLS sürümlerini güvenli hâle getirmez; istisna için sorumlu ve kaldırma tarihi belirlemek gerekir.

Genel internet trafiğine açık web siteleri için ise tavsiyemiz net: en düşük sürümü TLS 1.2 yapın.

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. Birçok eski ve riskli özellik kaldırı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ı: Sertifika tabanlı el sıkışmalarda (EC)DHE ile ileri gizlilik (PFS) sağlanır. Ancak yalnızca önceden paylaşılan anahtara (PSK) dayanan mod aynı güvenceyi sağlamaz; PFS tüm TLS 1.3 bağlantıları için koşulsuz değildir.
• 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) riski taşır; uygulamanın erken veriyi güvenle işleyebildiği değerlendirilmeden etkinleştirilmemelidir.

Özetle:

• Statik içerik sunan, sunucu durumunu değiştirmeyen ve tekrar oynatılması güvenli GET istekleri için özel senaryolarda düşünülebilir. İdempotent olmak, aynı isteğin tekrarlanmasının amaçlanan etkisini değiştirmemesi demektir; yalnızca GET yöntemini kullanmak veya idempotent olmak, 0-RTT güvenliği için yeterli değildir.
• 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ü:

• Web sunucusunun sürümü ve derleme özellikleri ile kullandığı TLS kütüphanesi (örneğin OpenSSL), desteklenebilen TLS sürümlerini sınırlar. İşletim sisteminin paketleri ve kriptografi politikası da bunu etkileyebilir.
• 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 parça, modern bir Linux + Nginx + güncel OpenSSL ortamı için örnek TLS politikasıdır; tam bir HTTPS sunucu konfigürasyonu değildir. Sertifika, özel anahtar ve HTTPS dinleyicisi tanımlanmış mevcut yapılandırmaya uyarlanmalıdır:

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

• Bu politikanın uygulandığı TLS uç noktasında eski TLS sürümlerini 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.

HTTP/2 için Nginx’in HTTP/2 modülüyle derlenmiş olması ve TLS tarafında ALPN desteği gerekir. Nginx 1.25.1 ve sonrasında ilgili HTTPS sunucu bloğunda listen 443 ssl; ile http2 on; kullanılabilir; mevcut dinleyici satırını buna göre düzenleyin. Daha eski sürümlerde listen 443 ssl http2; sözdizimi kullanılır. HTTP/2’nin TLS gereksinimlerine birazdan ayrıca değineceğiz.

Apache İçin Örnek TLS Konfigürasyonu

Apache’de benzer bir TLS politikası aşağıdaki parçayla uygulanabilir. Bu da tam bir HTTPS sanal sunucu tanımı değildir; SSL modülü, sertifika, özel anahtar ve HTTPS dinleyicisi yapılandırılmış bir ortama uyarlanmalıdır:

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. VPS veya dedicated sunucu seçerken, kullanacağınız işletim sistemi imajının ve web sunucusuna bağlı TLS kütüphanesinin TLS 1.3 desteğini doğrulayın.

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

Örneğin uygulama ve Nginx/Apache güncel olsa da web sunucusunun kullandığı OpenSSL kütüphanesi eski ve TLS 1.3 desteksiz olabilir. Böyle bir ortamda TLS 1.3’ü yalnızca bir ayar değişikliğiyle açmak mümkün olmaz. 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 altyapı güncellemelerini yalnızca tek bir katmana değil, OS + OpenSSL + web sunucusu üçlüsüne birlikte bakarak planlayın.

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, mevcut TLS 1.2 politikanızı gözden geçirip TLS 1.3 desteğini doğrulayın. TLS 1.3 tek başına HTTP/3’ü etkinleştirmez; bağlantıyı sonlandıran katmanın HTTP/3 ve QUIC desteği de gerekir.
• CDN veya ters proxy kullanıyorsanız, HTTP/3 bağlantısı bu katmanda sonlanabilir; origin (kaynak) sunucuya ayrı bağlantının TLS politikasını ayrıca doğrulayın.

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

Protokol geçişinde teknik ayarlar kadar adımların sırası da önemlidir. Aşağıdaki yol haritasını sitenizin ölçeğine, istemcilerinize ve entegrasyonlarınıza göre uyarlayın.

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ışarıya sunulan TLS sürümlerini ve bağlantı davranışını incelemek için openssl s_client ile testler yapabilir, online TLS test araçlarını kullanabilirsiniz. Bu testler işletim sistemi ve kütüphane envanterinin yerini tutmaz. İç ağdaki servislerde de paket bilgilerini ve etkin konfigürasyonu incelemeyi bağlantı testleriyle tamamlayın.

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.

HTTP güvenlik başlıkları, HSTS ve CSP gibi ek sıkılaştırmaları da önce staging ortamında değerlendirin; TLS geçişiyle aynı anda tümünü etkinleştirmek yerine ayrı ve kontrollü adımlarla uygulayın.

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 geri yüklenebilir, sürümlenmiş bir yedek alın; örneğin Git geçmişi veya tarihli ayrı kopyalar kullanın. rsync ile tek bir kopyayı güncellemek tek başına sürüm geçmişi sağlamaz.
• Önce daha az kritik sitelerde yeni TLS politikasını deneyin.
• Değişikliği etkinleştirmeden önce web sunucusunun konfigürasyon doğrulamasını çalıştırın; hata varsa devam etmeyin. Etkinleştirdikten sonra ilgili TLS uç noktalarında izin verilen sürümlerle bağlantı kurulabildiğini ve kaldırılan sürümlerin reddedildiğini doğrulayın.
• 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.

TLS konfigürasyonu değişiklikleri için bir bakım penceresi belirleyin ve geri dönüş adımlarını önceden tanımlayın. Bu plan, bir uyumluluk sorunu çıktığında müdahaleyi kolaylaştırır.

Hosting ve Sunucu Seçiminde TLS Politikası Ölçütleri

Hosting, VPS veya dedicated sunucu seçerken TLS ayarlarının hangi tarafın sorumluluğunda olduğunu ve aşağıdaki olanakları seçtiğiniz plan için doğrulayın:

• Hizmette TLS’nin nerede sonlandırıldığını, başlangıçta hangi protokol sürümlerinin etkin olduğunu ve bunları kimin değiştirebildiğini belirleyin.
• İşletim sistemi, TLS kütüphanesi ve web sunucusu güncellemelerinin kim tarafından ve nasıl yapılacağını netleştirin.
• Nginx/Apache ayarlarına erişim yetkilerinizi ve ihtiyaç duyacağınız teknik desteğin kapsamını doğrulayın.
• Otomatik SSL yenileme ve ACME entegrasyonu gereksinimlerini, yenileme hatalarının nasıl izleneceğiyle birlikte değerlendirin. Teknik seçenekler için SSL sertifika otomasyonundaki yenilikler yazımızdan yararlanabilirsiniz.

Ö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, bilinen protokol zayıflıklarına maruz kalma riskini artırır.

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.

Bir hizmet sağlayıcıdan destek alacaksanız, geçiş planlaması ve sunucu yapılandırmasının destek kapsamına girip girmediğini netleştirin. Seçtiğiniz altyapıda TLS 1.3, HTTP/2 ve HTTP/3 desteğini ve uygulamaya uygun güvenlik başlıklarını yapılandırma olanaklarını doğrulayın.