SSL/TLS Inspection Tasarımı: Sertifika, İstisnalar ve Riskler

Şifre çözülmeyen trafikte NGFW’nin IPS, antivirüs, DLP ve URL filtreleme motorları yalnızca bağlantının dış kabuğunu görür; zararlı dosya HTTPS içinde gelir ve hiçbir imzaya takılmadan geçer. SSL/TLS inspection bu görünürlüğü geri verir. Yanlış kurulduğunda ise uygulama kırar, gizlilik sorunu doğurur ve firewall’u darboğaza çevirir. Aşağıdaki rehber; incelemenin kapsamı, iç CA dağıtımı, istisna politikası ve kademeli devreye alma kararlarını verecek güvenlik ve ağ ekipleri için yazıldı.

Şifreli trafiği neden ve ne ölçüde incelemeli

Zararlı yazılım indirmeleri, kimlik avı sayfaları ve komuta-kontrol (C2) bağlantıları çoğunlukla HTTPS üzerinden gelir. Şifre çözülmeden IPS imzaları HTTP gövdesine, antivirüs motoru indirilen dosyaya, DLP ise yüklenen içeriğe bakamaz. Öte yandan kurumsal siber güvenlik açısından her bağlantıyı çözmek ne zorunlu ne de akıllıca. Sorulacak soru şu: hangi trafik grubunda hangi kontrol çalışmalı?

Kontrolleri risk ve getiri üzerinden eşleştirin:

• Kullanıcıdan internete web trafiği: dosya indirme, kategorisi belirsiz veya yeni kaydedilmiş alan adları ve dosya paylaşım servisleri en yüksek getiriyi verir.
• Sunuculardan internete çıkış: sunucunun gideceği hedefler zaten sınırlı olmalı. Burada inceleme yerine hedef bazlı izin listesi çoğu zaman daha etkilidir.
• İçeriden yayınlanan servisler (inbound): sunucunun kendi sertifikası ve özel anahtarı firewall’a yüklenerek gelen trafik incelenebilir. Bu, giden trafik incelemesinden farklı bir modeldir ve anahtar yönetimini ayrıca planlamak gerekir. TLS 1.3’te ve ileri gizlilik (PFS) sağlayan şifre takımlarında anahtarı bilmek pasif çözme için yetmez; firewall bağlantının ortasında aktif rol almalıdır. Bu desteği cihaz dokümantasyonundan doğrulayın.

Sertifika incelemesi ve derin inceleme farkı

Üreticiler farklı adlar kullansa da iki temel mod var. Sertifika incelemesinde (certificate inspection) firewall bağlantıyı çözmez; ClientHello içindeki SNI alanını ve TLS 1.2’de açık gönderilen sunucu sertifikasını okuyarak karar verir. Derin incelemede (full/deep inspection) firewall istemci ile sunucunun arasına girer: sunucuya kendisi bağlanır, sunucu sertifikasını doğrular ve istemciye kurumun iç CA’sıyla yeniden imzaladığı bir sertifika sunar.

Özellik	Sertifika incelemesi	Derin inceleme
Trafik çözülür mü	Hayır	Evet
Görünen bilgi	SNI, (TLS 1.2’de) sertifika	URL yolu, başlıklar, gövde, dosyalar
Uç noktada CA gereksinimi	Yok	İç CA güvenilir olmalı
Uygulama kırma riski	Düşük	Pinning ve mTLS’de yüksek
Kaynak tüketimi	Düşük	Yüksek
Uygun kullanım	Kategori/alan adı filtreleme	IPS, antivirüs, DLP, sandbox

