TLS El Sıkışması (Handshake) Nasıl Çalışır?

Tarayıcının adres çubuğunda gördüğünüz o küçük kilit simgesi, aslında saniyenin çok altında biten ama şaşırtıcı derecede karmaşık bir pazarlığın sonucudur. Bir siteye https:// ile bağlandığınızda, veri akmaya başlamadan önce istemci ile sunucu birbirlerini tanımak, kimlik doğrulamak ve o oturuma özel gizli bir anahtar üretmek için bir dizi mesaj değişir. Bu sürece TLS el sıkışması (handshake) denir ve HTTPS'in güvenliğinin temelini oluşturur.

Bu rehberde el sıkışmasını, teorik kriptografi diliyle değil, bir sistem yöneticisinin bir sunucuda openssl ile paketleri izlerken gördüğü pratik akışla anlatacağım. ClientHello mesajından şifreli oturumun kurulmasına kadar her adımı sırasıyla ele alacak, RSA ile ECDHE anahtar değişimi arasındaki farkı örnekleyecek, sertifikanın nasıl doğrulandığını gösterecek ve TLS 1.2 ile TLS 1.3 el sıkışmalarının neden bu kadar farklı hızlarda çalıştığını açıklayacağım. Sertifikanın kendisiyle ilgili temelleri SSL sertifikası nedir yazısında ele almıştık; burada odak, o sertifikanın kullanıldığı el sıkışma anıdır.

TLS El Sıkışması Nedir ve Neden Gerekli?#

TLS (Transport Layer Security), iki uç nokta arasında akan veriyi şifreleyen protokoldür. Ama şifreleme yapabilmek için önce her iki tarafın da bildiği ortak bir anahtara ihtiyaç vardır. İşte el sıkışması tam olarak bu sorunu çözer: açık, herkesin dinleyebildiği bir ağ üzerinden, gizli bir anahtar üzerinde anlaşmak.

El sıkışmasının üç temel görevi vardır. Birincisi kimlik doğrulama: istemci, karşısındaki sunucunun gerçekten iddia ettiği alan adı olduğundan emin olmalıdır, yoksa araya giren biri (man-in-the-middle) sizi kandırabilir. İkincisi anahtar üretimi: taraflar, sadece bu oturumda geçerli olacak simetrik bir şifreleme anahtarı üretir. Üçüncüsü parametre uzlaşması: hangi TLS sürümü, hangi şifre paketi (cipher suite) ve hangi eğri (curve) kullanılacağına karar verilir.

Bu üç görevi anlamak önemli, çünkü el sıkışmasında karşılaşacağınız hataların büyük çoğunluğu bu üç aşamadan birinde tıkanır: ya sürüm/şifre uzlaşması başarısız olur, ya sertifika zinciri doğrulanamaz, ya da anahtar değişimi tamamlanamaz.

El Sıkışmadan Önce: TCP Bağlantısı ve TLS Katmanı#

TLS, kendi başına bir taşıma protokolü değildir; TCP'nin üzerinde çalışır. Yani şifreli tek bir bayt bile gitmeden önce, klasik TCP üç yollu el sıkışması (SYN, SYN-ACK, ACK) tamamlanmış olmalıdır. Bu ayrım pratikte gecikme (latency) hesaplarken kritiktir: TCP el sıkışması bir gidiş-dönüş (round trip), TLS el sıkışması ise sürüme göre bir veya iki gidiş-dönüş daha ekler.

Bir bağlantının katmanlarını görmek için basit bir komut yeterli:

# Sunucuya bağlan, sunulan sertifikayı ve el sıkışma detaylarını yazdır
openssl s_client -connect clou.tr:443 -servername clou.tr

# Sadece hangi TLS sürümü ve cipher üzerinde anlaşıldığını görmek için
openssl s_client -connect clou.tr:443 -servername clou.tr </dev/null 2>/dev/null \
  | grep -E "Protocol|Cipher"

Buradaki -servername parametresi çok önemlidir; bu, ClientHello içinde gönderilen SNI (Server Name Indication) alanıdır. Tek bir IP üzerinde birden çok alan adı barındıran sunucular (ki paylaşımlı web hosting ortamlarının neredeyse tamamı böyledir), doğru sertifikayı sunabilmek için hangi alan adına bağlanmak istediğinizi bu alandan öğrenir. SNI göndermezseniz, sunucu size varsayılan sertifikayı sunar ve tarayıcıda alan adı uyuşmazlığı hatası alırsınız.

TLS 1.2 El Sıkışması Adım Adım#

