Cipher Suite (Şifre Paketi) Nedir?

Bir SSL/TLS bağlantısı kurulduğunda tarayıcı ile sunucu arasında saniyenin çok altında süren bir pazarlık yaşanır: iki taraf, bu oturum boyunca verinin nasıl şifreleneceğine, karşı tarafın kimliğinin nasıl doğrulanacağına ve aktarılan baytların yolda değiştirilmediğinden nasıl emin olunacağına birlikte karar verir. İşte bu kararların tamamını tek bir isim altında paketleyen yapıya cipher suite — Türkçesiyle şifre paketi — denir. Adres çubuğundaki kilit simgesinin arkasında görünmeyen ama bağlantınızın gerçek güvenlik seviyesini belirleyen şey, hangi şifre paketinin seçildiğidir.

Çoğu site sahibi şifre paketleriyle hiç ilgilenmez; yönetilen bir hosting paketinde sunucu zaten güvenli varsayılanlarla gelir. Ancak kendi sunucunuzu yönetiyorsanız, bir güvenlik taraması "zayıf şifreler tespit edildi" uyarısı verdiğinde ya da bir PCI-DSS/KVKK uyum denetiminden geçmeniz gerektiğinde bu konu birden hayati hale gelir. Bu rehberde bir şifre paketinin dört bileşenini tek tek parçalarına ayıracak, güvenli (AES-GCM, ChaCha20) ile zayıf (RC4, 3DES) şifreleri karşılaştıracak ve Nginx'te üretime hazır, önerilen bir cipher listesinin nasıl kurulacağını gerçek komutlarla göstereceğiz. Konunun temeli olan sertifikaları henüz kavramadıysanız önce SSL sertifikası nedir yazımıza göz atmanız faydalı olacaktır.

Cipher Suite Nedir ve Handshake'te Nasıl Seçilir?#

Bir şifre paketi, tek başına bir algoritma değil, birbiriyle uyumlu algoritmalardan oluşan bir demettir. TLS el sıkışması (handshake) sırasında istemci, desteklediği tüm şifre paketlerinin listesini önem sırasına göre sunucuya gönderir (ClientHello mesajı). Sunucu bu listeye kendi desteklediği ve izin verdiği paketlerle bakar, ortak kümeden birini seçer ve seçtiğini istemciye bildirir (ServerHello). Bu andan itibaren oturumun geri kalanı tamamen o seçilen paketin kurallarına göre işler.

Buradaki kritik nokta şudur: bağlantının güvenlik seviyesini, iki taraftan hangisinin seçime öncelik verdiği belirler. Eski TLS sürümlerinde sunucunun kendi tercih sırasını dayatması (prefer server ciphers) güvenli sayılırdı, çünkü böylece kötü yapılandırılmış bir istemci sizi zayıf bir şifreye zorlayamazdı. Yani bir tarafta desteklenen zayıf bir algoritma, listede güçlü olanlar da varsa, doğru yapılandırmayla asla seçilmez. Sorun genellikle sunucunun listesinde hâlâ eski, kırılmış algoritmaların bulunmasıdır — çözüm de bu listeyi bilinçli biçimde daraltmaktır.

Şifre paketlerinin iki farklı yazım biçimiyle karşılaşırsınız. Standartları belirleyen IANA gösterimi uzun ve açıklayıcıdır (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256), sunucu yapılandırmasında kullandığınız OpenSSL gösterimi ise kısadır (ECDHE-RSA-AES128-GCM-SHA256). İkisi aynı paketi anlatır; sadece söz dizimi farklıdır. Sisteminizin desteklediği paketleri OpenSSL gösterimiyle listelemek için:

openssl ciphers -v 'ECDHE+AESGCM' | column -t

Bu komut, adında ECDHE anahtar değişimi ve AES-GCM şifreleme geçen tüm paketleri, her birinin protokol sürümü ve bileşenleriyle birlikte gösterir.

Bir Şifre Paketinin Dört Bileşeni#

Klasik bir TLS 1.2 şifre paketinin adı, aslında dört ayrı görevi yerine getiren dört algoritmanın birleşimidir. ECDHE-RSA-AES128-GCM-SHA256 paketini parçalarına ayıralım:

1. Anahtar Değişimi (Key Exchange) — ECDHE. İki tarafın, hattı dinleyen biri her şeyi görse bile ortak bir gizli anahtar üzerinde anlaşmasını sağlar. Modern paketlerde bu neredeyse her zaman ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) veya DHE'dir. Buradaki "Ephemeral" (geçici) kelimesi çok önemlidir: her oturum için yeni ve tek kullanımlık bir anahtar üretilir. Bu, ileri gizlilik (Perfect Forward Secrecy) demektir — sunucunuzun özel anahtarı yıllar sonra ele geçirilse bile, saldırgan geçmişte kaydettiği trafiği çözemez, çünkü o oturumların anahtarları çoktan yok edilmiştir. İleri gizlilik sağlamayan eski statik RSA anahtar değişimi tam da bu yüzden terk edilmiştir.

2. Kimlik Doğrulama (Authentication) — RSA. Bu bileşen, karşınızdaki sunucunun sertifikasını imzalayan ve o sertifikanın gerçekliğini kanıtlayan algoritmadır. Genellikle RSA veya ECDSA olur ve doğrudan sertifikanızın anahtar tipiyle eşleşir. ECDSA sertifikalar daha kısa anahtarlarla aynı güvenliği sunduğu için el sıkışması biraz daha hafiftir; RSA ise en yaygın ve en geniş uyumlu seçenektir. Bu, SSL hatalarının çözümü yazımızda değindiğimiz "alan adı uyuşmazlığı" gibi kimlik doğrulama sorunlarının da kök zeminidir.

3. Simetrik Şifreleme (Bulk Cipher) — AES128-GCM. El sıkışması tamamlandıktan sonra aktardığınız asıl veriyi — sayfa içeriği, form gönderimleri, API çağrıları — şifreleyen algoritmadır. "Simetrik" olması, aynı anahtarın hem şifreleme hem çözme için kullanıldığı anlamına gelir; asimetrik işlemlere göre çok daha hızlıdır, bu yüzden büyük veri hacmi bununla korunur. Buradaki GCM da en az AES kadar kritiktir: bu, AEAD (Authenticated Encryption with Associated Data) modudur, yani şifreleme ve bütünlük doğrulamasını aynı anda ve güvenli biçimde yapar.

4. MAC / Özet Fonksiyonu — SHA256. Geleneksel modlarda bu bileşen, her mesajın yolda değiştirilmediğini doğrulayan mesaj doğrulama kodunu (MAC) üretir. AES-GCM gibi AEAD modlarında bütünlük zaten şifrelemenin içine gömülü olduğundan, buradaki SHA256 esas olarak anahtar türetme ve oturum özeti (PRF) için kullanılır. Kısacası bu son parça, "aldığım bayt, gönderilen bayt mı?" sorusunun cevabını garanti eder.

Güvenli ve Zayıf Şifreleri Ayırt Etmek#

Bir şifre paketinin "güvenli" olup olmadığını en çok belirleyen bileşen, simetrik şifreleme algoritması ve modudur. Bugün pratikte yalnızca iki AEAD ailesi kayıtsız şartsız güvenli kabul edilir: AES-GCM (donanım hızlandırması olan sunucularda en hızlısı) ve ChaCha20-Poly1305 (donanım AES desteği olmayan ortamlarda ve mobil cihazlarda üstün performans gösterir). Bu ikisi dışında kalan pek çok eski algoritma yıllar içinde kırıldı ya da ciddi zafiyetler barındırdığı için devre dışı bırakılmalıdır.

Zayıf tarafta üç ismi özellikle hatırlamakta fayda var. RC4 bir zamanlar hızı yüzünden çok yaygındı ama istatistiksel önyargıları nedeniyle artık tamamen kırılmış sayılıyor ve modern tarayıcılar bunu reddediyor. 3DES, 64-bit'lik küçük blok boyutu yüzünden Sweet32 saldırısına açıktır ve major tarayıcılar desteğini çekmiştir. AES-CBC modu teknik olarak "yasak" değildir ama AEAD olmadığı için Lucky13 gibi zamanlama saldırılarına tarihsel olarak zemin hazırlamıştır; mümkünse GCM'i tercih edin. Pratik kural nettir: paket adında GCM veya CHACHA20 göremiyorsanız ve ECDHE/DHE ile başlamıyorsa, o paketi modern bir yapılandırmada bulundurmayın.

TLS 1.3 Şifre Paketlerini Nasıl Sadeleştirdi?#