Derin incelemenin sık atlanan bir sorumluluğu var: firewall artık sunucu sertifikasının doğrulayıcısıdır. Süresi dolmuş, kendinden imzalı veya ad uyuşmazlığı olan bir sertifikayı firewall kendi CA’sıyla geçerli bir sertifikaya çevirirse kullanıcı tarayıcı uyarısını hiç görmez. Sahada en sık karşılaştığımız yanlış yapılandırma budur. Profilde “güvenilmeyen sunucu sertifikası” davranışını engelle veya kullanıcıya güvenilmeyen sertifika sun olarak ayarlayın; sessizce izin vermeyin. Aynı şekilde firewall’un sunucu tarafında SSLv3, TLS 1.0 ve 1.1 gibi zayıf sürümlere düşmesine izin vermeyin.

İç CA sertifikasının uç noktalara dağıtımı

Yeniden imzalamada kullanılan CA, kurumsal PKI’ın kök CA’sı olmamalı. Doğru yapı şu: kök CA altında yalnızca TLS inceleme için bir alt CA (subordinate CA) üretin, özel anahtarını firewall üzerinde (destekleniyorsa HSM veya korumalı depoda) tutun, uç noktalarda kök CA’nın güvenilir olmasını sağlayın. Firewall ele geçirilirse yalnızca bu alt CA iptal edilir. Kök yerinde kalır.

Pilotta TLS hatası açan çağrıların çoğu, CA’nın ulaşmadığı bir depodan gelir. Dağıtımda en sık unutulan noktalar:

• Windows: GPO’da Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies altındaki güvenilir kök ve ara CA depoları; Intune’da güvenilir sertifika profili.
• macOS ve mobil cihazlar: MDM sertifika yükü. iOS ve Android’de uygulamalar kullanıcı tarafından yüklenen CA’lara güvenmeyebilir.
• Firefox: kendi sertifika deposunu kullanır; kurumsal politikadaki ImportEnterpriseRoots ayarı veya security.enterprise_roots.enabled tercihi ile işletim sistemi deposuna güvenmesi sağlanır.
• Geliştirici araçları ve çalışma zamanları: Java (cacerts deposu), Python requests (REQUESTS_CA_BUNDLE), Node.js (NODE_EXTRA_CA_CERTS), Git (http.sslCAInfo) ve konteyner imajları işletim sistemi deposunu kullanmayabilir.
• Linux sunucu ve istemciler: Debian/Ubuntu’da update-ca-certificates, RHEL ailesinde update-ca-trust.

# Debian/Ubuntu: kurum kök CA'sını sistem deposuna ekleme
sudo cp kurum-kok-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

# RHEL/Rocky/Alma
sudo cp kurum-kok-ca.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

# Java uygulaması için (keystore yolu sürüme göre değişir)
keytool -importcert -alias kurum-kok-ca -file kurum-kok-ca.crt \
  -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit

Java örneğindeki changeit varsayılan depo parolasıdır; kurumunuzda değiştirildiyse ona göre uyarlayın. Java sürümü güncellendiğinde cacerts yenisiyle değişebilir. Eklenen CA da gider.

İstisna kategorileri: bankacılık, sağlık ve pinning yapan uygulamalar

İstisna listesinin iki gerekçesi vardır: teknik ve hukuki. Teknik istisnalar, incelemenin çalışmadığı trafiği kapsar:

• Sertifika sabitleme (pinning): uygulama yalnızca belirli bir sertifikayı veya açık anahtarı kabul eder, yeniden imzalanmış sertifikayı reddeder. Bazı mobil uygulamalar, güvenlik ajanları ve güncelleme istemcileri böyle davranır.
• Karşılıklı TLS (mTLS): istemcinin sertifikasıyla kimlik doğruladığı servislerde firewall istemcinin özel anahtarına sahip değildir; bağlantıyı sürdüremez.
• İşletim sistemi ve güvenlik ürünü güncellemeleri: güvenilir ve yüksek hacimlidir. Çözmenin getirisi düşük, maliyeti yüksektir.