TLS 1.2 hâlâ çok yaygın olduğu için akışı buradan anlatmak öğreticidir. Klasik bir ECDHE tabanlı el sıkışmada mesajlar şu sırayla gider:

1. ClientHello — İstemci başlatır. İçinde desteklediği en yüksek TLS sürümü, rastgele bir sayı (client_random), desteklenen cipher suite listesi, SNI ve uzantılar bulunur.
2. ServerHello — Sunucu, listeden bir cipher suite seçer, kendi rastgele sayısını (server_random) ve seçtiği sürümü döner.
3. Certificate — Sunucu, kendi sertifikasını ve ara (intermediate) sertifikaları gönderir. İstemci bu zinciri doğrular.
4. ServerKeyExchange — ECDHE kullanılıyorsa sunucu, geçici (ephemeral) açık anahtarını gönderir ve bunu sertifikasının özel anahtarıyla imzalar.
5. ServerHelloDone — Sunucu, kendi tarafından söyleyeceklerinin bittiğini bildirir.
6. ClientKeyExchange — İstemci, kendi geçici açık anahtarını (ECDHE) veya şifrelenmiş pre-master secret'ı (RSA) gönderir.
7. ChangeCipherSpec + Finished — Her iki taraf da artık üretilen anahtarla şifrelemeye geçer ve Finished mesajıyla el sıkışmanın bütünlüğünü doğrular.

Bu akışın en görünür özelliği, iki tam gidiş-dönüş sürmesidir: istemci konuşur, sunucu konuşur, istemci tekrar konuşur, sunucu onaylar. Uygulama verisi (ilk HTTP isteğiniz) ancak bundan sonra akmaya başlar. Yüksek gecikmeli mobil bağlantılarda bu iki turun toplamı, sayfa açılış hızında hissedilir bir gecikme yaratır. HTTPS yönlendirme yaparken gereksiz bir HTTP→HTTPS zıplaması eklerseniz, bu el sıkışma maliyetini bir de ikinci kez ödersiniz.

Anahtar Değişimi RSA ile ECDHE Arasındaki Fark#

El sıkışmasının kalbi, ortak gizli anahtarın nasıl üretildiğidir ve burada iki temel yaklaşım vardır. Farkı anlamak, neden modern sunucularda ECDHE'yi tercih etmeniz gerektiğini de açıklar.

RSA anahtar değişiminde istemci, rastgele bir pre-master secret üretir, bunu sunucunun sertifikasındaki açık anahtarla şifreler ve gönderir. Sadece sunucu, kendi özel anahtarıyla bunu çözebilir. Basittir ama tek bir zayıf noktası vardır: eğer sunucunun özel anahtarı gelecekte bir gün ele geçirilirse, saldırgan geçmişte kaydettiği tüm trafiği geriye dönük olarak çözebilir. Yani ileri gizlilik (forward secrecy) yoktur.

ECDHE anahtar değişiminde (Elliptic Curve Diffie-Hellman Ephemeral) ise taraflar, her oturum için geçici anahtar çiftleri üretir. Sertifikanın özel anahtarı burada sadece sunucunun geçici anahtarını imzalamak için kullanılır, ortak sırrı çözmek için değil. Oturum bitince geçici anahtarlar atılır. Sonuç: sertifika özel anahtarı çalınsa bile, geçmiş oturumlar çözülemez. Bu özellik Perfect Forward Secrecy (PFS) olarak bilinir ve bugün endüstri standardıdır.

Nginx üzerinde ECDHE'yi önceliklendiren ve zayıf paketleri kapatan tipik bir yapılandırma şöyledir:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_ecdh_curve X25519:secp384r1;

Kendi sunucunuzu yönetmiyorsanız ve bu ayarların otomatik olarak güvenli tutulmasını istiyorsanız, sunucu yönetimi hizmeti kapsamında cipher listesi ve protokol sürümü periyodik olarak sertleştirilir. Kendi kök erişimli makinenizde denemek isterseniz VDS veya sanal sunucu paketleri bu tür yapılandırma özgürlüğünü verir.

Sertifika Doğrulama Nasıl İşler?#

Anahtar değişimi ne kadar güçlü olursa olsun, karşınızdaki sunucunun gerçekten doğru taraf olduğundan emin olmadan hiçbir anlamı yoktur. İşte sertifika doğrulaması bu güveni kurar. İstemci, sunucunun gönderdiği sertifikayı aldığında şu kontrolleri sırayla yapar.

