TLS Nedir? SSL ile Farkı, Sürüm Pazarlığı ve Ölçümü

TLS, iki bilgisayarın birbirine tek kelime söylemeden önce nasıl konuşacaklarına karar verdikleri protokoldür. Şifreleme onun sonucudur, kendisi değil. Adı da bunu söylüyor: Transport Layer Security, yani taşıma katmanının güvenliği.

Burada sık atlanan bir ayrım var. Ağ protokolleri yazısı protokollerin var olma sebebini tek cümlede özetliyor: cihazlar her bağlantıda pazarlık etmesin diye. TLS bu kuralın istisnasıdır. Her bağlantıda, sıfırdan, yeniden pazarlık eder. Makalenin tamamı o pazarlığın içinde geçecek.

Ortak dili olmayan iki kişiyi düşünün. Masaya oturuyorlar. Özel bir şey konuşabilmeleri için önce, herkesin duyduğu yerde, yüksek sesle anlaşmaları gerekiyor: İngilizce mi, Almanca mı? Bu pazarlık gizli yapılamaz, çünkü gizli yapılabilmesi için zaten ortak bir dil gerekirdi. Ancak anlaştıktan sonra sesleri kimsenin anlamadığı bir şeye dönüşür. Makale boyunca bu masaya geri döneceğiz.

Önce adın karışıklığını çözeceğiz, sonra o pazarlıkta neyin kararlaştırıldığına ve seçimi kimin yaptığına bakacağız. Ardından paket dökümünü okumayı öğrenip bir tuzağa gireceğiz: sürüm alanı size doğruyu söylemiyor. Oradan asıl soruya geçeceğiz, sunucunuzun hangi sürümü konuştuğunu nasıl ölçersiniz, ve sürümün pazarlıkta neyi açığa çıkardığını kendi laboratuvar yakalamamızda göstereceğiz. Sonunda pazarlığın hiç sonuçlanmadığı duruma bakacağız, çünkü orada ekranda gördüğünüz şey sizi yanlış yere bakmaya iter.

TLS Nedir, Neden Her Bağlantıda Yeniden Pazarlık Yapar?

TLS, iki taraf arasındaki bağlantıyı şifreleyen, karşı tarafın kimliğini bir sertifikayla doğrulayan ve verinin yolda değiştirilmediğini denetleyen protokoldür. HTTPS’in içindeki “S” budur, ama yalnız web’e ait değildir: dizin sorguları, dosya transferi, log toplama ve kablosuz ağ kimlik doğrulaması hep aynı protokolü kullanır.

Pazarlığın neden her seferinde tekrarlandığı, TLS’in çözdüğü asıl problemden geliyor. Bir DHCP sunucusuyla istemci arasında tartışılacak bir şey yoktur: mesajın hangi alanları taşıyacağı standartta yazılıdır, iki taraf da onu uygular. TLS’te ise iki tarafın elindeki yetenekler farklıdır ve birbirini tanımazlar. 2016’dan kalma bir yazıcı ile bu ay kurulmuş bir sunucu aynı ağda konuşmak zorunda kalabilir. Hangi şifreleme yöntemlerini ortak bildikleri baştan bilinemez, çünkü ikisini de farklı firmalar, farklı yıllarda, birbirinden habersiz üretmiştir.

Masadaki iki kişi de karşısındakinin hangi dilleri bildiğini bilmiyor. Bilseler sormazlardı. Sormak zorunda oldukları için soru yüksek sesle soruluyor. Ve tam bu yüzden pazarlığın kendisi, dışarıdan izlenebilir bir şey oluyor.

Bu makale kurumsal network kurulumu hizmetimizin şifreli iletişim koluna odaklanır.

TLS Neyi Çözer, Neyi Çözmez?

TLS üç işi birden yapar: içeriği gizler, karşı tarafın kimliğini doğrular, verinin yolda değiştirilmediğini denetler. Bu üçünün kriptografik mekanizması, yani simetrik ile asimetrik şifrelemenin farkı ve hash fonksiyonlarının ne işe yaradığı şifreleme nedir yazısının konusudur.

TLS’in çözmediği şeyler sahada daha çok yanlış anlaşılır:

• Karşı tarafın iyi niyetli olduğunu söylemez. Yalnız iddia ettiği kişi olduğunu söyler. Bir saldırgan da kendi alan adı için geçerli bir sertifika alabilir.
• Bağlantının varlığını gizlemez. Kimin kiminle, ne zaman, ne kadar süre ve kaç bayt konuştuğu şifrelemenin dışında kalır.
• Uygulamanın kendi açıklarını kapatmaz. Şifreli bir kanaldan geçen zayıf bir parola, şifreli olduğu için güçlenmez.

SSL Nedir, TLS ile Farkı Ne?

SSL, TLS’in ölmüş atasıdır. Netscape’in 1990’ların ortasında geliştirdiği protokolün son sürümü SSL 3.0’dır ve 1996’da yayımlanmıştır. 1999’da protokol IETF’e devredilirken adı TLS olarak değiştirildi; ilk sürüm olan TLS 1.0, iç yapısı bakımından SSL 3.1’den başka bir şey değildi. Yani ikisi ayrı iki teknoloji değil, aynı soyağacının iki adıdır.

Protokol olarak SSL öldü. Ad ölmedi, ve bunun sebebi inatçılık değil: isimler altyapıya gömülüdür. Sertifikaları üreten araç hâlâ openssl adını taşır. FTP sunucusuna şifreli bağlanan istemcinin gönderdiği komut hâlâ AUTH SSL’dir ve sunucunun kendi logu hâlâ SSL session yazar. Sertifika satan şirketlerin ürün adı hâlâ “SSL sertifikası”dır, oysa sattıkları şey yıllardır TLS içindir.

