Microsoft’un güvenlik alanındaki en önemli adımlarından biri olan Transport Layer Security (TLS) 1.3 protokolü artık Windows 11 ve Windows Server 2025 sürümlerinde varsayılan hale getirildi.
Daha hızlı, daha güvenli ve modern kriptografi yöntemleriyle desteklenen TLS 1.3 teoride kurumsal kullanıcılar için büyük bir kazanım gibi görünüyor.
Ancak bu yeni protokolün IIS (Internet Information Services) ve IIS Express üzerinde kritik bir sınırlama yarattığı ortaya çıktı.
Microsoft mühendisi Matt Hamrick tarafından da doğrulanan bu sorun özellikle istemci sertifikalarıyla çalışan uygulamalarda servis kesintilerine ve doğrulama hatalarına yol açabiliyor.
Üstelik Microsoft’un kendi açıklamaları bu durumun uzun süre çözümsüz kalabileceğini işaret ediyor.
TLS 1.3 Nedir?
Transport Layer Security (TLS) internet üzerinden yapılan veri iletişimlerini güvenli hale getirmek için kullanılan en yaygın kriptografik protokoldür. Web sitelerine bağlandığınızda tarayıcı adres çubuğunda gördüğünüz https:// ifadesi aslında TLS sayesinde güvenli hale gelir.
TLS 1.3 bu protokolün en güncel ve en güvenli sürümüdür.
2018 yılında IETF (Internet Engineering Task Force) tarafından standartlaştırılmıştır ve bugün modern tarayıcıların ve sunucuların büyük çoğunluğu tarafından desteklenmektedir.
TLS 1.3’ün Amacı
- Daha yüksek güvenlik sağlamak – eski ve kırılabilir şifreleme algoritmaları tamamen kaldırıldı.
- Daha hızlı bağlantı kurulumu – el sıkışma (handshake) süreci basitleştirildi.
- Daha az işlem yükü – hem istemci hem de sunucu daha düşük CPU tüketimi ile çalışabiliyor.
- Gizlilik ve ileriye dönük güvenlik – anahtar değişim yöntemleri sayesinde geçmiş trafiğin şifresi açılsa bile çözülemiyor.
TLS 1.3 ile Gelen Önemli Yenilikler
🔹 Basitleştirilmiş El Sıkışma (Handshake)
- TLS 1.2’de bağlantı kurulurken en az iki gidiş-dönüş (2 round trip) gerekiyordu.
- TLS 1.3’te bu süreç tek gidiş-dönüşe (1-RTT) indirildi.
- Sonuç Web siteleri ve servisler daha hızlı açılıyor.
🔹 Eski Algoritmaların Kaldırılması
- Artık RC4, DES, 3DES, SHA-1 gibi güvenliği kırılmış algoritmalar desteklenmiyor.
- Sadece modern güçlü şifreleme yöntemleri kullanılabiliyor.
🔹 İleriye Dönük Gizlilik (Forward Secrecy)
- Her bağlantı için geçici (ephemeral) anahtarlar oluşturuluyor.
- Bir saldırgan sunucu anahtarını ele geçirse bile geçmiş iletişimleri çözümleyemiyor.
🔹 0-RTT Desteği (Sıfır Gidiş-Dönüş Zamanı)
- İstemci daha önce bağlandığı bir sunucuya tekrar bağlandığında el sıkışmayı beklemeden veri göndermeye başlayabiliyor.
- Bu performansı ciddi ölçüde artırıyor (özellikle mobil uygulamalar için).
TLS 1.2 ile TLS 1.3 Arasındaki Farklar
| Özellik | TLS 1.2 | TLS 1.3 |
|---|---|---|
| El sıkışma süresi | 2 gidiş-dönüş (yavaş) | 1 gidiş-dönüş (hızlı) |
| Güvenlik algoritmaları | Eski ve zayıf algoritmalar hâlâ var | Sadece modern algoritmalar |
| İleriye dönük gizlilik | Opsiyonel | Zorunlu |
| 0-RTT desteği | Yok | Var |
| Yeniden görüşme (Renegotiation) | Var | Yok (güvenlik için kaldırıldı) |
Nerelerde Kullanılır?
- Web siteleri (HTTPS) → TLS 1.3 sayesinde tarayıcı ve sunucu arasındaki trafik şifrelenir.
- E-posta sunucuları (SMTP, IMAP, POP3) → Posta trafiği güvenli hale gelir.
- VPN çözümleri → TLS tabanlı VPN’ler daha güvenli çalışır.
- Kurumsal uygulamalar → Özellikle istemci–sunucu tabanlı iş yazılımlarında güvenlik sağlar.
TLS 1.3’te “Yeniden Görüşme” Neden Kaldırıldı?
TLS 1.2’de bulunan “renegotiation” yani yeniden görüşme mekanizması sunuculara aktif bir oturum sırasında ikinci bir el sıkışma başlatarak istemciden sertifika talep etme imkânı veriyordu. Bu sayede:
- Kullanıcı önce şifreli bir bağlantı kuruyor,
- Ardından gerektiğinde sertifika ile kimlik doğrulaması yapılabiliyordu.
TLS 1.3 ile birlikte bu yöntem bilinçli bir şekilde kaldırıldı. Gerekçe ise iki yönlüydü:
- Güvenlik: Yeniden görüşme mekanizmasının geçmişte çeşitli saldırılara kapı araladığı biliniyordu.
- Performans: Fazladan el sıkışma oturum açılışını yavaşlatıyor ve işlem yükünü artırıyordu.
Artık TLS 1.3’te istemci sertifikası yalnızca ilk el sıkışma sırasında talep edilebiliyor. Bu da kimlik doğrulamanın esnekliğini ciddi ölçüde sınırlıyor.
IIS Üzerindeki Etki: http.sys Darboğazı
Windows’un ağ yığını için kritik rol oynayan http.sys oturum açılışında denetimi eline alıyor. Ancak istemci sertifikası başlangıçta tanımlanmamışsa TLS 1.3’ün yeni kısıtlamaları nedeniyle sonradan sertifika talebi yapılamıyor.
- Windows 10 ve önceki sürümlerde: http.sys bağlantıyı tamamen kapatıyordu.
- Windows 11 24H2 ve Server 2025 ile birlikte: http.sys artık bağlantıyı kesmek yerine “desteklenmiyor” uyarısı döndürüyor.
Bu durumda IIS tarafında 0x80070032 hata kodu eşliğinde HTTP 500 sunucu hatası oluşuyor.
Sonuç: client sertifikası gerektiren intranet uygulamaları, finansal servisler veya kimlik doğrulaması zorunlu sistemler doğrudan kesintiye uğrayabiliyor.
Microsoft’un Alternatif Önerisi: Post-Handshake Authentication
Microsoft, TLS 1.3’te “post-handshake authentication” yani oturum sonrası kimlik doğrulamasını teoride alternatif olarak sunuyor. Bu yöntem, yeniden görüşmenin yerini alması için tasarlandı. Ancak pratikte tablo şu şekilde:
- Çoğu tarayıcı bu özelliği henüz desteklemiyor.
- Birçok istemci kütüphanesi gerekli uyarlamaları yapmış değil.
- Gerçek dünyada yaygın kullanım için yıllar gerekebilir.
Dolayısıyla bu öneri, bugünkü kurumsal ortamlarda uygulanabilir bir çözüm olmaktan çok uzak görünüyor.
Resmî Yama Beklentisi Belirsiz
Ağustos 2025 itibarıyla Microsoft özellikle IIS Express kullanıcıları için herhangi bir resmi düzeltme yayımlamadı.
Matt Hamrick’in açıklaması da durumun belirsizliğini özetliyor:
“Bu sorun için bir düzeltme olup olmayacağından ve eğer olacaksa neye benzeyeceğinden gerçekten emin değilim.”
Bu ifade, özellikle uzun vadeli yatırım yapan kurumsal BT departmanları için endişe verici bir tablo ortaya koyuyor.
Geçici Çözümler: BT Ekipleri Ne Yapabilir?
Sorunu yaşayan kuruluşlar için öne çıkan geçici çözüm yolları:
- TLS 1.3’ü devre dışı bırakmak
- Gelen bağlantılarda TLS 1.2 kullanılmasını zorunlu kılmak kısa vadede en güvenli yöntem.
- http.sys yapılandırmasını değiştirmek
- Sertifika talebini mutlaka ilk el sıkışma aşamasında gerçekleştirecek şekilde ayarlamak.
- Uygulama tarafında sertifika zorunluluğunu kaldırmak
- Bazı durumlarda iş süreçlerine uygun olabilir, ancak güvenlikten ödün verileceği unutulmamalı.
- Alternatif kimlik doğrulama yöntemleri
- JWT, OAuth 2.0 veya Kerberos gibi uygulama katmanı çözümlerine yönelmek.
Kurumsal Ortamlar İçin Risk Analizi
- Operasyonel Risk: Sertifika tabanlı doğrulama yapan iş uygulamaları aniden çalışmaz hale gelebilir.
- Müşteri Deneyimi Riski: Son kullanıcılar hata ekranlarıyla karşılaşabilir, hizmet kesintileri yaşanabilir.
- Güvenlik Riski: Sertifika zorunluluğunu kaldırmak, saldırı yüzeyini genişletebilir.
- Uyumluluk Riski: Finans, sağlık ve kamu gibi regülasyonlu sektörlerde sertifika zorunluluğu kritik öneme sahiptir.
Önerilen Yol Haritası
- Test Ortamları Kurun: TLS 1.3 etkilerini üretim öncesi simüle edin.
- Geçici Olarak TLS 1.2’ye Dönün: Kritik iş uygulamalarında kesinti riskini sıfırlayın.
- Microsoft’un Yol Haritasını Takip Edin: Yayınlanacak yamalar veya yeni protokol uzantılarına hazırlıklı olun.
- Güvenlik ve Uyumluluk Ekiplerini Dahil Edin: Sertifika politikalarını güncelleyin, alternatif doğrulama çözümlerini tartışın.
Windows 11’in güvenlik güncellemeleri siber tehditlere karşı daha güçlü bir kalkan sağlasa da TLS 1.3’ün yeniden görüşmeyi kaldırması kurumsal dünyada beklenmedik sonuçlar doğuruyor. Özellikle IIS tabanlı uygulamalarda istemci sertifikasıyla doğrulama yapan sistemler, aniden kullanılmaz hale gelebiliyor.
Kısa vadede tek güvenilir çözüm, TLS 1.2’ye geri dönmek gibi görünüyor. Uzun vadede ise sektörün post-handshake authentication desteğini benimsemesi ve Microsoft’un sağlayacağı olası yamalar belirleyici olacak.