TLS 1.3, şifre paketi konusunu köklü biçimde basitleştirdi. Artık bir paket adında yalnızca iki parça vardır: simetrik şifreleme ve özet fonksiyonu. Örneğin TLS_AES_128_GCM_SHA256. Anahtar değişimi ve kimlik doğrulama, paket adının parçası olmaktan çıkarıldı ve el sıkışmanın ayrı bir aşamasında pazarlığa taşındı. Bunun nedeni ideolojik değil, güvenlikseldir: TLS 1.3 zaten yalnızca ileri gizlilik sağlayan (ephemeral) anahtar değişimini ve yalnızca AEAD şifrelerini kabul eder, dolayısıyla bu güvenli seçimleri paket adına gömmenin bir anlamı kalmamıştır.

TLS 1.3'te toplam yalnızca beş şifre paketi tanımlıdır ve hepsi güvenlidir:

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA256

Bu yüzden pratikte TLS 1.3 için "cipher listesi ayarlamak" diye bir dert kalmaz; sadece protokolü etkinleştirmeniz yeterlidir, geri kalanı güvenli bir varsayılan olarak zaten yerindedir. Uğraşmanız gereken tek yer, hâlâ geniş uyumluluk için açık tuttuğunuz TLS 1.2 ayarlarıdır. TLS 1.0 ve 1.1'i ise tamamen kapatmalısınız; bu iki eski sürüm artık uyum standartlarınca da desteklenmiyor.

Nginx'te Önerilen Cipher Listesi#

