TLS trafiğinde ne görülür ne görülmez

Kurum trafiğinin büyük kısmı bugün TLS ile şifreli akar. Saldırgan da aynı yolu kullanır. fin-pc12'deki svcupd.exe, 203.0.113.19 adresiyle HTTPS üzerinden konuşuyor. İçeriği okuyamazsın, ama bu kanal hakkında çok şey söyleyebilirsin.

TLS yükü gizler, zarfı gizlemez. Bu derste önce el sıkışmada neyin açık gittiğini ve TLS 1.2 ile 1.3 arasındaki farkı göreceksin. Sonra sertifikadan ve SNI alanından iz sürecek, istemci yazılımını JA3 ve JA4 parmak iziyle tanıyacaksın. En sonda şifreli kanalı davranışından yakalamayı ve kendi trafiğini hangi koşulda çözebileceğini öğreneceksin.

TLS bağlantısı kurulurken taraflar önce anlaşır, sonra kanalı kilitler. Anlaşma bitmeden ortak anahtar yoktur, bu yüzden ilk mesajlar açık gider. İstemci ClientHello ile başlar. İçinde desteklediği TLS sürümleri, şifre takımları ve uzantılar durur.

SNI uzantısı (RFC 6066) gidilmek istenen alan adını açık yazar. Aynı IP adresinde birçok site barınabildiği için sunucu doğru sertifikayı bu alandan seçer. ALPN uzantısı (RFC 7301) ise kanalın üstünde hangi uygulama protokolünün konuşulacağını söyler, örneğin HTTP/2 için h2. Sunucu ServerHello ile seçtiği sürümü ve şifre takımını bildirir.

Sertifikanın durumu sürüme göre değişir. TLS 1.2'de sunucu sertifikası açık gider ve kayıttan olduğu gibi okunur. TLS 1.3'te sunucu ServerHello'dan hemen sonra el sıkışma anahtarlarını kurar.

Sertifika bu anahtarlarla şifrelenmiş olarak gelir. Bir ayrıntı daha var. TLS 1.3 sunucusu ServerHello'nun sürüm alanına geriye uyum için hâlâ 1.2 yazar.

Asıl sürüm supported_versions uzantısındadır. Wireshark bunu çözer ve TLSv1.3 gösterir, ama yalnız ham sürüm alanına bakan bir betik yanılır. Aşağıdaki tablo iki sürümde neyin açık kaldığını özetler.

Alan                          TLS 1.2      TLS 1.3
SNI ve ALPN (ClientHello)     açık         açık, ECH varsa şifreli
Şifre takımları listesi       açık         açık
Sunucu sertifikası            açık         şifreli
IP adresi, port, boyut, zaman açık         açık
URL yolu, başlıklar, gövde    şifreli      şifreli

Bir de QUIC var. HTTP/3 trafiği TCP yerine UDP 443 üstünden QUIC ile akar. QUIC el sıkışmayı TLS 1.3 ile yapar ve ilk paketleri de şifreler. Ama bu şifreleme gizlilik sağlamaz.

İlk paketin anahtarı, bağlantı kimliğinden ve RFC 9001'de yazılı sabit bir değerden türetilir. Bu yüzden Wireshark bu paketi kendiliğinden çözer ve ClientHello içindeki SNI'yi gösterir. Güvenlik duvarı UDP 443'ü kapatırsa tarayıcılar TCP üstündeki TLS'ye döner. Bazı kurumlar görünürlüğü artırmak için bu yolu seçer.

Sertifika el sıkışmanın en konuşkan parçasıdır. Zeek bu bilgiyi iki günlüğe yazar. ssl.log her TLS oturumunun sürümünü, şifre takımını, SNI değerini ve doğrulama sonucunu tutar.

Doğrulama sonucu validation_status alanındadır ve validate-certs betiği yüklenince dolar. x509.log ise sertifikanın konu adını, veren kuruluşu ve geçerlilik tarihlerini tutar. Aşağıda 203.0.113.19 ile kurulan oturumu iki günlükte okuyorsun. zeek-cut -u zaman alanlarını okunur UTC biçimine çevirir.

