TLS el sıkışması

Adres çubuğundaki kilit simgesi tek şey söyler: tarayıcı ile sunucu arasında TLS (Transport Layer Security) kuruldu. TLS, HTTP mesajlarını olduğu gibi alır ve şifreli bir tünelde taşır. HTTPS'in varsayılan portu 443'tür. Aynı protokol e-posta sunucularında, veritabanı bağlantılarında ve API çağrılarında da çalışır.

Altay Kargo'nun müşteri paneli, mobil uygulaması ve iç servisleri her gün binlerce TLS bağlantısı açar. Bu derste bir bağlantının ilk milisaniyelerinde neler olduğunu, sertifikanın neyi kanıtladığını ve sunucuyu nasıl sağlamlaştıracağını öğrenirsin. Son bölümde de en pahalı hatalardan birini, sertifika doğrulamasını kapatmayı incelersin.

TLS üç güvence verir. Gizlilik: aradaki kişi veriyi okuyamaz. Bütünlük: veri yolda değişirse fark edilir.

Kimlik doğrulama: istemci, konuştuğu sunucunun gerçekten o alan adının sahibi olduğunu bilir. Tünel kurulmadan önce iki taraf pazarlık eder.

Hangi şifre takımını kullanacaklar? Sunucu gerçekten iddia ettiği sunucu mu? Veriyi hangi anahtarla şifreleyecekler? Bu pazarlığın adı el sıkışmadır (handshake).

Önceki derste gördüğün iki aile burada birlikte çalışır. Asimetrik kısım anahtar anlaşmasını ve kimliği, simetrik kısım veriyi üstlenir.

TLS 1.2'de tam el sıkışma iki gidiş dönüş sürerdi. TLS 1.3 bunu bire indirdi. Yöntem basit: istemci anahtar payını (key_share) doğrudan ilk mesajına koyar.

Sunucu yanıtında kendi payını döner ve iki taraf ortak sırrı hemen hesaplar. Bu kısaltmanın adı 1-RTT'dir.

İstemci yanlış tahmin ederse, yani sunucunun desteklemediği bir grup için pay yollarsa, sunucu HelloRetryRequest mesajıyla doğru grubu ister. O durumda el sıkışma bir tur uzar. İstemciler bu yüzden en yaygın gruplar için payı baştan yollar.

Şemayı soldan sağa oku. ClientHello, desteklenen şifre takımlarını, istemcinin anahtar payını ve bağlanmak istediği alan adını taşır; bu ada SNI denir. ServerHello sunucunun payını döner. RFC 8446'ya göre ServerHello'dan sonraki bütün el sıkışma mesajları şifreli gider, sertifika da artık açıkta dolaşmaz.

Sunucu sertifikasını ve o ana kadarki el sıkışma mesajları üzerinden attığı imzayı (CertificateVerify) yollar. İki tarafın Finished mesajı pazarlığı mühürler, çünkü o ana kadarki bütün mesajların özetini doğrular. Biri araya girip bir mesajı değiştirdiyse Finished tutmaz. Ardından uygulama verisi akar.

TLS 1.3 şifre takımı listesini de sadeleştirdi. RFC 8446 yalnız beş takım tanımlar ve hepsi kimlik doğrulamalı şifreleme kullanır. TLS_AES_128_GCM_SHA256 adını parçalarına ayır: veri AES-128 ile GCM modunda şifrelenir, anahtar türetme ve el sıkışma özeti SHA-256 kullanır. TLS_CHACHA20_POLY1305_SHA256 ise AES donanımı olmayan cihazlar için hızlı bir seçenektir.

Anahtar değişimi ve imza algoritması artık takım adında yer almaz, ayrı uzantılarla pazarlık edilir. Bu sadelik, yanlış yapılandırma yüzünden zayıf bir takımın seçilmesini de büyük ölçüde önler.

Anahtar anlaşmasını ECDHE (geçici eliptik eğri Diffie-Hellman) yapar. İki taraf her oturum için yeni bir geçici anahtar çifti üretir. Açık kısımları değişirler ve aynı ortak sırra ulaşırlar. Kabloyu dinleyen kişi değişilen payları görür ama ortak sırrı hesaplayamaz.

Ortak sır doğrudan anahtar olarak kullanılmaz. HKDF adlı türetme işlevi, bu sırdan ve el sıkışmanın özetinden iki yön için ayrı oturum anahtarları üretir. İstemciden sunucuya giden veri bir anahtarla, sunucudan istemciye giden veri başka bir anahtarla şifrelenir.

Geçici kelimesi kritik. Oturum bitince geçici anahtar atılır. Saldırgan bugünkü trafiği kaydetse, yıllar sonra sunucunun uzun ömürlü özel anahtarını çalsa bile kayıtları açamaz. Bu özelliğin adı ileri gizliliktir (forward secrecy).

Eski sürümlerde statik RSA anahtar değişimi vardı: istemci oturum sırrını sunucunun açık anahtarıyla şifreleyip yollardı. Özel anahtarı ele geçiren, kaydedilmiş bütün eski trafiği de açardı. TLS 1.3 statik RSA anahtar değişimini tamamen kaldırdı, artık her açık anahtarlı anahtar değişimi ileri gizlilik taşır.