Türkiye’de bunun tanıdık bir karşılığı var. SSK 2006’da Sosyal Güvenlik Kurumu’na devredildi, tabelalar değişti, kurum değişti. Yirmi yıl sonra hâlâ “SSK’lı oldum”, “SSK girişim yapıldı” deniyor. Kimse yanlış söylemiyor; herkes doğru kurumu kastediyor, sadece eski adıyla.

Pratik sonucu şu: birisi “SSL sertifikası” ya da “SSL bağlantısı” dediğinde düzeltmeye gerek yok, kastettiği şey TLS’tir. Düzeltilmesi gereken tek şey, bir sürüm olarak SSL 3.0’ın hâlâ açık bırakılmış olmasıdır, ve o bambaşka bir konudur.

TLS El Sıkışmasında Sürümü ve Şifre Takımını Kim Seçer?

El sıkışmada iki şey kararlaştırılır: hangi TLS sürümü kullanılacak ve hangi şifre takımı (cipher suite) ile şifrelenecek. Karar süreci tek yönlüdür ve çoğu anlatımda bu ayrım kayboluyor: istemci bir liste sunar, sunucu o listeden bir tanesini seçer. İstemci teklif eder, sunucu karar verir.

El sıkışmanın adım adım mesaj akışı ve anahtarın neden hiçbir zaman ağdan geçmediği HTTP ve HTTPS yazısında anlatıldı. Burada o akışı tekrarlamıyoruz. Bakacağımız şey listenin kendisi.

Masaya dönelim. Biri oturur oturmaz konuşabildiği bütün dilleri sayıyor. Karşısındaki listeye bakıp bir tane seçiyor: “o zaman Almanca.” Seçimi yapan taraf her zaman ikincisi. Ve listeyi duyan tek kişi o değil; masayı gören herkes duydu.

Şifre Takımı Listesi: İstemci Sunar, Sunucu Seçer

Laboratuvardaki domain controller’a (dc01, 192.168.1.10) LDAPS portundan bağlanıp, istemcinin sunduğu listeyi ve sunucunun seçtiğini paket dökümünden okudum. Aynı istemci, aynı sunucu, aynı sertifika; değiştirilen tek şey istenen TLS sürümü.

Tabloda iki sütuna bakın: kaç tane sunuldu ve hangisi seçildi.

Üç satır üç şey söylüyor:

1. Seçen taraf sunucudur. İstemci 28 seçenek sunduğunda bile bağlantıyı belirleyen tek bir değer var ve onu sunucu koyuyor. Yani “istemcim güçlü şifreleme destekliyor” cümlesi tek başına hiçbir şey ifade etmez.
2. Sürüm, menünün kendisini belirliyor. TLS 1.0 pazarlığında seçilen takım CBC modu ile SHA-1 hash’i kullanıyor. Şifreleme ile bütünlük denetimini tek işlemde yapan GCM, TLS 1.2 ile geliyor. Eski sürüm soyut bir risk değil: seçilebilecek şifreleme yöntemini değiştiriyor.
3. TLS 1.3 menüyü büyütmedi, 28’den 4’e indirdi. Kırık ya da şüpheli olan her şey listeden çıkarıldığı için geriye dört seçenek kaldı. “TLS 1.3 daha güvenli” cümlesinin sıfat değil sayı hâli budur.

Şifre takımı adının parçalarının ne anlama geldiği, yani anahtar değişimi, simetrik şifreleme ve bütünlük katmanının adın neresinde durduğu simetrik ve asimetrik şifreleme yazısında çözümlendi.

Neden TLS 1.3’ün Şifre Takımı Adı Daha Kısa?

İki adı yan yana koyun, fark hemen görünür:

ECDHE-RSA-AES256-GCM-SHA384      (TLS 1.2)
TLS_AES_256_GCM_SHA384           (TLS 1.3)

Kısalma bir sadeleştirme değil, pazarlıktan çıkarılan alanların izi. TLS 1.2 adında dört bilgi var: anahtar değişimi (ECDHE), sunucunun kimliğini kanıtlarken kullandığı imza (RSA), simetrik şifreleme (AES256-GCM) ve hash (SHA384). TLS 1.3’te ilk ikisi adın dışına çıktı, çünkü artık şifre takımıyla birlikte pazarlık edilmiyorlar; ayrı uzantılarda ele alınıyorlar. Geriye yalnız simetrik şifreleme ile hash kaldı.

Bu, üstteki “menü 4’e indi” bulgusunun sebebini de açıklıyor: seçenek sayısı azaldı çünkü tek bir addan seçilen şeylerin sayısı azaldı.

İki farklı adlandırma dolaşımda, ikisi de doğru. openssl çıktısında ECDHE-RSA-AES256-GCM-SHA384 yazan takım, Wireshark’ta standart adıyla TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 görünür. Aynı takımın iki yazımı; sayısal karşılığı ikisinde de 0xc030.

TLS Kayıt Katmanını Okumak: Paket Dökümünde Neye Bakılır?

Bundan sonraki her ölçüm paket dökümüne dayanıyor, o yüzden önce dökümün alfabesini koyalım. TLS’te ağdan geçen her şey kayıt (record) denen zarflara bölünür ve her zarfın başında ne taşıdığını söyleyen tek baytlık bir numara bulunur. Pratikte üç numara görürsünüz:

• 22 : Handshake. Pazarlık mesajları. Sürüm, şifre takımı ve sertifika bu zarfın içinde taşınır.
• 23 : Application Data. Asıl veri. Şifrelidir, dışarıdan çözülemez.
• 21 : Alert. Hata ve kapanış bildirimleri.

Bu üç numara paket dökümünü okunur kılan şey. Bir yakalamada Handshake (22) görüyorsanız o kaydın içi ayrıştırılabilir demektir; Application Data (23) görüyorsanız Wireshark size yalnızca kaç bayt olduğunu söyleyebilir. Makalenin taşıyıcı bulgusu birazdan tam olarak bu iki numaranın yer değiştirmesi üzerine kurulacak.

Pakette Üç Ayrı TLS Sürüm Numarası Var

Sürümü öğrenmenin en doğal yolu, Handshake zarfının içindeki sürüm alanına bakmak gibi görünür. Bakarsanız yanılırsınız: bir TLS 1.3 el sıkışmasında üç ayrı sürüm numarası dolaşır ve görünür alanların hiçbiri 1.3 demez.

Bu alanları üç ayrı bağlantıdan çektim: her biri tek bir sürüme sabitlenmiş, tabloda ayrı satır çiftleri olarak duruyor. Yani satırlar farklı bağlantıları, sütunlar ise aynı mesajın içindeki üç ayrı alanı gösteriyor: record.version en dış zarfın sürüm alanı, handshake.version pazarlık mesajının kendi alanı, supported_versions ise TLS 1.3 ile gelen bir uzantı.

tshark -r 636-tls1_3.pcap -d tcp.port==636,tls \
  -Y "tls.handshake.type==1 || tls.handshake.type==2" \
  -T fields -e tls.record.version -e tls.handshake.version \
  -e tls.handshake.extensions.supported_version

Değerlerin karşılığı: 0x0301 TLS 1.0, 0x0303 TLS 1.2, 0x0304 TLS 1.3.

Tablo bir yanılgıyı davet ediyor, önce onu ortadan kaldıralım: bu üç sayı bir sıra değil. El sıkışma TLS 1.0’dan başlayıp basamak basamak 1.3’e tırmanmıyor. TLS 1.3 satırındaki 0x0301, 0x0303 ve 0x0304, tek bir ClientHello mesajının aynı anda taşıdığı üç ayrı alandır; birbirini izleyen üç adım değil.

Sürüm de tıpkı şifre takımı gibi tek turda seçilir: istemci supported_versions uzantısında desteklediği sürümlerin listesini bir kerede gönderir, sunucu o listeden kendi de desteklediği en yükseğini seçip geri yazar. Kademe kademe yükselen bir pazarlık yoktur.

O zaman geriye tek soru kalıyor: madem gerçek cevap supported_versions’da, diğer iki alan neden hâlâ eski sürümleri gösteriyor? Son iki satırı tek tek okuyalım:

1. TLS 1.3 bağlantısının Client Hello mesajı, en dış zarfında TLS 1.0 yazıyor. Bu bir hata değil, kasıtlı bir donma. Aradaki eski güvenlik duvarları ve yük dengeleyiciler tanımadıkları sürüm numarasını gördüklerinde bağlantıyı kesiyordu; o alan yıllar önce eski bir değerde sabitlendi ve artık hiçbir şey anlatmıyor.
2. Pazarlık mesajının kendi sürüm alanı da TLS 1.2 diyor. Aynı sebeple. TLS 1.3 kendini yeni bir sürüm numarasıyla tanıtmayı denemedi bile.
3. Gerçek cevap yalnız supported_versions uzantısında. Sürüm pazarlığı 1.3’te eski alanlardan alınıp bir uzantıya taşındı. Sebebi yalnız uyumluluk değil: eski alan üzerinden yapılan pazarlık, araya giren birinin iki tarafı daha zayıf bir sürümde anlaşmaya zorlamasına açıktı. Uzantı, o pazarlığı el sıkışmanın bütünlük denetimine dahil eden yapının parçası.

Peki bu neden sizin sorununuz? Çünkü bu tuzağın izine sitede zaten rastladık. LDAP ve LDAPS yazısındaki yakalamada şu iki satır yan yana duruyor:

4  TLSv1    Client Hello
6  TLSv1.3  Server Hello

Aynı oturum, iki farklı sürüm gibi görünüyor. Görünüyor, değil: Wireshark Client Hello satırında kayıt katmanının sürüm alanını, Server Hello satırında ise pazarlıkta seçilen gerçek sürümü gösteriyor. O bağlantı baştan sona TLS 1.3’tü.

Sahada pratik karşılığı: bir denetim raporu ya da izleme aracı size “istemciler TLS 1.0 kullanıyor” diyorsa, aracın hangi alanı okuduğunu sorun. Kayıt katmanının sürüm alanını sayan bir araç, tamamen TLS 1.3 konuşan bir ağı TLS 1.0 gibi raporlar.

Sunucunuz Hangi TLS Sürümünü Konuşuyor?

Sürüm alanına güvenilemediğine göre geriye tek yol kalıyor: sunucuya sormak. Yolu her sürümü tek tek denemek ve hangisinin kabul edildiğine bakmaktır.

Sahada bu soruya verilen standart cevap şudur: modern bir Windows Server’da TLS 1.0 ve 1.1 zaten kapalıdır, çünkü Microsoft bunları yıllar önce kullanımdan kaldırdı. Laboratuvardaki domain controller test için uygun bir aday: Windows Server 2025, kurulumdan sonra Schannel protokol sürüm ayarlarına hiç dokunulmamış.