$ zeek -C -r web01.pcap protocols/ssl/validate-certs
$ zeek-cut -u ts id.orig_h id.resp_h version cipher server_name validation_status \
    < ssl.log | grep 203.0.113.19 | head -1
2026-09-14T00:09:02+0000	10.20.30.61	203.0.113.19	TLSv12	TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384	cdn-update-srv.example	self-signed certificate

$ zeek-cut -u certificate.subject certificate.issuer \
    certificate.not_valid_before certificate.not_valid_after < x509.log | head -1
CN=cdn-update-srv.example,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU	CN=cdn-update-srv.example,O=Internet Widgits Pty Ltd,ST=Some-State,C=AU	2026-09-11T22:14:05+0000	2026-09-18T22:14:05+0000

Çıktıyı satır satır oku. ssl.log satırı oturumun TLS 1.2 ile kurulduğunu ve SNI değerinin cdn-update-srv.example olduğunu söyler. validation_status sertifikanın kendi imzalı olduğunu, yani hiçbir otoriteye bağlanmadığını gösterir.

x509.log satırında konu adı ile veren kuruluş aynıdır. Internet Widgits Pty Ltd ve Some-State, OpenSSL'in sertifika üretirken önerdiği varsayılan değerlerdir. Kurumsal bir sunucuda bu değerleri kimse bırakmaz.

Geçerlilik yedi gün sürüyor ve bağlantıdan üç gün önce başlıyor. Kısa ömür tek başına kanıt değildir, bazı otoriteler artık altı günlük sertifika da veriyor. Ama kendi imzayla birleşince aceleyle kurulmuş bir altyapıya işaret eder.

Alan adını bağımsız bir kaynaktan da sınarsın. Sertifika şeffaflığı (CT) günlükleri, kamuya güvenilen otoritelerin verdiği sertifikaları kalıcı ve herkese açık tutar. crt.sh gibi bir arama arayüzünde alan adını sorgular, ilk sertifikanın tarihine bakarsın.

Kendi imzalı sertifika bu günlüklerde çıkmaz. Ama saldırgan aynı alan adı için başka bir zaman bir otoriteden sertifika aldıysa kayıt orada durur. İlk kaydın tarihi altyapının ne zaman kurulduğunu gösterir. Bu bilgi göstergenin güven düzeyini artırır.

SNI'nin açık gitmesi uzun süre mahremiyet açığı sayıldı. Mart 2026'da yayımlanan RFC 9849, Encrypted Client Hello (ECH) yöntemini standart hâline getirdi. ECH'de istemci iki ClientHello kurar.

Asıl hedefin adını taşıyan iç mesaj şifrelenir ve dış mesajın içine gömülür. Dış mesajın SNI alanında ise ön cephedeki sunucunun ortak adı, yani public_name yazar. Kayıtta gördüğün ad artık gerçek hedef olmayabilir.

Bir ayrıntıya daha dikkat et. ECH desteklemeyen sunucuya giden tarayıcı da sahte bir ECH uzantısı gönderir. Buna GREASE ECH denir. Wireshark'ta tls.ech alanlarını görmek, gerçek ECH kullanıldığını tek başına kanıtlamaz.

ClientHello'daki alanlar istemci yazılımına göre değişir. Bir tarayıcı, bir Python kitaplığı ve bir zararlı yazılım farklı şifre takımları ve uzantılar sunar. JA3 bu farkı parmak izine çevirir.

TLS sürümünü, şifre takımlarını, uzantıları, eliptik eğrileri ve nokta biçimlerini sırayla birleştirir, sonucun MD5 özetini alır. GREASE denen rastgele dolgu değerlerini yok sayar. Ama uzantıların sırasına duyarlıdır.

2023'ten beri Chromium tabanlı tarayıcılar uzantı sırasını her bağlantıda karıştırır. Aynı tarayıcı bu yüzden bağlantıdan bağlantıya farklı JA3 üretir. JA3'ün özgün deposu da Mayıs 2025'te arşivlendi.