TLS 1.3'ün bir de 0-RTT seçeneği var. İstemci daha önce bağlandığı sunucuya dönerken önceki oturumdan kalan ortak anahtarla (PSK) ilk mesajın yanında veri de yollar. Kazanç bir turluk gecikmedir, bedeli ise güvenliktir. RFC 8446, erken verinin bağlantılar arasında tekrar oynatılmaya (replay) karşı korunmadığını açıkça yazar.

Aradaki biri aynı erken veriyi sunucuya ikinci kez gönderebilir. Bir para transferi isteği iki kez işlenirse zarar gerçektir. 0-RTT'yi bu yüzden yalnız tekrarı zararsız isteklerde, örneğin sayfa okuyan GET isteklerinde açarsın. Sunucu şüphelendiği erken veriyi 425 Too Early yanıtıyla geri çevirebilir.

2026: trafik kaydı (TLS 1.3, ECDHE)
2030: sunucu özel anahtarı sızdı
2030: kayıt + özel anahtar -> ?

Kimlik kanıtı sertifikadan gelir. Sertifika, alan adını sunucunun açık anahtarına bağlar ve altında sertifika otoritesinin (CA) imzası durur. Tarayıcı bu imzayı zincir boyunca yukarı doğru izler: yaprak sertifika, ara sertifika, kök sertifika. Kök sertifikalar işletim sistemine ve tarayıcıya gömülü gelir.

Ara sertifikayı göndermek ise sunucunun işidir. Sunucu yalnız yaprak sertifikayı yollarsa bazı istemciler zinciri tamamlayamaz ve bağlantıyı reddeder. Bu hata özellikle mobil uygulamalarda ve komut satırı araçlarında sık görülür.

Doğrulamada üç soru sorulur. Alan adı sertifikadaki adla eşleşiyor mu? Süresi dolmuş mu?

Zincir güvenilen köke ulaşıyor mu? Birinin cevabı olumsuzsa tarayıcı uyarı ekranı basar. Doğrulama yapılmazsa ECDHE yine şifreli kanal kurar, ama kanalın öbür ucunda kimin olduğunu bilemezsin.

Kilit simgesi yalnız trafiğin şifreli olduğunu söyler, sitenin iyi niyetli olduğunu söylemez. Oltalama siteleri de kendi alan adları için geçerli sertifika alır. Bu üç soruyu komut satırında kendin de sorabilirsin. Aşağıda Altay Kargo'nun test ortamındaki yönetim paneline yapılan bir bağlantı var.

$ openssl s_client -connect panel.altaykargo.example:443 -servername panel.altaykargo.example
depth=2 CN=Altay Test Kok CA
verify return:1
depth=1 CN=Altay Test Ara CA
verify return:1
depth=0 CN=panel.altaykargo.example
verify return:1
---
Certificate chain
 0 s:CN=panel.altaykargo.example
   i:CN=Altay Test Ara CA
   v:NotBefore: Sep 20 08:00:00 2026 GMT; NotAfter: Dec 19 08:00:00 2026 GMT
 1 s:CN=Altay Test Ara CA
   i:CN=Altay Test Kok CA
---
Negotiated TLS1.3 group: X25519MLKEM768
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Verify return code: 0 (ok)

Çıktıyı yukarıdan aşağı oku. depth satırları zinciri kökten yaprağa doğru gösterir; her birinin altındaki verify return:1 o halkanın doğrulandığını söyler. Certificate chain bölümünde s alanı sertifikanın sahibini, i alanı onu imzalayan otoriteyi verir.

Yaprağın i alanı ara sertifikanın s alanıyla eşleşir, zincir böyle kurulur. v satırı geçerlilik aralığıdır. Alttaki satırlar pazarlığın sonucudur: TLSv1.3 sürümü, TLS_AES_256_GCM_SHA384 takımı ve X25519 ile ML-KEM'i birleştiren hibrit anahtar grubu.

Son satırdaki 0 (ok), zincirin güvenilen köke ulaştığını söyler. -servername bayrağı SNI değerini açıkça yollar. s_client ad eşleşmesini ise varsayılan olarak denetlemez; bunun için -verify_hostname bayrağını eklersin.

Sertifika dünyası iki yönde değişiyor. Birincisi şeffaflık. Sertifika Şeffaflığı (CT), kamuya açık otoritelerin verdiği sertifikaları herkesin okuyabildiği ve yalnız eklenebilen günlüklere yazar.

Büyük tarayıcılar bu kaydı olmayan sertifikaya güvenmez. Savunan taraf da bu günlükleri izler ve kendi alan adına habersiz verilmiş bir sertifikayı yakalar.

İkincisi kısa ömür. CA/Browser Forum'un 2025'te kabul ettiği SC-081 kararıyla azami geçerlilik 15 Mart 2026'da 398 günden 200 güne indi. Süre 2027'de 100 güne, 2029'da 47 güne inecek. Bu tempoyu elle yenilemeyle tutamazsın; ACME protokolü (RFC 8555) yenilemeyi otomatikleştirir.

