~/sibercrew▊
← Kriptografi

TLS/SSL El Sıkışma (Handshake) Süreci Detaylı İnceleme

Bir HTTPS bağlantısının kurulması sırasında perde arkasında gerçekleşen kriptografik müzakerenin adım adım analizi.

TLS (Transport Layer Security), internet üzerindeki güvenli iletişimin temelini oluşturan protokoldür. Bu makale, bir istemci ve sunucunun güvenli bir bağlantı kurmak için gerçekleştirdiği "el sıkışma" (handshake) sürecinin adımlarına, özellikle TLS 1.3'ün getirdiği iyileştirmelere odaklanır.

TLS 1.2 El Sıkışması: Klasik Akış

TLS 1.2'de tam bir el sıkışma tipik olarak şu adımları içerir:

  1. ClientHello: İstemci, desteklediği TLS sürümlerini, şifre paketlerini (cipher suite'leri) ve rastgele bir sayı (client random) gönderir.
  2. ServerHello: Sunucu, seçilen TLS sürümünü, şifre paketini, kendi rastgele sayısını (server random) ve dijital sertifikasını gönderir.
  3. Sertifika Doğrulama: İstemci, sunucunun sertifikasının güvenilir bir CA (Certificate Authority) tarafından imzalandığını doğrular.
  4. Anahtar Değişimi: Taraflar (genelde Diffie-Hellman veya RSA tabanlı bir yöntemle) ortak bir "pre-master secret" üzerinde anlaşır, bu değerden hem client random hem server random kullanılarak nihai oturum anahtarları türetilir.
  5. Finished mesajları: Her iki taraf da el sıkışmanın bütünlüğünü doğrulayan şifrelenmiş bir mesaj gönderir.

Bu süreç, gerçek veri iletimi başlamadan önce 2 round-trip (istemci-sunucu arası gidiş-dönüş) gerektirir — bu, özellikle yüksek gecikmeli (latency) bağlantılarda fark edilir bir performans maliyetidir.

TLS 1.3'ün Devrimi: 1-RTT ve 0-RTT

TLS 1.3, el sıkışma sürecini önemli ölçüde sadeleştirdi ve hızlandırdı:

  • 1-RTT el sıkışması: İstemci artık ClientHello mesajında, desteklediği anahtar değişim parametrelerini (key share) DOĞRUDAN gönderir — sunucunun hangi parametreleri seçtiğini öğrenmek için ayrı bir round-trip beklemesine gerek kalmaz. Bu, el sıkışma süresini TLS 1.2'nin yarısına indirir.
  • 0-RTT (sıfır round-trip) devam eden oturumlar için: İstemci, daha önce aynı sunucuyla kurduğu bir oturumdan elde edilen bir "resumption ticket" kullanarak, hiçbir el sıkışma beklemeden İLK isteğiyle birlikte şifreli veri gönderebilir. Bu ciddi bir hız avantajı sağlar ama önemli bir güvenlik zayıflığı taşır: replay saldırılarına (aynı 0-RTT isteğinin bir saldırgan tarafından yakalanıp tekrar gönderilmesi) karşı doğal bir koruma sağlamaz — bu yüzden 0-RTT genelde sadece "tekrar gönderilmesi zararsız" olan işlemler (örneğin GET istekleri) için önerilir, ödeme veya hesap değiştirme gibi durum değiştiren (state-changing) işlemler için kullanılmamalıdır.

TLS 1.3'te Kaldırılan Zayıf Bileşenler

TLS 1.3, önceki sürümlerde bilinen zafiyetlere yol açmış birçok zayıf bileşeni protokolden tamamen çıkardı:

  • RSA tabanlı statik anahtar değişimi (Perfect Forward Secrecy sağlamadığı için) kaldırıldı — artık sadece (EC)DHE gibi PFS sağlayan yöntemler zorunludur.
  • RC4, DES, MD5 gibi kriptografik olarak zayıf/kırılmış algoritmalar tamamen listeden çıkarıldı.
  • Sıkıştırma (compression) kaldırıldı çünkü CRIME gibi saldırılar, sıkıştırma sırasında oluşan boyut farklarından şifreli verinin içeriği hakkında bilgi sızdırabiliyordu.

Sertifika Doğrulama Zinciri

Bir istemci, sunucunun sertifikasını doğrularken bir "güven zinciri" (chain of trust) izler: sunucu sertifikası → ara (intermediate) CA sertifikası → kök (root) CA sertifikası. Kök CA sertifikaları, işletim sistemi veya tarayıcı tarafından önceden güvenilir olarak yüklenmiştir (trust store). Zincirdeki herhangi bir sertifika süresi dolmuşsa, iptal edilmişse (revoked) veya imza geçersizse, bağlantı reddedilir.

Pratik Senaryo

Bir e-ticaret sitesi, sayfa yükleme hızını artırmak için TLS 1.3'e geçiyor ve dönen ziyaretçiler için 0-RTT özelliğini etkinleştiriyor. Güvenlik ekibi, ödeme sayfasına giden isteklerin 0-RTT ile işlenmemesi gerektiğini fark ediyor çünkü bir saldırgan, ağı dinleyip bir 0-RTT ödeme isteğini yakalayabilir ve daha sonra bu isteği tekrar sunucuya gönderebilir (replay) — sunucu bunun orijinal, meşru bir istek mi yoksa tekrarlanmış bir kopya mı olduğunu 0-RTT katmanında ayırt edemez. Ekip, ödeme akışını 0-RTT'den hariç tutup sadece normal sayfa yüklemelerinde bu hızlandırmayı kullanarak hem performans avantajından faydalanıyor hem de kritik işlemleri güvende tutuyor.

Bu makale, TLS/SSL el sıkışma sürecinin orta-ileri seviye teknik bir özetidir; SiberCrew ekibi tarafından hazırlanmış özgün içeriktir.