TLS 1.3 El Sıkışma Diyagramı: Adım Adım, Oturum Sürdürme ve mTLS ile

Her HTTPS isteği, çoğu mühendisin hiç bakmadığı bir konuşmayla başlar. Tarayıcınız GET / göndermeden önce sunucuyla bir protokol sürümünde anlaşır, anahtar değiş tokuş eder, bir sertifikayı kontrol eder ve bunların hiçbirinin kurcalanmadığını kanıtlar. Bu iş ters gittiğinde handshake_failure ya da bad_certificate gibi anlaşılması güç hatalar alırsınız; yavaş gittiğinde ise her sayfa bunun bedelini öder.

TLS 1.3, el sıkışmayı TLS 1.2'ye göre daha kısa ve daha gizli hâle getirdi. Bu yazı onu bir sekans diyagramıyla mesaj mesaj ele alıyor, ardından üretimde karşılaşacağınız varyasyonları anlatıyor: HelloRetryRequest, oturum sürdürme ve 0-RTT, karşılıklı TLS, Encrypted Client Hello ve kuantum sonrası anahtar değişimi.

El sıkışmanın başarması gerekenler

Bir TLS el sıkışması, herhangi bir uygulama verisi akmadan önce dört iş yapar:

1. Parametreleri müzakere etmek: protokol sürümü, şifre takımı (cipher suite) ve anahtar değişimi grubu.
2. Ortak anahtarlar kurmak: İki taraf da sırları hiç göndermeden aynı sırları türetir.
3. Sunucunun kimliğini sertifikalarla doğrulamak; isteğe bağlı olarak istemcininkini de.
4. Bütünlüğü teyit etmek: İki taraf da aynı el sıkışma mesajlarını gördüklerini kontrol eder; böylece bir saldırgan müzakereyi daha zayıf seçeneklere düşüremez ya da değiştiremez.

Güncel spesifikasyon, Temmuz 2026'da yayımlanan RFC 9846 belgesidir. RFC 8446'nın yerini alır ama aynı protokol sürümünü korur; bu yüzden eski RFC'ye göre yazılmış bir TLS 1.3 istemcisi, yenisine göre yazılmış bir sunucuyla konuşmaya devam eder.

Tam el sıkışma, mesaj mesaj

TLS 1.3 tek bir gidiş-dönüşe ihtiyaç duyar. İstemci, sunucunun hangi anahtar değişimini kabul edeceğini tahmin eder ve anahtar değişiminin kendi yarısını daha ilk mesajda gönderir.

Önemli olan ServerHello'dan sonraki satırdır. İstemci sunucunun key share'ini aldığında iki taraf da anahtar takvimini (ortak sır ve transkript üzerinde HKDF) çalıştırır ve el sıkışma trafik anahtarlarını türetir. O andan itibaren her el sıkışma mesajı şifrelenir. TLS 1.2'de ağdaki bir gözlemci sunucunun sertifikasını okuyabiliyordu; TLS 1.3'te okuyamaz.

CertificateVerify, sunucunun az önce gönderdiği sertifikanın özel anahtarına sahip olduğunu kanıtlar. Finished, iki tarafın da aynı mesajları gördüğünü kanıtlar. Bir saldırgan ClientHello'dan bir şifre takımını çıkarsaydı transkriptler farklılaşır ve Finished kontrolü başarısız olurdu.

Sunucu kendi Finished mesajının hemen ardından uygulama verisi gönderebilir; istemci de ilk isteğini kendi Finished mesajından hemen sonra gönderir. ClientHello'dan bir gidiş-dönüş sonra şifreli bağlantı hazırdır.

TLS 1.2'den bu yana neler değişti

Şifre takımı listesi TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256 ve iki CCM takımına indi. Bir TLS 1.3 şifre takımı artık yalnızca kayıt şifrelemesini ve hash'i adlandırır; anahtar değişimi ve imza algoritması ayrı müzakere edilir. RSA sertifikaları hâlâ çalışır. Ortadan kalkan, istemcinin sırrı sunucunun açık anahtarıyla şifrelediği ve çalınan bir anahtarın kaydedilmiş her oturumu çözdüğü RSA anahtar taşımasıdır.

Tek gidiş-dönüş ikiye çıktığında: HelloRetryRequest

Tek gidiş-dönüşlük el sıkışma bir tahmine dayanır. İstemci, sunucunun kabul etmesini beklediği gruplar için key share gönderir; genellikle X25519. Sunucu bunların hiçbirini desteklemiyorsa, kabul ettiği bir grubu belirten bir HelloRetryRequest ile yanıt verir ve istemci yeni bir ClientHello ile baştan başlar. Bu, tam bir ek gidiş-dönüşe mal olur.