Eski sürümler artık kabul görmez: SSL 3.0 çok önce düştü. IETF, TLS 1.0 ve 1.1'i 2021'de RFC 8996 ile resmen kullanımdan kaldırdı. Bugün alt sınır TLS 1.2, hedef TLS 1.3'tür. Eski sürümlerde saldırgan pazarlığı zayıf seçeneğe düşürmeye çalışırdı.

TLS 1.3 zayıf seçenekleri listeden attı ve sürüm düşürme girişimini fark etmeye yarayan bir işaret ekledi. Sunucunu yapılandırırken ayarları tek tek ezberlemen gerekmez. Güncel yapılandırma rehberleri iki profil sunar: yalnız TLS 1.3 açan modern profil ve TLS 1.2 ile 1.3'ü birlikte açan orta (intermediate) profil. Hizmetlerin büyük çoğunluğu için orta profil önerilir.

# nginx, orta profil
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1:secp384r1;
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;
ssl_prefer_server_ciphers off;

Yapılandırmayı satır satır oku. ssl_protocols yalnız TLS 1.2 ve 1.3'ü açar; TLS 1.1 ile gelen istemci el sıkışmayı tamamlayamaz. ssl_ecdh_curve anahtar anlaşması gruplarını tercih sırasıyla verir.

Baştaki X25519MLKEM768, s_client çıktısında gördüğün kuantum sonrası hibrit gruptur ve sunucuda OpenSSL 3.5 ya da daha yeni bir sürüm ister. ssl_ciphers yalnız TLS 1.2 takımlarını belirler. Listedeki her takım ECDHE ile ileri gizlilik, GCM ya da ChaCha20 ile kimlik doğrulamalı şifreleme taşır.

TLS 1.3 takımlarına ayrıca dokunmazsın, çünkü OpenSSL'in varsayılan TLS 1.3 takımları zaten güçlüdür. Son satır seçimi istemciye bırakır. Listede zayıf takım kalmadığı için istemci kendi donanımına en uygun olanı seçer. Değişiklikten sonra s_client ile yeniden bağlanır, sürümü ve takımı doğrularsın.

Sunucu tarafında bir işin daha var. Düz HTTP isteğini 301 yanıtıyla HTTPS adresine yönlendirirsin. Yalnız yönlendirme yetmez, çünkü ilk istek hâlâ düz HTTP ile gider. Aradaki biri o isteği yakalar ve kullanıcıyı şifresiz bir sayfada tutabilir; bu saldırıya SSL stripping denir.

Çözüm HSTS (HTTP Strict Transport Security) başlığıdır. Başlık tarayıcıya, belirtilen süre boyunca o alan adına yalnız HTTPS ile gitmesini söyler. RFC 6797'ye göre tarayıcı düz HTTP üstünden gelen HSTS başlığını yok sayar. Başlık yalnız şifreli yanıtta anlam taşır.

HTTP/1.1 200 OK
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Content-Type: text/html; charset=utf-8

Başlığı parça parça oku. max-age saniye cinsindendir; 31536000 bir yıl eder ve tarayıcı bu süre boyunca alan adına düz HTTP ile hiç gitmez. includeSubDomains kuralı bütün alt alan adlarına yayar. preload ise alan adını tarayıcıların yerleşik HSTS listesine eklemek istediğini belirtir.

Listedeki alan adına ilk ziyaret bile HTTPS ile gider. Sık hata, bütün alt alan adları HTTPS'e hazır değilken includeSubDomains açmaktır. Yalnız HTTP ile çalışan eski bir iç panel o anda erişilemez hâle gelir. Önce kısa bir max-age ile dener, sorun çıkmazsa süreyi uzatırsın.

Aynı kavramları tarayıcı dışında düşün. Altay Kargo'nun mobil uygulaması kendi API sunucusuna TLS 1.3 ile bağlanıyor. Geliştirici, testte kendi imzaladığı sertifikayı kabul etsin diye sertifika doğrulamasını kapatmış ve bu ayar yayına çıkmış.

Kullanıcı kafedeki ortak Wi-Fi ağına bağlanıyor. Aynı ağdaki biri trafiği kendi üstüne yönlendirebiliyor. Bağlantı yine şifreli kurulacak, kilit yine yerinde duracak.

Kullanıcı ekranda hiçbir uyarı görmez. Asıl soru, uygulamanın kiminle şifreli konuştuğu.

Bu hata kodda tanıdık izler bırakır. Python'da verify=False, Go'da InsecureSkipVerify: true, Node'da rejectUnauthorized: false ve Android'de her sertifikayı kabul eden boş bir TrustManager aynı ailenin üyeleridir. Kod incelemesinde ve statik analizde bu ifadeleri ararsın.

Test ortamı için doğrulamayı kapatmak yerine kendi test CA'nı yalnız test yapılandırmasına güvenilir kök olarak eklersin. Yayındaki uygulamada bir adım ileri gidip sertifika sabitleme (pinning) uygulayabilirsin. Ama sabitlenen anahtarın yedeğini ve yenileme planını önceden hazırlarsın, yoksa sertifika yenilendiğinde uygulama kendi sunucusuna bağlanamaz.