Bölüm 11: TLS El Sıkışması

Simetrik şifreleme, anahtar uzlaşması ve imza ayrı ayrı elinde. Üçünü tek bir kanalda birleştiren şey bir bağlantı.

Kilit o kanalda kuruluyor ve birkaç mesaja sığıyor. Peki el sıkışma neyi pazarlıyor?

Kilit nereye takılıyor?

Kilidin adı TLS (Transport Layer Security) ve adındaki “transport layer” yanıltıcı: kilit transport layer’ın içine takılmıyor, onun bir üstünde, programların kendi dilini konuştuğu application layer’da (uygulama katmanı) kuruluyor. Uygulama bir TLS kitaplığı çağırıyor, kitaplık da TCP’yi çağırıyor; sıra bu ve tersi değil. TCP’nin kendisi hiç değişmiyor: aynı sıra numaraları, aynı pencere, aynı bayraklar. Değişen tek şey, sokete düz yazdığın metnin ağa şifreli çıkması.

Bunun pratik karşılığı 443 numaralı port. Kilitli web trafiği oradan geçiyor ama o port sıradan bir port; yol üstündeki router’lar orada özel hiçbir iş yapmıyor. Şifrelemeyi iki uç kendi arasında hallediyor. Kitaplık web’e özel de değil: isim sorgusunu gizleyen DoH ve DoT da altında aynı kilidi taşıyor.

Kilidin verdiği söz üç parçalı. Gizlilik simetrik şifrelemeden geliyor. Bütünlük kriptografik özetlemeden, kimlik doğrulama ise açık anahtar kriptografisinden. Üçü ayrı ayrı gerekiyor, çünkü şifreleme tek başına kurcalamayı engellemiyor. Okuyamayan biri de bitleri karıştırabilir; kilitli bir kutuyu açamadan sallamaya benziyor.

Kilitsiz HTTP bu üç sözden hiçbirini vermiyor. Hat dinlemeye de MITM saldırısına da açık. Amaç, dürüst olması beklenmeyen bir ağın üstünde dürüst bir kanal kurmak. Adı hâlâ SSL diye anılan eski protokol 2015’te kullanımdan kaldırıldı; bugünkü sürüm TLS 1.3 ve künyesi RFC 8446.

Tek gidiş-dönüş nasıl mümkün oldu?

El sıkışmanın dört işi var ve dördü de birkaç mesajın içine sığıyor: sürüm pazarlığı yapmak, kriptografik algoritmaları seçmek, karşı tarafı doğrulamak ve ortak anahtar malzemesi kurmak. Bunlar üç evreye dağılmış: Key Exchange, Server Parameters, Authentication. İlk evre bittikten sonra geriye kalan her şeyi şifreli akarken göreceksin; sunucunun sertifikası bile açıkta gitmiyor.

İlk mesaj ClientHello. İçinde 32 bayt uzunluğunda bir rastgele değer, önerilen protokol sürümleri, simetrik şifre ile anahtar türetme işlevinin (HKDF) özet çiftlerinden oluşan liste ve key_share uzantısında bir dizi Diffie-Hellman anahtar payı duruyor. Sürüm alanına ayrıca bak, çünkü tuhaf görünüyor. Adı legacy_version ve içine 0x0303, yani TLS 1.2 yazılıyor; gerçek sürüm ise supported_versions uzantısında 0x0304 olarak duruyor. Sebebi uyumluluk: yol üstündeki eski kutular tanımadıkları bir sürüm numarası görünce bağlantıyı düşürüyordu.

ClientHello’nun bir uzantısı daha var ve ilk durakta bıraktığım düğümü o çözüyor: SNI (Server Name Indication, server_name uzantısı). Aynı adres ve portta yüzlerce siteyi barındıran bir sunucu hangi sertifikayı sunacağına ancak istenen adı görerek karar verebilir; ama sertifika gelmeden şifreleme de kurulamaz. Çözüm, adı ilk mesajda, henüz şifresizken göndermek. Bedeli şu: ClientHello açıkta gittiği için yolun üstündeki herkes hangi siteye bağlandığını görüyor. Şifreli ad çözmenin kapatamadığı sızıntı buydu. Onu da kapatan uzantının adı ECH (Encrypted Client Hello): sunucunun açık anahtarı DNS’teki HTTPS kaydından alınıyor ve ad o anahtarla şifrelenip gönderiliyor. Yol üstündeki kutu artık yalnızca barındırma sağlayıcısının herkese açık ön adını görüyor, asıl adı değil.