Gizlilik istisnaları ise çalışanın sağlık gibi özel nitelikli kişisel verilerine (KVKK md. 6) veya kişisel bankacılık gibi hassas finansal bilgilerine eriştiği kategorileri kapsar. Çözülen trafikte kişisel veri bulunacağı için incelemenin amacı, kapsamı ve log saklama süresi aydınlatma metni ve iç politikalarla tanımlanmalı. Hukuk ve KVKK sorumlusunun onayı olmadan kapsamı genişletmeyin.

TLS 1.3, ECH ve QUIC’in incelemeye etkisi

TLS 1.3 (RFC 8446) tasarımı üç noktada değiştirir. Birincisi, sunucu sertifikası el sıkışmada şifreli gider; sertifika incelemesi pratikte SNI’ye kalır. İkincisi, statik RSA anahtar değişimi kaldırıldı; pasif bir cihaza sunucu anahtarı verip trafiği çözmek artık mümkün değil, inceleme ancak bağlantının ortasına girilerek yapılır. Üçüncüsü, firewall istemciyle ve sunucuyla iki ayrı TLS oturumu kurar; cihaz bir tarafta TLS 1.3’ü desteklemiyorsa bağlantıyı TLS 1.2’ye düşürebilir veya incelemeyi atlayabilir. Bu, güvenlik seviyesini sessizce düşürür. Profilde izin verilen en düşük sürümü açıkça tanımlayın ve cihazın derin incelemede TLS 1.3’ü tam desteklediğini sürüm notlarından doğrulayın.

Encrypted Client Hello (ECH), SNI dahil ClientHello’nun hassas kısmını şifreler. Tarayıcı ECH yapılandırmasını DNS HTTPS kaydından aldığı için kurumsal DNS’i ve DoH kullanımını kontrol etmek, ECH’nin ağınızda nasıl davranacağını doğrudan belirler; bu konu kurumsal DNS filtreleme rehberinde ayrıca işleniyor. Yönetilen tarayıcılarda ECH kurumsal politikayla kapatılabilir (örneğin Chrome’da EncryptedClientHelloEnabled).

QUIC (RFC 9000) UDP 443 üzerinde çalışır ve TLS 1.3’ü protokolün içine gömer. Çoğu firewall QUIC’i derin incelemeyle çözemez. Yaygın uygulama, giden UDP 443’ü engelleyip tarayıcıyı TCP üzerindeki TLS’e düşürmektir; yönetilen Chrome’da QuicAllowed politikası da kullanılabilir. Cihazınız QUIC’i tanıyıp engelleme veya inceleme seçeneği sunuyorsa üreticinin önerisini izleyin. UDP 443 açık kaldıysa inceleme politikanızın büyük kısmı boşa çalışır.

Performans ve kapasite planlaması

Derin inceleme her bağlantı için iki ayrı TLS el sıkışması, sertifika üretimi ve simetrik şifreleme/çözme demektir. Üretici veri sayfalarında “firewall throughput” ile “SSL inspection throughput” bu yüzden ayrı verilir ve ikincisi belirgin biçimde düşüktür. Kapasite hesabında şunlara bakın:

• Belirleyici olan toplam bant genişliği değil, çözülecek trafik ve saniyedeki yeni TLS oturumu sayısıdır.
• İncelemeyle birlikte açılan IPS, antivirüs ve sandbox profilleri yükü artırır. Veri sayfası değerinin hangi profil kombinasyonuyla ölçüldüğünü kontrol edin.
• Güncellemeler, video akışı ve büyük bulut yedeklemeleri gibi istisnalar yükü ciddi ölçüde azaltır. İstisna politikası aynı zamanda bir performans aracıdır.
• Pilot dönemde CPU, bellek, oturum tablosu ve SSL işlem kuyruklarının tepe saat değerlerini izleyin.

Cihaz seçimi aşamasındaki ölçütleri kurumsal firewall seçimi rehberinde topladık. Burada asıl mesele, seçilen cihazın kendi trafik karışımınızla test edilmesidir. Veri sayfası laboratuvar ölçümüdür.

Kademeli devreye alma ve doğrulama