Öncelikle imza zinciri doğrulanır. Sunucu sertifikası bir ara sertifika tarafından, o ara sertifika da tarayıcının/işletim sisteminin kök deposunda (root store) bulunan güvenilir bir kök tarafından imzalanmıştır. İstemci bu zincirdeki her imzayı, bir üst sertifikanın açık anahtarıyla kontrol eder. Zincirde bir halka eksikse, meşhur "zincir tamamlanamadı" hataları çıkar; bu genellikle sunucunun ara sertifikayı sunmayı unutmasından kaynaklanır.

Sonra alan adı eşleşmesi kontrol edilir: sertifikanın Subject Alternative Name (SAN) alanındaki adlardan biri, bağlandığınız alan adıyla eşleşmeli. Ardından geçerlilik tarihi kontrol edilir; süresi dolmuş veya henüz başlamamış sertifikalar reddedilir. Son olarak iptal durumu (OCSP/CRL) sorgulanabilir.

Zinciri komut satırından denetlemek için:

# Zincirdeki her sertifikanın konu ve verici bilgisini listele
openssl s_client -connect clou.tr:443 -servername clou.tr -showcerts </dev/null 2>/dev/null \
  | grep -E "s:|i:"

# Sertifikanın geçerlilik tarihlerini ve SAN alanını incele
echo | openssl s_client -connect clou.tr:443 -servername clou.tr 2>/dev/null \
  | openssl x509 -noout -dates -ext subjectAltName

Sertifikanın kimliğini gerçekten doğrulaması istenen kurumsal sitelerde OV/EV tipi sertifikalar tercih edilirken, çoğu web sitesi için ücretsiz DV sertifikaları yeterlidir. SSL çözümleri sayfasında hangi doğrulama seviyesinin hangi durumda uygun olduğunu bulabilir, alan adınızın kaydını domain tarafında düzenleyebilirsiniz.

Oturum Anahtarı Nasıl Üretilir?#

El sıkışmasında değişilen tüm bu mesajların amacı tek bir şeye varmaktır: her iki tarafın da bildiği, ama ağı dinleyen hiç kimsenin bilemeyeceği ortak bir simetrik oturum anahtarı. Neden simetrik? Çünkü RSA ve ECDHE gibi asimetrik işlemler yavaştır; büyük veri akışını şifrelemek için verimsizdir. Asimetrik kriptografi sadece anahtarı kurmak için kullanılır, veriyi şifrelemek için değil.

TLS 1.2'de süreç şöyle işler. Önce taraflar, anahtar değişiminden bir pre-master secret elde eder (ECDHE'de bu, Diffie-Hellman hesabının ortak sonucudur). Ardından bu değer, client_random ve server_random ile birlikte bir PRF (Pseudo-Random Function) üzerinden geçirilerek master secret üretilir. master secret'tan da yön yön (istemci→sunucu ve sunucu→istemci) ayrı şifreleme ve MAC anahtarları türetilir.

İşin güzelliği şudur: her oturumda client_random ve server_random farklı olduğu için, aynı sunucuya iki kez bağlansanız bile üretilen oturum anahtarı her seferinde farklı olur. Bu yüzden bir oturumun anahtarı ele geçse bile diğer oturumlar etkilenmez. AES-GCM gibi modern paketlerde tek bir anahtar hem şifrelemeyi hem de bütünlük doğrulamasını (AEAD) birlikte yürütür, bu da hem güvenli hem hızlıdır.

Bu şifreli kanal kurulduktan sonra, üzerinden geçen her şey — form verileri, oturum çerezleri, e-posta trafiği, yönetim panelleri — dışarıdan okunamaz. Bir WAF veya DDoS koruma katmanı bu şifreli trafiği, TLS'i sonlandırdıktan (terminate) sonra inceler; yani el sıkışması genellikle koruma katmanında biter, sonra iç ağda arka uca iletilir.

TLS 1.3 ile Değişen Ne? Daha Hızlı El Sıkışma#

TLS 1.3, el sıkışmasını hem daha güvenli hem de belirgin biçimde daha hızlı hale getirdi. En büyük değişiklik, el sıkışmanın iki gidiş-dönüşten bire (1-RTT) inmesidir. Bunu nasıl başarır? İstemci, ClientHello'yu gönderirken hangi eğriyi kullanacağını tahmin ederek geçici açık anahtarını (key_share) daha ilk mesajda birlikte yollar. Sunucu da ilk cevabında hem kendi key_share'ini döner hem de artık şifreli konuşmaya başlar. Böylece bir tam tur kısalır.