Ölçtüm.

Dört Sürümü Tek Tek Denemek

Ölçüm ntp01 (192.168.1.15) üzerinden dc01’in LDAPS portuna karşı yapıldı. Komut her sürüm için tekrarlandı, yalnız sürüm bayrağı değişti.

openssl s_client -connect 192.168.1.10:636 -tls1
openssl s_client -connect 192.168.1.10:636 -tls1_1
openssl s_client -connect 192.168.1.10:636 -tls1_2
openssl s_client -connect 192.168.1.10:636 -tls1_3

Çıktıyı okurken bir tuzak var, ve makalenin şimdiye kadarki konusuyla tam olarak aynı tuzak. openssl çıktısının en görünür satırı New, ile başlar ve orada bir sürüm yazar. O satır pazarlanan sürümü bildirmez; seçilen şifre takımının ilk tanımlandığı asgari sürümü yazar. Kendi ölçümümüzde ikisi ayrışıyor:

636-tls1    New, TLSv1.0, Cipher is ECDHE-RSA-AES256-SHA
                Protocol  : TLSv1
636-tls1_1  New, TLSv1.0, Cipher is ECDHE-RSA-AES256-SHA
                Protocol  : TLSv1.1

İki bağlantı da New, TLSv1.0 yazıyor, ama ikincisi TLS 1.1’dir. Bakılacak yer oturum bloğundaki üç satır birlikte: hangi sürüm pazarlandı, hangi şifre takımı seçildi, ve ortak anahtar üretildi mi?

    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA
    Master-Key: 3D649425E82306A61A66106293CFA0E68C850B27...

Master-Key alanının dolu olması, el sıkışmanın sonuna kadar gittiğini söyleyen kısımdır. Tek başına Protocol satırına bakmak yetmez; birazdan hiç el sıkışma yapılmamış bir bağlantıda da o satırın dolu geldiğini göreceğiz.

Dört denemenin sonucu:

Dördü de kuruldu, ve el sıkışma gerçekten tamamlandı: yakalamada sunucudan Change Cipher Spec ve şifreli Finished mesajları, ardından uygulama verisi var. Bağlantı Server Hello’da kalmadı.

2026’nın en yeni sunucu işletim sistemi, 1999’dan kalma TLS 1.0’ı reddetmiyor.

Cümlenin şeklini bozmamak önemli, çünkü kolayca yanlış kuruluyor: sunucu TLS 1.0 kullanmıyor. Her seferinde teklif edilenin en yükseğini seçti; TLS 1.3 isteyene TLS 1.3 verdi. Kapıyı açık bırakan şey sunucunun tercihi değil, istemcinin ısrarı. Modern bir istemci buradan TLS 1.3 alır, on yıl önceki bir cihaz da kapıyı açık bulur.

İstemci tarafında bir ayar yapmak zorunda kaldım ve bunu saklamak yanlış olur. Ubuntu üzerindeki OpenSSL 3.0, kendi sistem yapılandırması gereği TLS 1.2 altını reddediyor; ilk denemede komut sunucuya hiç ulaşmadan düştü. Asgari sürüm ve güvenlik seviyesi geçici bir yapılandırma dosyasıyla gevşetildi. Bu sonucu bozmaz: istemci ayarı yalnızca neyin teklif edildiğini belirler, hangi sürümün seçileceğine sunucu karar verir. Ayrıntının kendisi de bir bulgu: günümüzün varsayılan Linux istemcisi bu bağlantıyı kurmayı reddediyor. Sorun modern istemcilerde değil.

Sunucu Bunu Bilerek mi Yaptı? RFC’nin Kendi İşareti

Buraya kadar bir soru cevapsız: sunucu eski sürümü seçti mi, yoksa yeni sürümü zaten yapamadığı için mi oraya düştü? Bu ikisi çok farklı şeyler, ve cevabı aynı yakalamanın içinde duruyor.

Server Hello mesajının içinde sunucunun ürettiği 32 baytlık rastgele bir değer taşınır. TLS 1.3 standardı, o değerin son sekiz baytına bir kural koydu: TLS 1.3 yapabilen bir sunucu daha eski bir sürüm seçmek zorunda kaldığında oraya bir işaret bırakmalı. Dört yakalamada o sekiz bayta baktım:

tshark -r 636-tls1.pcap -d tcp.port==636,tls \
  -Y "tls.handshake.type==2" -T fields -e tls.handshake.random

Standardın kuralı şu: TLS 1.2 seçilirse son bayt 01, TLS 1.1 ve altı seçilirse 00 olur. Ölçüm bu kuralla birebir uyuşuyor. Üç şey birden kanıtlanmış oluyor:

1. Cevap veren yığın TLS 1.3 yapabiliyor. Yapamayan bir sunucu bu işareti hiç koymaz.
2. Eski sürümü bilerek seçti. Yani bu bir uyumluluk kazası ya da eski bir yazılım yığını değil.
3. Seçilen sürüm, sürüm alanından tamamen bağımsız ikinci bir yerde de doğrulanıyor. Baştaki tabloya güvenmemek için sebebimiz vardı; artık iki ayrı alan aynı şeyi söylüyor.

İşaretin varlığı ayrıca bu makalenin en başındaki iddiayı kapatıyor: sunucu pazarlığın sonucunu, kendisini dinleyen herkesin okuyabileceği bir yere yazıyor.

Boş Registry Anahtarı “Kapalı” Demek Değil