Şimdi teoriden pratiğe geçelim. Aşağıdaki yapılandırma, geniş tarayıcı uyumluluğunu korurken (Mozilla'nın "intermediate" profiline yakın) yalnızca ileri gizlilikli, AEAD şifreleri açık bırakan üretime hazır bir örnektir. Nginx http bloğunuza ya da ilgili server bloğuna ekleyebilirsiniz:

# Yalnızca modern protokoller — TLS 1.0/1.1 kapalı
ssl_protocols TLSv1.2 TLSv1.3;

# TLS 1.2 için elle seçilmiş, ileri gizlilikli AEAD paketleri
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

# Modern istemcilerde sıralamayı istemciye bırakmak önerilir (TLS 1.3 zaten kendi yönetir)
ssl_prefer_server_ciphers off;

# Oturum performansı ve ECDHE eğrisi
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_ecdh_curve X25519:secp384r1;

Burada dikkat edilecek birkaç ince nokta var. ssl_ciphers yönergesi yalnızca TLS 1.2 ve altını etkiler; TLS 1.3 paketleri bu satırla değil, protokolün kendisi tarafından yönetilir; bu yüzden listede TLS 1.3 paketlerini görmeyişiniz normaldir. Listeyi hem ECDSA hem RSA varyantlarıyla yazdık ki hangi tür sertifikaya sahip olursanız olun uyumlu bir paket bulunsun. ChaCha20-Poly1305'i bilinçli olarak ekledik: AES donanım hızlandırması olmayan sunucularda ve mobil istemcilerde belirgin performans avantajı sağlar.

Değişikliği uygulamadan önce her zaman söz dizimini test edin, ardından servisi kesintisiz yeniden yükleyin:

sudo nginx -t && sudo systemctl reload nginx

Apache kullanıyorsanız aynı mantık SSLProtocol ve SSLCipherSuite yönergeleriyle kurulur:

SSLProtocol             -all +TLSv1.2 +TLSv1.3
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder     off
SSLSessionTickets       off

Kendi sunucunuzu yönetmek yerine bu tür güvenlik ince ayarlarını uzmana bırakmak isterseniz sunucu yönetimi hizmetimiz tam da bunun için vardır; ekip, cipher listenizi güncel tehdit modeline göre düzenli olarak sıkılaştırır.

Yapılandırmanızı Test Etmek ve Doğrulamak#

Bir cipher listesini yazmak işin yarısıdır; asıl önemli olan gerçekten beklediğiniz gibi davrandığını doğrulamaktır. En hızlı yerel doğrulama, belirli bir zayıf şifrenin reddedildiğini ispatlamaktır. Örneğin sunucunuzun 3DES'i gerçekten kapattığını görmek için:

openssl s_client -connect alanadiniz.com:443 -cipher '3DES' 2>&1 | grep -i "cipher\|handshake failure"

Sağlıklı bir yapılandırmada bu komut handshake failure ile döner — yani sunucu bu zayıf şifreyle bağlantı kurmayı reddeder, ki tam olarak istediğimiz budur. Tersine, güvenli bir paketin gerçekten çalıştığını görmek için:

openssl s_client -connect alanadiniz.com:443 -tls1_2 \
  -cipher 'ECDHE-RSA-AES128-GCM-SHA256' 2>/dev/null | grep "Cipher"

Sunucunuzun sunduğu tüm şifre paketlerini tek seferde ve derli toplu görmek isterseniz nmap'in yerleşik betiği çok pratiktir; her paketi bir güç notuyla (A'dan F'ye) birlikte listeler:

nmap --script ssl-enum-ciphers -p 443 alanadiniz.com

Çıktıda least strength: A görmeniz, sunulan en zayıf paketin bile güçlü olduğu anlamına gelir. Herhangi bir yerde C, D veya F notu belirirse o paketi listenizden çıkarmanız gerekir. Tarayıcı tabanlı, ücretsiz üçüncü taraf SSL test araçları (arama motorunda "SSL sunucu testi" olarak bulabilirsiniz) da aynı analizi görsel bir raporla sunar ve genel bir harf notu verir; canlıya çıkmadan önce bu raporda en az A almayı hedefleyin. Bu testleri periyodik hale getirmek için ilerideki taramalarınızı SEO ve site sağlığı araçlarımızla birlikte düzenli takvime bağlayabilirsiniz.

Uyum, Uygulama Katmanı ve Sık Yapılan Hatalar#

Şifre paketlerini sıkılaştırırken en sık düşülen tuzak, uyum uğruna gereğinden fazla kısıtlama yapıp gerçek ziyaretçileri dışarıda bırakmaktır. Çok agresif bir liste (yalnızca AES-256-GCM ve TLS 1.3), güncel tarayıcılarda kusursuz çalışırken eski bir kurumsal Windows istemcisinden veya bazı ödeme ağ geçitlerinden gelen bağlantıları koparabilir. Bu yüzden "en katı" değil, "tehditlere kapalı ama meşru istemcilere açık" dengesini hedefleyin; yukarıdaki intermediate profil çoğu Türkiye pazarı için bu dengeyi iyi tutar.

İkinci sık hata, katmanları karıştırmaktır. Şifre paketiniz kusursuz olabilir ama uygulamanız hâlâ karışık içerik (mixed content) sunuyorsa ya da bir arka uç servisi şifrelenmemişse zincirin en zayıf halkası orasıdır. Şifre paketi yalnızca taşıma katmanını korur; uygulama seviyesindeki saldırılar için ayrıca bir web uygulama güvenlik duvarına ihtiyacınız olur. Bir güvenlik taramasının "zayıf şifre" uyarısını kapatmak, sitenizin bütün olarak güvenli olduğu anlamına gelmez — bu, çok katmanlı bir savunmanın yalnızca bir katmanıdır. Sertifika, protokol ve şifre paketi üçlüsünü birlikte düşünmek için SSL çözümlerimizi ve genel hosting altyapımızı da bu bütünün parçaları olarak değerlendirin.

Sıkça Sorulan Sorular#

Şifre paketi ile SSL sertifikası aynı şey mi?#

Hayır, ikisi farklı ama birbirini tamamlayan kavramlardır. Sertifika, sunucunuzun kimliğini kanıtlayan ve içinde açık anahtarınızı taşıyan belgedir; şifre paketi ise o kimlik doğrulandıktan sonra verinin hangi algoritmalarla şifreleneceğini belirleyen kurallar demetidir. Sertifikanızın tipi (RSA veya ECDSA) hangi şifre paketlerinin kullanılabileceğini etkiler, ama sertifikayı almak tek başına şifre paketi yapılandırmanızı güvenli hale getirmez.

Sunucumda hangi şifre paketlerinin açık olduğunu nasıl görürüm?#

Sunucudan bağımsız çalışan nmap --script ssl-enum-ciphers -p 443 alanadiniz.com komutu en pratik yöntemdir; sunulan tüm paketleri güç notlarıyla birlikte listeler. Alternatif olarak openssl s_client ile belirli bir şifreyi tek tek test edebilir ya da tarayıcı tabanlı ücretsiz bir SSL test aracıyla görsel bir rapor alabilirsiniz. Yerel olarak OpenSSL'in bildiği paketleri görmek içinse openssl ciphers -v komutunu kullanabilirsiniz.

RC4 veya 3DES hâlâ neden bazı sunucularda açık?#

Genellikle çok eski bir yapılandırmanın hiç güncellenmemiş olmasından kaynaklanır. Bir zamanlar bu şifreler eski tarayıcılarla uyumluluk için mantıklıydı, ancak RC4 istatistiksel önyargılar nedeniyle, 3DES ise Sweet32 saldırısı nedeniyle kırıldı ve modern tarayıcılar zaten ikisini de reddediyor. Bunları açık tutmanın bugün hiçbir uyum ya da uyumluluk gerekçesi yoktur; cipher listenizden derhal çıkarmalısınız.

İleri gizlilik (Forward Secrecy) neden bu kadar önemli?#

Çünkü sunucunuzun özel anahtarı gelecekte bir gün çalınsa bile, ileri gizlilik sağlayan paketler geçmiş trafiğinizi koruma altında tutar. ECDHE ve DHE gibi "ephemeral" anahtar değişimleri her oturum için tek kullanımlık bir anahtar üretip sonra yok eder; dolayısıyla saldırganın çalınan ana anahtarla geriye dönük olarak kaydettiği şifreli trafiği çözmesi mümkün olmaz. Bu yüzden modern yapılandırmalarda yalnızca ECDHE/DHE ile başlayan paketler tercih edilir.

TLS 1.3'e geçersem cipher listesini elle ayarlamama gerek kalır mı?#

TLS 1.3 için pratikte gerek kalmaz, çünkü bu protokol yalnızca güvenli, AEAD tabanlı ve ileri gizlilikli paketleri kabul edecek şekilde tasarlanmıştır; sadece protokolü etkinleştirmeniz yeterlidir. Ancak geniş uyumluluk için genellikle TLS 1.2'yi de açık bırakırsınız ve asıl elle sıkılaştırma yapmanız gereken katman işte odur. Yani cipher listesi yazma işi tümüyle ortadan kalkmaz; sadece TLS 1.2 ile sınırlanır.

Şifre paketini sıkılaştırdım ama bazı ziyaretçiler siteye giremiyor, ne yapmalıyım?#

Büyük olasılıkla listeyi fazla daraltıp eski ama meşru istemcileri dışarıda bıraktınız. Yalnızca AES-256-GCM ve TLS 1.3 gibi çok agresif bir yapılandırma, güncel olmayan kurumsal tarayıcıları veya bazı ödeme sistemlerini koparabilir. Bu rehberdeki intermediate profile geri dönüp hem ECDHE-RSA hem ChaCha20 varyantlarını da eklemek uyumu genellikle geri getirir; nmap çıktısında en zayıf notun hâlâ güçlü olduğundan emin olarak dengeyi koruyabilirsiniz.

Kapanış#

Cipher suite, adının teknik ağırlığına rağmen aslında basit bir fikirdir: iki tarafın, bir oturum boyunca güvenliği nasıl sağlayacağına dair üzerinde anlaştığı bir kurallar demeti. Anahtar değişimi ileri gizliliği, kimlik doğrulama güveni, simetrik şifreleme gizliliği, MAC ise bütünlüğü üstlenir. Bugün yapmanız gereken tek şey listenizi yalnızca ECDHE/DHE ile başlayan, GCM veya CHACHA20 içeren AEAD paketleriyle sınırlamak, TLS 1.0/1.1'i tamamen kapatmak ve değişikliği bir tarama aracıyla doğrulamaktır. Bu üç adım, sitenizi hem bilinen saldırılara hem de uyum denetimlerine karşı sağlam bir zemine oturtur.

Bu ince ayarlarla tek tek uğraşmak yerine güvenli varsayılanlarla gelen bir altyapıda çalışmak isterseniz, SSL çözümlerimize ve otomatik sertifika yönetimiyle gelen hosting paketlerimize göz atabilir; kendi sunucunuzu tam kontrolle yönetmeyi tercih ediyorsanız sunucu yönetimi hizmetimizle cipher listenizi sürekli güncel ve sıkı tutabilirsiniz. Güvenlik, tek seferlik bir ayar değil, düzenli bakım gerektiren bir süreçtir; doğru kurulmuş bir şifre paketi ise bu sürecin en sağlam temellerinden biridir.