Bunu istemci ile sunucu gruplar konusunda anlaşamadığında görürsünüz; örneğin yalnızca P-256 için yapılandırılmış bir sunucu ve yalnızca X25519 share'i gönderen bir istemci. Çözüm yapılandırmadır: İstemcilerinizin önce sunduğu grupların, sunucularınızın tercih ettikleri olduğundan emin olun.

Oturum sürdürme ve 0-RTT

El sıkışmadan sonra sunucu NewSessionTicket mesajları gönderebilir. Bir bilet (ticket), istemcinin daha sonra tam bir sertifika değişimi yerine önceden paylaşılmış bir anahtarla (PSK) oturumu sürdürmesini sağlar. Sürdürme normalde yine de yeni bir (EC)DHE değişimi çalıştırır; böylece sürdürülen oturum ileri gizliliğini korur.

Bir biletle istemci, 0-RTT denen erken veri de gönderebilir: İlk istek ClientHello ile aynı mesaj dizisinde (flight) gider. Bir gidiş-dönüş kazandırır, ancak RFC 9846, 0-RTT verisinin bağlantılar arasında tekrar oynatmaya (replay) karşı hiçbir garantisi olmadığını açıkça belirtir. İlk mesaj dizisini yakalayan bir saldırgan onu yeniden gönderebilir.

Pratik kurallar:

• Erken veri olarak yalnızca idempotent istekler gönderin: yan etkisi olmayan GET; asla bir ödeme ya da sipariş değil.
• Sunucuda 0-RTT'yi yalnızca uygulamanın tekrar oynatmaları reddedebildiği ya da tolere edebildiği yerlerde etkinleştirin. Birçok sunucu erken veri isteklerini işaretler (örneğin RFC 8470'te tanımlanan Early-Data: 1 başlığıyla); böylece uygulama 425 Too Early ile yanıt verebilir.
• Tekrar oynatmayı düşünüp taşınmadıysanız 0-RTT'yi kimliği doğrulanmış işlemler için kullanmayın.

Karşılıklı TLS

Karşılıklı TLS'te (mTLS) sunucu istemciden de bir sertifika ister. Sunucu EncryptedExtensions'tan sonra bir CertificateRequest ekler; istemci de kendi Finished mesajından önce kendi Certificate ve CertificateVerify mesajlarıyla yanıt verir. Gidiş-dönüş sayısı değişmez.

mTLS, bir mesh içindeki servisler arasında varsayılandır: Her iş yükü kısa ömürlü bir sertifika alır ve sidecar'lar ya da proxy'ler el sıkışmayı yürütür. Service mesh mimari diyagramı bu sertifikaların nereden geldiğini gösteriyor; sıfır güven mimarisi diyagramı ise istek başına kimliğin, isteğin geldiği ağdan neden daha önemli olduğunu açıklıyor.

Gizlilik ve kuantum sonrası anahtarlar: 2026'da yeni olanlar

Yakın tarihli iki RFC, el sıkışmanın ağda nasıl göründüğünü değiştiriyor.

Encrypted Client Hello. ClientHello henüz hiçbir anahtar yokken gönderilir; bu yüzden SNI, yani istemcinin istediği host adı, açık metin olarak gider. Mart 2026'da yayımlanan RFC 9849, Encrypted Client Hello'yu (ECH) tanımlar: İstemci, gerçek host adı dahil bir iç ClientHello'yu, sunucunun DNS'te yayımladığı bir anahtarla şifreler. Gözlemciler yalnızca, genellikle büyük bir sağlayıcıya ait olan, herkese açık bir dış ad görür.

Hibrit kuantum sonrası anahtar değişimi. Bugün kaydedilen trafik ileride bir kuantum bilgisayarla çözülebilir; bu yüzden ilk değişen anahtar değişimi oluyor. Ağustos 2026'da yayımlanan RFC 10024, X25519 ile ML-KEM-768'i birleştiren X25519MLKEM768 gibi hibritleri tanımlar. İki share de anahtar takvimine girer; böylece algoritmalardan biri dayandığı sürece bağlantı güvende kalır. Chrome ve Edge 131 ve sonrası ile Firefox 132 ve sonrası bunu varsayılan olarak sunar.

Bedeli boyuttur. Bir X25519MLKEM768 istemci share'i 1.216 bayt, sunucu share'i 1.120 bayttır; düz X25519'da ise her biri 32 bayttır. Bir ClientHello artık iki pakete yayılabiliyor ve bu, bunun asla olmayacağını varsayan ara kutuları (middlebox) açığa çıkardı.

Gidiş-dönüş maliyeti

Bir bağlantının ne kadar çabuk hazır olacağını bant genişliği değil, gidiş-dönüşler belirler. İstemci ile sunucu arasında 100 ms'lik bir gidiş-dönüşle, DNS'i saymazsak:

QUIC aynı TLS 1.3 el sıkışmasını kendi paketleri içinde taşır (RFC 9001) ve onu taşıma katmanı el sıkışmasıyla birleştirir; fazladan gidiş-dönüş de burada ortadan kalkar. TLS'i kullanıcılara yakın bir yerde, bir CDN'de ya da uçtaki bir yük dengeleyicide sonlandırmak gidiş-dönüşün kendisini kısaltır; yük dengeleyici diyagramı sonlandırmanın genellikle nerede yapıldığını ele alıyor.

El sıkışma diyagramı

Nasıl okunur:

• İki yaşam çizgisi. Solda istemci, sağda sunucu. Zaman aşağı doğru akar.
• Düz oklar açık metin olarak gönderilir: ClientHello ve ServerHello. “handshake keys” olarak işaretlenmiş çizginin altındaki her şey şifrelidir.
• Sunucunun mesaj dizisi EncryptedExtensions, Certificate, CertificateVerify ve Finished'ı tek seferde taşır; el sıkışmanın tek gidiş-dönüşe sığmasının nedeni budur.
• İsteğe bağlı parça, yalnızca karşılıklı TLS'te gönderilen istemcinin Certificate ve CertificateVerify mesajlarını içerir. Sunucunun dizisindeki kesikli CertificateRequest bunları isteyen mesajdır.
• Markdown bloğu el sıkışmanın başarılı olup olmayacağını belirleyen uzantıları listeler: sürümler, gruplar, imza algoritmaları, SNI ve ALPN.

Hata ayıklamaya yarayan protokol diyagramları çizmek

• Şifreleme sınırını işaretleyin. TLS hakkındaki en yaygın soru, bir gözlemcinin neyi görebildiğidir. Çizgiyi çizin.
• Önemli uzantıları adlandırın, hepsini değil. key_share ve supported_versions hataların çoğunu açıklar.
• İsteğe bağlı ve alternatif yolları parçalara koyun. İstemci sertifikaları için bir opt parçası ve HelloRetryRequest için bir alt parçası ana akışı okunabilir tutar.
• Her soru için bir diyagram tutun. Tam bir el sıkışma, 0-RTT'li bir sürdürme ve bir mTLS değişimi, her biri ayrıntı gerektiriyorsa üç ayrı diyagramdır.

Sekans diyagramı örneği yaşam çizgilerini, parçaları ve adlandırma kurallarını daha ayrıntılı ele alıyor.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Sekans paketinden Client ve Server adlı iki Yaşam çizgisi düğümü ekleyin.
3. Mesajları yaşam çizgileri arasında yukarıdan aşağıya kenarlar olarak çizin: ClientHello, ServerHello, ardından sunucunun dört şifreli mesajı ve istemcinin Finished mesajı. Her kenarı mesaj adı ve temel alanlarıyla etiketleyin.
4. İstemcinin Certificate ve CertificateVerify mesajlarının çevresine, Sekans paketinden opt operatörlü bir Parça ekleyin ve sunucunun CertificateRequest mesajını kesikli bir kenar olarak çizin.
5. Temel paketinden uzantıları ve gidiş-dönüş sayısını içeren bir Markdown bloğu ve şifrelemenin nerede başladığını işaretleyen bir Not ekleyin.

Örnek 4 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

Bir TLS 1.3 el sıkışması kaç gidiş-dönüş sürer? Yeni bir bağlantı için bir; TLS 1.2'de ise iki. Bir HelloRetryRequest ikincisini ekler; 0-RTT ile sürdürme ise istemcinin ilk isteğini hiç el sıkışma gidiş-dönüşü olmadan göndermesini sağlar.

TLS 1.3'te sunucu sertifikası şifreli mi? Evet. Certificate mesajı dahil ServerHello'dan sonraki her şey el sıkışma anahtarlarıyla şifrelenir. ClientHello şifrelenmez; Encrypted Client Hello'nun kapattığı boşluk budur.

0-RTT'yi etkinleştirmek güvenli mi? Yalnızca tekrar oynatılması güvenli olan istekler için. Erken veri yakalanıp yeniden gönderilebilir; bu yüzden onu idempotent isteklerle sınırlayın ve uygulamanın geri kalan her şeyi 425 Too Early ile reddetmesine izin verin.

TLS 1.3 hâlâ RSA sertifikalarını destekliyor mu? Evet. RSA imzaları sunucuların kimliğini doğrulamak için hâlâ kullanılır. TLS 1.3, oturum sırrının sunucunun RSA anahtarıyla şifrelendiği ve sızan bir anahtarın geçmiş trafiği açığa çıkardığı RSA anahtar taşımasını kaldırdı.

TLS ile mTLS arasındaki fark nedir? Normal TLS'te yalnızca sunucu bir sertifika sunar. Karşılıklı TLS'te sunucu istemciden de sertifika ister; böylece iki taraf da aynı el sıkışmada doğrulanır.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.