Bir gidiş-dönüşü kurtaran hileyi de burada göreceksin. İstemci sunucunun hangi grubu seçeceğini tahmin ediyor ve anahtar payını daha ilk mesajda gönderiyor. Sunucu kabul ederse ortak sır ikinci mesajda zaten hesaplanabilir hâle geliyor. Tahmin tutmazsa sunucu HelloRetryRequest yolluyor, istemci el sıkışmayı doğru grupla baştan kuruyor ve bir gidiş-dönüş daha ödüyor. El sıkışma özeti sıfırlanmıyor: ilk alışveriş de özete giriyor.

istemci -> sunucu   ClientHello           random 32 bayt, key_share, supported_versions
sunucu  -> istemci  ServerHello           seçilen takım, sunucunun key_share'i
                    EncryptedExtensions   <-- buradan sonrası şifreli
                    Certificate
                    CertificateVerify
                    Finished
istemci -> sunucu   Finished
                    [uygulama verisi]

El sıkışmanın hangi mesajında neyin kararlaştığını sırayla görelim:

Dökümde ServerHello satırına bak: seçilen şifre takımını ve sunucunun kendi payını taşıyor. Hemen ardından gelen EncryptedExtensions, sunucu el sıkışma trafik sırrından türeyen anahtarlarla korunan ilk mesaj. Finished ise doğrulama bloğunun sonuncusu: el sıkışmanın bütünlüğünü ve hesaplanan anahtarların doğruluğunu mühürlüyor. İçeriği yanlış çıkarsa bağlantı decrypt_error uyarısıyla kesiliyor; el sıkışmaya karışan bir kutu varsa tam burada yakalanıyor.

Sertifikayı burada yalnızca sunucunun gönderdiği imzalı belge olarak alıp geçiyorum. Onu kimin imzaladığını ve o imzaya neden güvenildiğini, sertifika zincirini kuran 12. bölümde açacağım.

SYN ve SYN-ACK ile ödediğin bir gidiş-dönüş vardı; kripto el sıkışması onun üstüne bir tane daha koyuyor. Yani ilk uygulama baytın yola çıkmadan önce iki gidiş-dönüş ödemiş oluyorsun. TLS 1.2 üstünde bu üç gidiş-dönüştü.

Beş takım, iki karar

Şifre takımına baktığında artık yalnızca iki şey göreceksin: kayıtları koruyan AEAD algoritması ve HKDF ile kullanılacak özet algoritması. Anahtar değişimi ile imza algoritması takımın dışına, ayrı uzantılara çıkarıldı. Adlandırma kalıbı bu yüzden sade: TLS_AEAD_HASH.

Takım adındaki sayı anahtar uzunluğunu veriyor: ilk satırda 128 bit, ikincisinde 256 bit. Seçenek sayısı, TLS 1.2 standardının kendi metninde tanımladığı 37 takımdan 5’e indi; sonradan eklenenlerle o sürümün kayıt defteri yüzlerce takımı buluyordu. Bu sadeleşmeyi kasıtlı bir güvenlik kararı olarak oku: az seçenek, az yanlış yapılandırma anlamına geliyor.

İkinci karar daha sert çıkıyor: RSA ile anahtar taşıma seçeneği tamamen kaldırıldı ve anahtar değişimi için Diffie-Hellman zorunlu hâle geldi. Bunun sonucuna ileri gizlilik (forward secrecy) deniyor. Sunucunun uzun ömürlü özel anahtarı sonradan ele geçse bile eski oturumlar açılamıyor, çünkü o oturumların anahtarı hiç telden geçmedi. Matematiğini az önce kurduğun Diffie-Hellman anahtar uzlaşması, protokolde burada işe koşuluyor.

Veri korumasında da şifreleme ile doğrulama tek algoritmada birleşti. Eskiden bunları arka arkaya iki ayrı adımda yapıyordun ve sıralamayı yanlış kurmak koca bir saldırı sınıfı üretiyordu; POODLE ve Lucky Thirteen o sınıfın en bilinen örnekleri.

Anahtarların kendisini kimse elle seçmiyor. Anahtar takvimini HKDF-Extract ve HKDF-Expand üstüne kurmuşlar. Türetme etiketleri tls13 önekiyle başlıyor. Her türetmeye o ana kadarki bütün el sıkışma mesajlarının özeti giriyor. Yani anahtar, konuşmanın kendisine bağlı kalıyor. Ortak sırrı da doğrudan kullanmıyorlar. Ondan yön başına ve evre başına ayrı anahtarlar çıkıyor. Simetrik şifrelemenin anahtarını işlere bölme kuralı vardı; HKDF takvimi o kuralı uyguluyor.