1. Envanter ve hedef: hangi kullanıcı grupları ve hangi kontroller için inceleme yapılacağını, istisna kategorilerini ve log saklama kuralını yazılı hale getirin.
2. PKI hazırlığı: inceleme alt CA’sını üretin, uç noktalara kök CA’yı dağıtın, dağıtım oranını raporlayın. CA’sı olmayan cihaza derin inceleme uygulamayın.
3. Sertifika incelemesiyle başlangıç: tüm kullanıcılar için SNI tabanlı kategori filtrelemeyi açın. Bu aşama uç noktada değişiklik gerektirmez.
4. BT pilot grubu: derin incelemeyi önce BT ekibine uygulayın; TLS hata logları ve kullanıcı geri bildirimleriyle teknik istisna listesini çıkarın.
5. Bölüm bazlı genişletme: her dalgada yeni istisnaları kayda geçirin, IPS ve antivirüs profillerini çözülen trafikte izleme modunda başlatın (ayrıntılar IPS politikası ayarlama rehberinde).
6. Düzenli gözden geçirme: istisnaları ve güvenilmeyen sertifika engellemelerini çeyrek dönemlerde inceleyin.

Doğrulamada ilk bakılacak yer, istemcinin gördüğü sertifikayı veren CA’dır. İncelenen bir sitede issuer alanında inceleme CA’sı, istisna listesindeki bir sitede gerçek genel CA görünmelidir:

openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates

Windows uç noktalarında kök CA’nın gerçekten yüklendiğini PowerShell ile denetleyin:

Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Subject -like "*Kurum Kok CA*" } |
  Select-Object Subject, Thumbprint, NotAfter

Son olarak bilerek süresi dolmuş veya ad uyuşmazlığı olan bir test sitesine bağlanın; firewall’un bu bağlantıyı engellediğini ya da tarayıcıya güvenilmeyen bir sertifika sunduğunu görün. Bu test, derin incelemenin en tehlikeli yanlış yapılandırmasını yakalar. Beş dakika sürer. Politika ve profil yapısını kurumunuza göre kurgulamak için firewall kurulumu ve kural yönetimi ile ağ güvenliği ve segmentasyon çalışmalarında bu kararları birlikte ele alıyoruz.

Sık sorulan sorular

SSL inspection için firewall’un kendi ürettiği sertifika yeterli mi?

Pilot için yeterli. Üretimde kurumsal PKI’dan yalnız bu iş için ayrılmış bir alt CA kullanın. Sertifikanın ömrü, iptali ve yenilenmesi kurumun elinde kalır, kök CA anahtarı da firewall’a hiç taşınmaz.

Sertifika incelemesi TLS 1.3’te hâlâ işe yarar mı?

Kısmen. TLS 1.3’te sunucu sertifikası şifreli gider; sertifika incelemesi pratikte SNI alanına kalır. Alan adı ve kategori tabanlı engelleme çalışır, ancak ECH kullanılan bağlantılarda SNI de gizlenebildiği için görünürlük azalır.

QUIC trafiğini engellemek kullanıcıları etkiler mi?

Çoğu zaman fark edilmez. UDP 443 kapandığında tarayıcı aynı siteye TCP üzerinden TLS ile bağlanır. Yine de QUIC veya UDP kullanan video konferans gibi kurumsal uygulamaları pilot grupta deneyin; gerekiyorsa hedef bazlı istisna tanımlayın.

Hangi trafik asla çözülmemeli?

Sağlık gibi KVKK’da özel nitelikli veri işlenen kategoriler, kişisel bankacılık gibi hassas finansal servisler, sertifika sabitleme yapan uygulamalar, istemci sertifikasıyla karşılıklı kimlik doğrulama kullanan servisler ve işletim sistemi güncelleme kanalları için istisna tanımlamak yaygın ve savunulabilir bir yaklaşımdır. Listeyi hukuk ve KVKK sorumlusuyla birlikte onaylayın.