Sunucu tarafında ne yapılandırıldığına baktım. Uzaktan bir CIM oturumuyla dc01’in Schannel protokol anahtarını okudum:

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

Anahtarın hiç alt anahtarı yok. Ve sezginin tersine döndüğü nokta burası: bir sürümün kullanılabilmesi için registry’de açıkça açılmış olması gerekmiyor. Microsoft’un kendi belgesi bunu tersinden söylüyor: bir sürümü açmak ya da kapatmak için değer oluşturulur, değişikliği geri almak için o değer silinir. Yani anahtarın boş olması “hiçbir sürüm tanımlı değil” demek değil, “hiçbir ezme yok, işletim sisteminin varsayılanı geçerli” demektir.

Yapı da tek katmanlı değil. Her sürümün altında Client ve Server diye iki ayrı alt anahtar bulunur ve bunlar bağımsızdır: bir makine TLS 1.0’ı istemci olarak kapatmış ama sunucu olarak açık bırakmış olabilir. Sıkılaştırmada en sık atlanan ayrım bu. Değişiklik sunucu genelindedir ve etkili olması için yeniden başlatma ister.

Peki varsayılan ne? Microsoft’un Schannel protokol destek tablosu Windows Server 2025 satırında TLS 1.0 ve TLS 1.1’i, hem istemci hem sunucu rolünde, Enabled olarak listeliyor. Ölçüm bu tabloyla birebir uyuşuyor.

Ölçümün sınırı, açıkça. Burada gösterilen şey şu: registry’de hiçbir ezme yoktu ve sunucu eski sürümü reddetmedi. Boş anahtarın bu davranışın sebebi olduğu ise ölçülmedi, çıkarsandı; bunu kanıtlamak için sürümü kapatıp davranışın değiştiğini göstermek gerekirdi. Ayrıca ölçülen tek şey LDAPS dinleyicisinin TLS katmanıdır. Aynı makinedeki uzak masaüstü, veritabanı ve uzaktan yönetim servisleri Schannel’ı kullanır, ama bir servis sistem varsayılanını kendi içinde daraltabilir; genişletemez. Yani her kapı ayrı cevap verebilir ve her kapı ayrı ölçülmelidir.

Ve bir çelişki var, doğrudan üreticinin kendi belgelerinde. Windows Server’ın kaldırılan özellikler sayfası bu sürümlerin Server 2025’te varsayılan kapalı olduğunu yazıyor; Schannel tablosu ise açık gösteriyor. Kullanımdan kaldırma duyurusu bu ikisinin arasını buluyor: değişikliğin Insider Preview sürümleri için geldiğini ve piyasadaki sürümleri etkilemeyeceğini söylüyor. Ölçüm Schannel tablosuyla uyuşuyor.

Çıkarılacak sonuç, hangi sayfanın haklı olduğu değil: dokümantasyona bakıp varsaymayın, kendi sunucunuzda ölçün. Ölçüm dört komut sürüyor.

Bu ölçüm neye çapalı. dc01, Windows Server 2025 Datacenter Evaluation, Build 26100.32690, ölçüm tarihi 20 Ağustos 2026. Tek makine, tek kurulum. Bir sonraki güncelleme paketi varsayılanı çevirebilir, ve bu satır o zaman kendiliğinden eskir. Bu yüzden burada okuduğunuz şey sizin sunucunuz hakkında bir iddia değil, uygulamanız gereken bir yöntem.

Ölçümü tekrarlayacaksanız bir ön koşul var: TLS 1.3’ü Schannel yalnız Windows Server 2022 ve sonrasında konuşur. Daha eski bir sunucuda dördüncü komut bağlanmaz, ve bunun sebebi sıkılaştırma değil, o sürümün hiç desteklenmiyor olmasıdır.

IIS’teki Kutu Sunucunun Tamamını Kapsamıyor

Bu ölçümün pratikte en pahalı sonucu burada. IIS yazısında sitenin binding penceresindeki Disable Legacy TLS kutusundan söz edilmişti. O kutu işini yapıyor, ama işi yalnız o binding kadar: web sunucusunun istek katmanına uygulanır, Schannel’ın sunucu genelindeki ayarına dokunmaz.

Yukarıdaki ölçümde IIS hiç yok. Ölçülen şey bir domain controller’ın dizin servisi, ve orada eski sürüm hâlâ kabul ediliyordu.

Yani bir sitede kutuyu işaretleyen yönetici, sunucunun eski TLS’i kapattığını sanabilir. Kapanan şey bir kapıdır. Diğerlerinin ne cevap verdiği ölçülene kadar bilinmiyor, ve kontrol edilecek yer tek bir ekran değil, servis servis her kapıdır.

Aynı Sertifika, İki Sürüm: Pazarlıkta Ne Görünür?

Sürümün ikinci etkisi güvenlikte değil görünürlüktedir, ve bu bölüm makalenin taşıyıcı ölçümü. İddia sitede daha önce sözle kurulmuştu: el sıkışmanın dört işini anlatan bölüm TLS 1.3’ün “el sıkışmanın daha büyük bir kısmını şifrelediğini” söylüyor. Şimdi o cümlenin paket dökümündeki karşılığını koyuyoruz.

Deney tek değişkenli: aynı sunucu, aynı sertifika, aynı port. Değişen tek şey sürüm. İki yakalama alındı ve dosyaların ham baytları içinde iki dize arandı: sunucunun adı ve sertifikayı veren kurumun adı.

grep -a -o "dc01.ad.sercebilisim.com" 636-tls1_2.pcap | wc -l
grep -a -o "SerceBilisim-Lab-Root-CA" 636-tls1_2.pcap | wc -l