TLS 1.3 ayrıca temizlik de yaptı: RSA anahtar değişimi, statik Diffie-Hellman, RC4, SHA-1, MD5 ve pazarlıkla düşürülebilen zayıf paketler tamamen kaldırıldı. Artık sadece ileri gizlilik sağlayan anahtar değişimleri kaldığı için, "yanlış cipher seçme" riski büyük ölçüde ortadan kalktı. Bir bonus olarak, daha önce bağlanılmış bir sunucuya 0-RTT ile, ilk pakette uygulama verisi göndererek bağlanmak mümkün hale geldi (belirli tekrar-saldırısı riskleriyle birlikte).

Pratik tavsiye: sunucunuzda mutlaka hem TLS 1.2 hem TLS 1.3'ü açık tutun, ama TLS 1.0/1.1'i kesinlikle kapatın. Eski sürümleri açık bırakmak, PCI-DSS gibi uyum standartlarında da başınızı ağrıtır. WordPress veya reseller hosting paketlerinde bu sürüm ayarları genellikle güvenli varsayılanlarla gelir; kendi sunucunuzu yönetiyorsanız yapılandırmayı düzenli olarak SSL test araçlarıyla denetleyin.

El Sıkışmasını Test Etmek ve Sorun Gidermek#

Teoriyi bilmek güzel, ama işler bozulduğunda asıl sınav başlar. El sıkışma hatalarının çoğu birkaç tipik nedene indirgenir ve komut satırından hızlıca teşhis edilir.

En sık karşılaşılan durum, sürüm/cipher uzlaşmazlığıdır. İstemci sadece modern paketleri desteklerken sunucu eski bir yapılandırmada takılı kalmışsa (veya tam tersi) el sıkışma daha ServerHello'ya varamadan kopar. Belirli bir sürümü zorlayarak sorunu daralttabilirsiniz:

# Sadece TLS 1.3 ile bağlanmayı dene
openssl s_client -connect ornek.com:443 -servername ornek.com -tls1_3 </dev/null

# Sadece TLS 1.2 ile dene; hangisinin çalıştığını karşılaştır
openssl s_client -connect ornek.com:443 -servername ornek.com -tls1_2 </dev/null

# Sunucunun desteklediği tüm cipher/sürümleri tarayan pratik araç
nmap --script ssl-enum-ciphers -p 443 ornek.com

İkinci büyük grup sertifika hatalarıdır: eksik ara sertifika, süresi dolmuş sertifika veya SNI/alan adı uyuşmazlığı. Süresi dolmuş sertifikalar utanç verici derecede yaygındır çünkü yenileme unutulur. Bunun önüne geçmek için sertifika izleme ve otomatik yenilemeyi devreye alın; bir bitiş tarihi kontrolünü cron'a koymak bile hayat kurtarır:

# Sertifikanın bitişine kaç gün kaldığını hesapla, 15 günden azsa uyar
DAYS=$(( ( $(date -d "$(echo | openssl s_client -connect ornek.com:443 -servername ornek.com 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)" +%s) - $(date +%s) ) / 86400 ))
[ "$DAYS" -lt 15 ] && echo "UYARI: Sertifikaya $DAYS gün kaldı"

Üçüncü olarak, bir alan adını yeni taşıdıysanız veya site taşıma sonrası DNS henüz oturmadıysa, tarayıcı doğru sunucuya değil eski sunucuya ulaşıp yanlış sertifikayı görebilir. Böyle durumlarda openssl çıktısındaki IP ile beklediğiniz IP'yi karşılaştırın. Düzenli yedekleme ve otomatik sertifika yönetimi, taşıma sonrası bu tür TLS kesintilerini en aza indirir. Sitenizin arama sıralamasında da HTTPS'in doğru çalışması bir sinyaldir; SEO tarafında karışık içerik (mixed content) ve sertifika hataları görünürlüğü olumsuz etkiler.

Sıkça Sorulan Sorular#

TLS el sıkışması ne kadar sürer?#

El sıkışmasının süresi büyük ölçüde ağ gecikmesine bağlıdır, çünkü asıl maliyet gidiş-dönüş sayısıdır. TLS 1.2'de iki tam tur, TLS 1.3'te bir tur gerekir; 50 ms gecikmeli bir bağlantıda bu, TLS 1.2 için kabaca 100 ms, TLS 1.3 için 50 ms ek süre demektir. Kriptografik hesaplamaların kendisi modern donanımda milisaniyenin altındadır, bu yüzden en büyük iyileştirme sürümü yükseltmek ve gereksiz yönlendirmeleri kaldırmakla gelir.

SSL handshake ile TLS handshake aynı şey mi?#

Pratikte evet, çoğu insan ikisini birbirinin yerine kullanır. SSL, TLS'in atası olan ve artık güvensiz kabul edilip terk edilen eski protokolün adıdır; SSL 2.0 ve 3.0 sürümleri yıllar önce devre dışı bırakıldı. Bugün "SSL sertifikası" ya da "SSL handshake" dediğinizde teknik olarak kastedilen şey TLS'tir. Ayrıntılar için SSL sertifikası nedir yazısına göz atabilirsiniz.

ECDHE neden RSA anahtar değişiminden daha güvenli sayılıyor?#

Çünkü ECDHE her oturum için geçici anahtarlar üretir ve bu geçici anahtarlar oturum bitince atılır. Sunucunun uzun ömürlü özel anahtarı gelecekte bir gün ele geçirilse bile, geçmişte kaydedilmiş şifreli trafik çözülemez; buna ileri gizlilik denir. RSA anahtar değişiminde ise ortak sır doğrudan sunucunun özel anahtarına bağlı olduğu için, o anahtar sızarsa tüm geçmiş trafik risk altına girer. Bu nedenle TLS 1.3 RSA anahtar değişimini tamamen kaldırmıştır.

El sıkışması sırasında verilerim şifreleniyor mu?#

El sıkışmasının ilk mesajları (ClientHello, ServerHello gibi) henüz şifresizdir çünkü ortak anahtar daha kurulmamıştır; bir gözlemci sizin hangi alan adına bağlandığınızı SNI üzerinden görebilir. Ancak asıl uygulama veriniz — form içerikleri, parolalar, çerezler — el sıkışması tamamlanıp oturum anahtarı üretildikten sonra akmaya başlar ve tamamen şifrelidir. TLS 1.3, el sıkışmanın büyük kısmını da şifrelediği için üstverinin sızması daha da azalmıştır.

Sürekli "handshake failure" hatası alıyorum, nereden başlamalıyım?#

İlk olarak sorunun sürüm/cipher uzlaşmasında mı yoksa sertifikada mı olduğunu ayırın. openssl s_client -connect alanadi:443 -tls1_2 ve -tls1_3 ile ayrı ayrı deneyin; biri çalışıp diğeri çalışmıyorsa sorun protokol yapılandırmasındadır. Her iki sürümde de kopuyorsa, sertifika zincirini -showcerts ile inceleyin ve ara sertifikanın sunulup sunulmadığını, geçerlilik tarihini kontrol edin. Kök erişiminiz yoksa veya yapılandırmayı kendiniz düzeltmek istemiyorsanız sunucu yönetimi hizmetiyle bu ayarlar sizin adınıza düzeltilir.

TLS 1.0 ve 1.1'i kapatırsam eski ziyaretçilerimi kaybeder miyim?#

Günümüzde TLS 1.0/1.1'e ihtiyaç duyan istemci oranı ihmal edilebilecek kadar düşüktür; modern tarayıcıların tamamı yıllardır TLS 1.2 ve 1.3'ü destekler. Bu eski sürümleri açık tutmak size güvenlik açığı ve uyum sorunu dışında bir şey kazandırmaz, üstelik POODLE ve BEAST gibi bilinen saldırılara kapı aralar. Güvenle TLS 1.2 ve 1.3'ü açık bırakıp 1.0/1.1'i kapatabilirsiniz; kapattıktan sonra sitenizi bir SSL test aracıyla doğrulamanız yeterlidir.

Kapanış#

TLS el sıkışması ilk bakışta karmaşık görünse de, aslında üç basit soruyu yanıtlayan düzenli bir konuşmadır: "Kiminle konuşuyorum?", "Hangi kurallarla?" ve "Ortak gizli anahtarımız ne?". Bu soruların yanıtları ClientHello ile başlar, sertifika doğrulaması ile güvence altına alınır ve oturum anahtarının üretilmesiyle biter. RSA'dan ECDHE'ye, TLS 1.2'den 1.3'e geçişin tek bir ortak hedefi vardır: her oturumu daha hızlı ve geçmişe dönük daha kırılmaz kılmak.

Bu bilgiyi pratiğe dökmek için doğru altyapı önemlidir. Modern TLS sürümleri, otomatik sertifika yönetimi ve sertleştirilmiş cipher yapılandırması ile gelen hosting ve sunucu paketlerimizle sitenizin el sıkışmalarını hem hızlı hem güvenli tutabilirsiniz. Ücretsiz SSL kurulumundan yönetilen sunucu yönetimi hizmetine kadar ihtiyacınıza uygun çözümü seçin; el sıkışmasının doğru çalışması bizim işimiz olsun, siz içeriğinize odaklanın. Şifreli bağlantının bir sonraki adımı olan yönlendirmeleri doğru kurmak için HTTPS yönlendirme rehberimize de göz atmanızı öneririm.