JA4 bu sorunu çözmek için geliştirildi. Tek bir özet yerine, alt çizgiyle ayrılmış üç parçadan oluşur. İlk parça düz metindir ve altı bilgi taşır.

Protokol harfi t ise TCP, q ise QUIC demektir. Ardından TLS sürümü gelir. SNI varsa d, yoksa i yazar. Sonra şifre takımı ve uzantı sayıları, en sonda ilk ALPN değerinin ilk ve son karakteri gelir.

İkinci parça sıralanmış şifre takımlarının SHA-256 özetinin ilk 12 karakteridir. Üçüncü parça da 12 karakterlik bir özettir. Sıralanmış uzantıları ve özgün sırasıyla imza algoritmalarını kapsar.

Sıralama yüzünden uzantı karıştırma JA4'ü değiştirmez. Wireshark 4.2'den beri JA4 değerini tls.handshake.ja4 alanında kendisi hesaplar.

$ tshark -r web01.pcap -Y 'tls.handshake.type == 1' -T fields \
    -e ip.src -e ip.dst -e tls.handshake.extensions_server_name -e tls.handshake.ja4 \
  | sort -u | grep 't12d1908h1_2b729b4bf6f3'
10.20.30.58	192.0.2.44	statik.dagitim.example	t12d1908h1_2b729b4bf6f3_97e6b6ac8e76
10.20.30.61	203.0.113.19	cdn-update-srv.example	t12d1908h1_2b729b4bf6f3_97e6b6ac8e76

Çıktıyı satır satır oku. İki farklı iç makine, iki farklı dış adrese ve iki farklı alan adına gidiyor. Ama JA4 değeri birebir aynı.

İlk parça t12d1908h1 şunu söyler: TCP üstünde TLS 1.2, SNI var, 19 şifre takımı, 8 uzantı, ALPN http/1.1. Güncel bir tarayıcı TLS 1.3 sunar ve çoğu kez h2 ister, bu istemci ikisini de yapmıyor.

10.20.30.58 bu yüzden incelemeye girer. Yine de JA4 tek başına kimlik değildir. Aynı kitaplıkla yazılmış meşru bir güncelleme aracı da aynı izi verir. JA4'ü süreç adı, sertifika ve zamanlama gibi başka kanıtlarla birleştirirsin.

İçeriği okuyamadığında davranışa bakarsın. Dört ölçü birlikte okunur: bağlantı sıklığı, süre, yön ve boyut. fin-pc12 her dakika 203.0.113.19 adresine kısa bir bağlantı açıyor ve her seferinde yaklaşık 1400 bayt taşıyor.

İnsan trafiği bu kadar düzenli olmaz. Aynı hedefle kurulan yirmi dakikalık tek oturumda ise dışarı giden veri gelen verinin yaklaşık yetmiş katı. Bu ölçüler şifrelemeden etkilenmez, çünkü paket başlıkları ve zamanları her zaman açıktır.

Ağ yetmediğinde başka kaynaklara geçersin. Kurumsal vekil sunucu şifreli isteklerin bile alan adını ve boyutunu yazar. Uç nokta ajanı ya da Sysmon ise bağlantıyı açan süreci verir. Aşağıdaki conn.log satırları iki deseni yan yana gösterir.

$ zeek-cut -u ts id.resp_h id.orig_p duration orig_bytes resp_bytes < conn.log \
    | awk '$2 == "203.0.113.19"' | head -5
2026-09-14T00:09:02+0000	203.0.113.19	49868	0.401327	1412	236
2026-09-14T00:09:02+0000	203.0.113.19	49871	1204.997301	214097651	3118402
2026-09-14T00:10:04+0000	203.0.113.19	49874	0.398112	1408	236
2026-09-14T00:11:01+0000	203.0.113.19	49877	0.402877	1414	236
2026-09-14T00:12:05+0000	203.0.113.19	49880	0.387401	1410	236

Kanalı tanımlarken göstergeleri birleştirirsin. Hedef adres, SNI değeri, sertifika parmak izi, JA4 değeri ve zamanlama deseni aynı hikâyeyi anlatıyorsa kanal tanımlanmıştır.

x509.log'daki fingerprint alanı burada işe yarar. Aynı sertifika parmak izi başka bir adreste çıkarsa, iki sunucu büyük olasılıkla aynı kişinin altyapısıdır. SNI değeri de raporda gösterge olarak yer alır. Ama ECH yaygınlaştıkça dış SNI gerçek hedefi göstermeyebilir, bunu da raporda belirtirsin.

Kendi kontrolündeki bir istemcinin trafiğini çözmenin meşru bir yolu var: anahtar günlüğü. Birçok TLS kitaplığı, SSLKEYLOGFILE ortam değişkeni tanımlıysa oturum sırlarını o dosyaya yazar. Temmuz 2026'da yayımlanan RFC 9850 bu dosyanın biçimini tanımlar. Her satır bir etiket, ClientHello'daki rastgele değer ve sırrın kendisini taşır.

Wireshark bu dosyayı okuyunca şifreli kaydı açar. RFC 9850 aynı zamanda açık bir uyarı yapar: bu yöntem yalnız test verisi taşıyan sistemler içindir, üretimde kullanılmaz. Bunu yalnız kendi lab ortamında dene.

# Yalnız kendi lab makinende
$ export SSLKEYLOGFILE=$HOME/lab/keys.log
$ curl -s --http1.1 https://lab.test/giris -o /dev/null
$ cut -d' ' -f1 $HOME/lab/keys.log | sort -u
CLIENT_HANDSHAKE_TRAFFIC_SECRET
CLIENT_TRAFFIC_SECRET_0
EXPORTER_SECRET
SERVER_HANDSHAKE_TRAFFIC_SECRET
SERVER_TRAFFIC_SECRET_0

$ tshark -r lab.pcap -o tls.keylog_file:$HOME/lab/keys.log -Y http.request \
    -T fields -e http.host -e http.request.uri
lab.test	/giris

Çıktıyı satır satır oku. export komutu değişkeni tanımlar, curl bağlantıyı kurarken sırları dosyaya yazar. cut ve sort komutları dosyadaki etiket türlerini listeler. Bunlar TLS 1.3 oturumunun el sıkışma ve trafik sırlarıdır.

Son komutta tshark bu dosyayla kaydı çözer ve şifreli kanalın içindeki HTTP isteğini okur: lab.test üzerindeki /giris sayfası. Anahtar dosyası, koruduğu trafik kadar hassastır.

Sızarsa o oturumların hepsi okunur. İşin bitince dosyayı silersin. Olay müdahalesinde bir makinede beklenmedik bir SSLKEYLOGFILE tanımı bulursan, bunu da bulgu olarak yazarsın.

Kurumlar şifreli trafiği görmek için TLS incelemesi de kurar. Vekil sunucu, istemciyle kendi arasında bir oturum, hedefle ayrı bir oturum açar. Bunun için istemcilere kurumun kök sertifikası dağıtılır. Bu yöntem çalışan mahremiyetine doğrudan dokunur.

Kurulumdan önce yazılı politika, çalışanlara bildirim ve bir istisna listesi gerekir. Bankacılık, sağlık ve kişisel e-posta çoğu kurumda istisnaya alınır. Sertifika sabitleme (pinning) kullanan uygulamalar da listeye girer. Şifreli DNS görüşü ayrıca daraltır.

DoH (RFC 8484) sorguyu HTTPS içinde 443 portundan, DoT (RFC 7858) ise 853 portundan taşır. Savunmada istemcileri kurumsal çözümleyiciye zorlar, dışarı giden 53 ve 853 portlarını kapatırsın. Tarayıcıların DoH ayarını da kurum politikasıyla kurumsal çözümleyiciye yönlendirirsin. Sorgular şifreli akmaya devam eder, ama hepsi tek bir noktada günlüğe düşer.