Sayılar bir yerden geliyor, ve o yer paketin yapısı. Aynı iki yakalamada dc01’in gönderdiği ilk kayda baktım. Kayıt katmanının alfabesini yukarıda koymuştum; şimdi işe yarıyor:

TLS 1.2
  Content Type: Handshake (22)
    Server Hello
    Certificate
      Certificate Length: 1676
        issuer:  id-at-commonName=SerceBilisim-Lab-Root-CA
        subject: id-at-commonName=dc01.ad.sercebilisim.com
    Server Key Exchange
    Certificate Request
    Server Hello Done

TLS 1.3
  Opaque Type: Application Data (23)
    Length: 2065
    Encrypted Application Data: e62a48910b2f4a01d0a78d0a56dd734d...

Dökümü satır satır okuyalım:

1. TLS 1.2’de sertifika, 22 numaralı düz metin bir el sıkışma kaydının içinde yolculuk ediyor. Wireshark onu alanlarına kadar ayrıştırabiliyor: sunucunun adı, sertifikayı veren kurum, uzunluğu. Ağı dinleyen birinin bunları okumak için hiçbir şey kırması gerekmiyor.
2. TLS 1.3’te aynı sertifika 23 numaralı bir kaydın içinde, yani şifreli veri zarfında. Wireshark’ın o bloğa verdiği ad Opaque Type: içini göremediği bir şey. Uzunluğunu söylüyor, 2065 bayt, başka bir şey söyleyemiyor.
3. Sertifikayı veren kurumun adı, gönderilen belgenin kendi içinden okunuyor. Bu bağlantıda sunucu tek bir sertifika sunuyor ve kök otorite onu doğrudan imzalamış. Ara halkalı bir kurumsal yapıda zincirin nasıl uzadığı sertifika otoritesi yazısının konusu.
4. Yan bulgu: TLS 1.2 dökümünde Certificate Request mesajı da görünüyor. Bu sunucu, dizin servisine bağlanan istemciden de sertifika isteyebileceğini bildiriyor. TLS 1.3’te bu istek şifreli tarafta kaldığı için, sunucunun böyle bir talebi olduğu bile dışarıdan anlaşılmıyor.

Masaya dönelim. İki kişi de ortak dile geçmeden önce kartvizitlerini uzatıyor. TLS 1.2’de kartvizitler dile geçmeden önce masaya konuyor, yani salonu gören herkes iki ismi de okuyor. TLS 1.3’te önce dile geçiliyor, kartvizitler ondan sonra uzatılıyor. İzleyen kişi iki insanın konuştuğunu biliyor, kim olduklarını bilmiyor.

Analojinin koptuğu yer de burası: gerçek hayatta kartviziti gizlemek bir sır saklamaktır. Sertifikada değil.

Bu ölçüm ne demek DEĞİL. TLS 1.2 bir sır sızdırmıyor. Sertifika tanımı gereği kamuya açık bir belgedir; o sunucuya bağlanan herkes zaten onu alır ve içinde gizli hiçbir şey yoktur. Ölçülen şey sırrın korunması değil, bağlantının kimliğinin ne kadar ucuza okunabildiğidir. Fark, bir saldırganın ağı tarayıp “burada hangi sunucular var, hangi kurum imzalamış?” sorusunu tek bir yakalamayla cevaplayabilmesinde ortaya çıkar.

TLS 1.3’te Düz Metin Kalmaya Devam Edenler

Sertifikanın şifreli tarafa geçmesi bağlantıyı görünmez yapmıyor. Aynı yakalamalarda dışarıdan okunmaya devam eden üç şey var:

• Bağlanılmak istenen alan adı. İlk mesajda açık gidiyor. Bu alanın adı SNI’dır ve neyi sızdırdığı şifreleme neyi gizler, neyi gizlemez yazısında ele alındı.
• Oturum kimliği. Aynı sunucuya arka arkaya bağlandığımızda ilk bağlantı yeni bir oturum kurdu, sonrakiler aynı oturumu devraldı ve oturum kimliği dördünde de birebir aynıydı. Yani şifreli bir bağlantı, dışarıdan izleyen biri için tekrar tanınabilir bir işaret taşıyabiliyor.
• Bağlantının zamanı, süresi ve bayt miktarı. İçerik hiç okunmadan da desen üretir.

New,    TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
   Session-ID: 421A00001C0521F1B1D83925FBB9FB13...
Reused, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
   Session-ID: 421A00001C0521F1B1D83925FBB9FB13...

New ve Reused ayrımı, oturum devamının (session resumption) çalıştığını gösteriyor: ikinci bağlantı el sıkışmayı baştan yapmıyor, ilkinden kalan oturumu sürdürüyor. Kazanç hızda, maliyet ise yukarıdaki satırda görünen tekrar eden kimlikte.

Aynı yakalamada görünmeyen bir şey de var. İstemci, sertifikanın iptal edilip edilmediğine dair bilgiyi sunucudan istedi; sunucu yanıt vermedi:

OCSP response: no response sent

Sunucunun sertifika geçerliliğini el sıkışmaya iliştirmesine OCSP stapling denir ve bu sunucuda açık değil. Sonucu şu: iptal denetimi yapmak isteyen bir istemcinin bunu kendi başına, ayrı bir bağlantıyla yapması gerekir.

TLS Pazarlığı Kırıldığında Ne Görürsünüz?

Pazarlık sonuçlanmadığında gördüğünüz hata mesajı sizi yanlış yere bakmaya iter, çünkü kriptografik bir anlaşmazlık ağ diliyle raporlanır.