Kayıtlara bölmek, kapanışı ilan etmek

El sıkışma bitince iş kayıt katmanına kalıyor. Kayıt katmanı dört içerik türü tanıyor: handshake, application_data, alert ve yalnızca eski yazılımlarla uyum için duran change_cipher_spec. Böylece birden çok üst protokol aynı kayıt katmanını paylaşabiliyor.

Veri en fazla 16.384 baytlık parçalara bölünüyor ve her parça kendi bütünlük etiketini taşıyor. Bölmenin sebebi şu: alıcı bağlantının kapanmasını beklemeden her kaydı geldiği anda doğrulayıp kullanabiliyor.

Kapanış da protokolün içinde. Saldırgan sahte bir TCP kapatma parçası üretirse taraflardan biri veriyi olduğundan kısa sanır; buna kesme saldırısı deniyor. Çözüm kapanışa ayrı bir kayıt türü vermek; o tür de bütünlük hesabına giriyor. Her taraf yazma yönünü kapatmadan önce close_notify göndermek zorunda ve o uyarıdan sonra gelen veri yok sayılıyor. Taşımanın FIN’i tek başına yeterli kanıt sayılmıyor.

İkinci ziyaret daha ucuz. İlk el sıkışma bittikten sonra sunucu NewSessionTicket ile istemciye bir PSK kimliği veriyor; istemci sonraki el sıkışmada pre_shared_key uzantısıyla o kimliği sunuyor. Sunucu kabul ederse yeni bağlantı kriptografik olarak eskisine bağlanıyor ve tam el sıkışma yerine eski anahtardan başlanıyor. Sunucu PSK ile doğrulandığı için Certificate ve CertificateVerify mesajlarını hiç göndermiyor.

Eski sürümlerdeki oturum kimliği ve oturum bileti mekanizmalarının ikisi de kaldırıldı; yerlerini önceden paylaşılan anahtar aldı. Ama PSK tek başına kullanılırsa uygulama verisi için ileri gizlilik kayboluyor. Bu yüzden istemci PSK sunarken key_share da gönderiyor: hem tazelik gelsin, hem de sunucu sürdürmeyi reddedip tam el sıkışmaya düşebilsin diye.

Paylaşılan anahtar varsa istemci daha ileri gidebiliyor. İlk mesaj demetinde early_data uzantısıyla birlikte şifrelenmiş bir HTTP isteği gidiyor ve el sıkışma gecikmesi sıfıra iniyor. Bedeli de var. Erken veri yalnızca sunulan PSK’dan türeyen anahtarlarla korunuyor, yani ileri gizliliği yok. Kaydedilip sonradan aynen tekrar oynatılabiliyor da.

Bütün bunlar kendi makinende görünür hâle gelebiliyor. 10. bölümdeki openssl s_client komutunu grep olmadan çalıştır ve tam çıktıda üç satıra bak: Protocol, Cipher ve Negotiated TLS1.3 group (eski OpenSSL sürümlerinde sonuncusunun adı Server Temp Key). Sırasıyla pazarlıkla seçilen sürümü, şifre takımını ve anahtar uzlaşma grubunu gösteriyorlar.

Özet

• Kilit application layer’ında kuruluyor: TCP hiç değişmiyor, sokete düz yazılan metin ağa şifreli çıkıyor ve varsayılan port 443.
• El sıkışma tek gidiş-dönüşe bir tahminle sığıyor: istemci grubu önceden seçip anahtar payını ilk mesajda gönderiyor, tutmazsa HelloRetryRequest bir tur daha yazıyor.
• Şifre takımı artık yalnızca AEAD ile özet algoritmasını seçiyor: anahtar değişimi ile imza dışarı çıktı, seçenek 37’den 5’e indi ve Diffie-Hellman zorunlu oldu.
• Kayıt katmanı stream’i parçalara bölüyor: her kayıt kendi başına doğrulanıyor ve kapanış close_notify ile ilan ediliyor.

Kanal artık okunamıyor, kurcalanamıyor ve kapanışı bile sahtelenemiyor. Kilit kuruldu; ama kilidi karşı tarafla kurduğunu nereden biliyorsun?