Bunu ölçmek için kesişimi baştan boş olan bir pazarlık kurdum. dc01’in sertifikası RSA’dır; istemciye yalnızca ECDSA gerektiren tek bir şifre takımı pazarlattım. İki tarafın ortak noktası yok:

openssl s_client -connect 192.168.1.10:636 -tls1_2 \
  -cipher 'ECDHE-ECDSA-AES256-GCM-SHA384'

write:errno=104
CONNECTED(00000003)
no peer certificate available
SSL handshake has read 0 bytes and written 142 bytes
New, (NONE), Cipher is (NONE)
    Protocol  : TLSv1.2
    Cipher    : 0000
    Master-Key:

errno=104 bağlantının karşı taraf tarafından sıfırlandığı anlamına gelir. read 0 bytes ise daha fazlasını söylüyor: sunucu tek bayt bile göndermedi. Kayıt katmanının alfabesindeki 21 numaralı Alert zarfı, yani protokolün kendi hata bildirimi, hiç kullanılmadı.

Bu çıktı aynı zamanda az önce verdiğimiz sözü tutuyor. Hiçbir el sıkışma yapılmadığı hâlde Protocol satırı TLSv1.2 yazıyor: o satır kurulan oturumu değil, denenen sürümü basıyor. Yanındaki iki satır ise gerçeği söylüyor, Cipher sıfır ve Master-Key boş. Bir bağlantının kurulup kurulmadığını Protocol satırından okuyamazsınız.

Asıl öğretici olan, bu bağlantıyı başarılı olanla yan yana koymak. İlk dört paketleri birebir aynı:

Tablodan çıkan üç sonuç teşhiste zaman kazandırır:

1. İki bağlantı da TCP düzeyinde başarılıdır. Üçlü el sıkışma tamamlanmış, port cevap vermiştir. Bir port testi ikisinde de “açık” der. Port testi bu arızayı göremez.
2. Ayrışma altıncı pakettedir ve orada gelen şey bir açıklama değil, kapı kapatmasıdır.
3. Reset, hangi anlaşmazlığın yaşandığını söylemez. Aynı laboratuvarda, aynı sunucuda, sertifika hiç yokken de aynı imza kaydedilmişti: port açık, TCP başarılı, el sıkışma resetleniyor. Farklı sebep, aynı belirti.

Teşhis bu yüzden reset’e bakarak yapılamaz. Bakılacak yer Client Hello mesajının içeriğidir: istemci hangi sürümleri ve hangi şifre takımlarını sundu, ve sunucunun kabul ettikleriyle kesişimi var mı? Portun açık olması, iki tarafın anlaşabildiği anlamına gelmiyor.

TLS Bağlantıya Nereden Giriyor?

TLS’i HTTPS’in bir parçası sanmak yaygın bir kısaltmadır ve yanıltıcıdır: TLS bir taşıyıcıdır, üstünde ne çalıştığını umursamaz. Ama bağlantıya iki farklı şekilde giriyor ve bu ayrım, sahada karşılaşacağınız yapılandırma seçeneklerini belirliyor.

Bağlantı bir kez kurulduktan sonra ikisinin kriptografik sonucu aynı. Bunu aynı makinede ölçtüm: dc01 iki ayrı kapıda TLS konuşuyor, biri baştan sarmalı diğeri sonradan yükseltmeli, ve ikisinde de sertifika CN = dc01.ad.sercebilisim.com, sürüm TLSv1.3, şifre takımı TLS_AES_256_GCM_SHA384 çıktı. Değişen tek şey el sıkışmanın ne zaman başladığı.

Sonradan yükseltmenin adı protokolden protokole değişir, ve bu tek başına aynı mekanizmayı tanımayı zorlaştırıyor. Posta protokollerinde komutun adı STARTTLS, dizin tarafında StartTLS, dosya aktarımında AUTH TLS. Üçü de aynı işi yapar: düz başlamış bir bağlantıyı, ayrı bir port açmadan, aynı oturumun içinde şifreliye çevirir. Bir yapılandırma ekranında bu adlardan birini gördüğünüzde tablodaki ikinci satırdasınız demektir; ve o satırın pratik bedeli şudur: komut verilene kadar geçen her şey ağda açıktadır.

StartTLS Neden İcat Edildi, Nerede Zayıf Kalıyor?

StartTLS, her protokole şifreli sürümü için ikinci bir port numarası ayırma zorunluluğundan kurtulmak için icat edildi. Sorunu görmek için 1990’ların sonuna bakmak yeterli: bir protokolü şifrelemenin tek yolu ona ikiz bir kapı açmaktı.

Her yeni protokol iki numara tüketiyordu, üstelik güvenlik duvarında iki kural, belgelerde iki satır, kullanıcı ekranında iki seçenek demekti. Standart yazarları bunu sürdürülebilir bulmadı: 1999 tarihli RFC 2595, posta protokolleri için ayrı port tahsisini açıkça tavsiye etmedi ve çözüm olarak aynı porta bir yükseltme komutu koydu. StartTLS’in doğduğu yer burasıdır.

Mekanizması tek bir zincir ve zincirin tamamı aynı TCP bağlantısının içinde geçer:

1. İstemci düz bir TCP bağlantısı açar, şifreleme yoktur.
2. İstemci sunucuya yeteneklerini sorar (SMTP’de EHLO, IMAP’ta CAPABILITY).
3. Sunucu desteklediklerini listeler ve o listede yükseltme komutunun adı geçer.
4. İstemci komutu yollar, sunucu “başla” der.
5. Aynı soketin üstünde TLS el sıkışması başlar; yeni bağlantı açılmaz, yeni port kullanılmaz.
6. O andan sonra aynı bağlantı şifrelidir ve protokol kaldığı yerden devam eder.

Kritik ayrıntı 3. adımda saklı, ve StartTLS’in tek gerçek zayıflığı da orada: şifrelemenin mümkün olduğu bilgisi, henüz şifresiz olan bir kanaldan geliyor. Araya girebilen biri, sunucunun yetenek listesinden o tek satırı silerse, istemci sunucunun şifreleme desteklemediğini sanır ve düz devam eder. Kullanıcı hiçbir uyarı görmez. Bu saldırıya düşürme (downgrade) denir ve 443, 993, 465 gibi baştan şifreli kapılarda mümkün değildir, çünkü orada pazarlık edilecek bir şey yoktur: bağlantı ya şifreli kurulur ya hiç kurulmaz.

İki pratik sonuç çıkar. Birincisi, istemci ayarındaki “şifrelemeyi zorunlu tut” seçeneği kozmetik değildir: düşürmeyi fark edilir kılan tek şey odur, çünkü “isteğe bağlı” ayarda istemci sessizce düz metne düşer. İkincisi, sektör bu riski gördükten sonra kısmen geri adım attı: 2018 tarihli RFC 8314 posta tarafı için baştan şifreli portları yeniden önerdi. 465 numaralı portun bugün hâlâ hayatta olmasının sebebi nostalji değil, bu geri dönüştür.

Özetle üçü birden: StartTLS port israfını çözer, aynı bağlantıyı yerinde yükseltir, ve bunu yaparken pazarlığın ilk anını korumasız bırakır.

Bu iki yaklaşımın dizin tarafındaki karşılığı, hangisinin ne zaman tercih edildiği ve port ayrımı dizin protokolünün şifreli kipleri yazısının konusu; dosya transferi tarafındaki karşılığı ise FTP, FTPS ve SFTP yazısında.

Aynı desen posta tarafında da işliyor ve en yaygın hâline orada ulaşıyor: giden posta 587 numaralı portta düz başlayıp STARTTLS ile şifreliye çevriliyor, ve şifreleme devreye girmeden önce o bağlantıda nelerin okunabildiğini SMTP nedir yazısında oturum dökümüyle gösteriyoruz. Gelen posta tarafındaki 143 ile 993 ayrımı ve şifresiz kapının parolayı neden baştan reddettiği ise IMAP ile POP3 farkı yazısının konusu.

Aynı desen kablosuz ağ kimlik doğrulamasında da işliyor: orada el sıkışmanın sonucu bir bağlantı noktasının açılıp açılmayacağına karar veriyor, ayrıntısı RADIUS yazısında.

Listedeki her kalem aynı soruyu doğuruyor ve cevabını büyük ihtimalle bilmiyorsunuz: bu kapıların her biri hangi TLS sürümünü konuşuyor? Bir önceki bölümdeki dört komut hepsi için aynı şekilde çalışır; değişen tek şey port numarasıdır.

ALPN: Pazarlığın İsteğe Bağlı Alanı

El sıkışmada bir şey daha pazarlanabiliyor: TLS kurulduktan sonra üstünde hangi protokolün konuşulacağı. Adı ALPN, ve zorunlu değil. Aynı sunucuya ALPN teklif ederek bağlandım:

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
No ALPN negotiated

Sunucu karşılık vermedi, çünkü ihtiyaç yok: dizin servisinin dinlediği kapıya bağlanan istemcinin ne konuşacağı zaten belli. ALPN’in gerçekten iş gördüğü yer web tarafı, tarayıcı ile sunucunun HTTP’nin hangi sürümünü kullanacağına karar verdiği an. Aynı el sıkışma, aynı alan, farklı ihtiyaç.

Sonuç: Pazarlık Görünür, Karar Sizin

TLS’i “şifreleme” diye özetlemek, işin sonucunu alıp mekanizmasını atlamaktır. Mekanizma pazarlıktır: her bağlantıda, sıfırdan, iki tarafın ortak noktasını bulma denemesi. Ve o pazarlık üç şeyi birden belirliyor: bağlantının hangi yöntemle korunduğunu, dışarıdan bakan birinin ne okuyabildiğini, ve iş kırıldığında elinize hangi hata mesajının geçeceğini.

Bu makaledeki ölçümlerin ortak sonucu tek cümlede toplanıyor: sunucunuzun ne konuştuğunu varsaymayın. Kayıt katmanının sürüm alanı size yanlış cevap verir. Dokümantasyon kendi içinde çelişebilir. Bir yönetim ekranındaki kutu yalnız kendi kapısını kapatır. Doğru cevabı veren tek şey, sunucuya doğrudan sorulan birkaç komuttur.

Bunu bugün başlatmanın yolu bir envanterdir: TLS konuşan her kapı, hangi sürümleri kabul ettiği, ve o kapıya hâlâ hangi eski istemcinin bağlandığı. Sıralama önemli, çünkü ikinci sütunu bilmeden üçüncüsüne bakmak, çalışan bir şeyi kapatmakla sonuçlanır. Sertifikaların bu tabloda nereden geldiğini merak ediyorsanız iç sertifika otoritesi yazısı zincirin nasıl kurulduğunu anlatıyor; şifreleme yöntemlerinin kendi mekanizması ise şifreleme yöntemlerinin mekanizması yazısında.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn