SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama
SSL Sertifika Analizi Açık Port Tespiti Web Uygulama Tarama DNS Güvenlik Denetimi HTTP Başlık Analizi Yanlış Yapılandırma Tespiti Yazılım Parmak İzi Alt Alan Adı Tarama

Tüm Kayıtlar

Kategori Kriptografik Yanlış Yapılandırma
Tipik Önem Derecesi Orta
OWASP A02:2021 – Kriptografik Başarısızlıklar
CWE CWE-326 – Yetersiz Şifreleme Gücü
Diğer adları Kullanımdan Kalkmış TLS, Zayıf TLS, Eski SSL/TLS
Etkilenen sistemler Web sunucuları, yük dengeleyiciler, API ağ geçitleri, CDN'ler ve TLS 1.0 ya da TLS 1.1'i hâlâ duyuran TLS sonlandıran tüm uç noktalar
İlgili standartlar RFC 8996 (TLS 1.0 ve 1.1'i kullanımdan kaldırır), PCI DSS v3.2.1+ (minimum TLS 1.2 zorunlu), NIST SP 800-52 Rev. 2
Etkilenen protokol sürümleri TLS 1.0 (RFC 2246, 1999), TLS 1.1 (RFC 4346, 2006)

Genel Bakış

Transport Layer Security (TLS), modern internet iletişimlerinin büyük çoğunluğunu güvence altına alan kriptografik protokoldür. TLS 1.0, 1999 yılında; TLS 1.1 ise 2006 yılında standart hâline getirilmiştir. Her iki sürüm de yapısal zayıflıkları ve bunlara karşı geliştirilmiş pratik saldırılar nedeniyle RFC 8996 (Mart 2021) ile resmen kullanımdan kaldırılmıştır. Bu sürümleri hâlâ destekleyen sunucular, istemcilerin bozuk kriptografik ilkellerle oturum kurmasına izin verir ve TLS'nin sağlaması gereken gizlilik ile bütünlük güvencelerini ortadan kaldırır.

Sensagraph, sürekli taşıma katmanı güvenliği değerlendirmeleri kapsamında TLS 1.0 ve TLS 1.1 desteğini otomatik olarak tespit eder.

Nasıl çalışır

TLS el sıkışması sırasında istemci, desteklediği protokol sürümlerini ve şifre takımlarını içeren bir ClientHello iletisi gönderir. Sunucu TLS 1.0 veya TLS 1.1'i kabul ederse her iki taraf da bu eski protokol çerçevelerini kullanarak oturum kurabilir. Bu sürümlere özgü başlıca zayıflıklar şunlardır:

  • BEAST (Browser Exploit Against SSL/TLS): TLS 1.0'ı etkiler; önceki kayıttan zincirlenen öngörülebilir IV ile CBC modunu kullanması, oturum çerezlerine yönelik seçili düz metin saldırılarına olanak tanır.
  • POODLE (Padding Oracle On Downgraded Legacy Encryption): Aslen SSL 3.0'a yönelik bu saldırının varyantları TLS 1.0'ın CBC dolgusunu hedef alır; ortadaki adam konumundaki bir saldırganın şifreli metnin tek tek baytlarını çözmesini mümkün kılar.
  • LUCKY13: TLS 1.0 ve 1.1'de kullanılan CBC modlu MAC-then-encrypt yapısına karşı zamanlama yan kanal saldırısı; kısmi düz metin kurtarmayı sağlar.
  • Zayıf PRF ve MAC algoritmaları: TLS 1.0, Sahte Rastgele İşlevinde (PRF) MD5 ve SHA-1'in birleşimini kullanır; her ikisi de kriptografik açıdan kırılmış kabul edilir. TLS 1.1, IV işlemesini iyileştirmiş olsa da aynı zayıf PRF'yi korumaktadır.
  • Sürüm düşürme saldırıları: Hem modern hem de eski TLS sürümlerini destekleyen sunucular, istemciler TLS 1.2 veya 1.3 tercih etse bile ağ düzeyindeki müdahalelerle daha zayıf sürümde oturum kurmaya zorlanabilir.
  • AEAD şifre takımlarının yokluğu: TLS 1.0 ve 1.1, AES-GCM gibi İlişkili Verilerle Kimlik Doğrulamalı Şifreleme (AEAD) şifre takımlarını desteklemez; bu takımlar TLS 1.3'te zorunlu, TLS 1.2'de ise güçlü biçimde önerilmektedir.

İş etkisi

TLS 1.0 veya TLS 1.1'in etkin bırakılması, birden fazla boyutta risk oluşturur:

  • Veri gizliliği: Aktif ağ saldırganları (örn. ortak Wi-Fi'de veya BGP ele geçirme yoluyla) yukarıdaki zayıflıkları kullanarak oturum trafiğini kısmen ya da tamamen çözebilir; kimlik bilgileri, oturum belirteçleri ve hassas veriler ifşa olabilir.
  • Uyumluluk ve düzenleyici risk: PCI DSS, TLS 1.0'dan Haziran 2018'den itibaren uzaklaşılmasını zorunlu kılmaktadır. HIPAA kılavuzu, NIST SP 800-52 ve pek çok ulusal veri koruma çerçevesi en az TLS 1.2 kullanımını şart koşmaktadır. Uyumsuzluk; denetimlere, para cezalarına veya ödeme işleme kapasitesinin kaybına yol açabilir.
  • Tarayıcı güveni kaybı: Chrome, Firefox, Safari ve Edge gibi büyük tarayıcılar 2020–2021 yılları arasında TLS 1.0 ve 1.1 desteğini kaldırdı. Bu tarayıcıları kullanan ziyaretçiler güvenlik uyarısı ya da bağlantı hatası alır; bu durum kullanıcı deneyimini ve marka güvenini olumsuz etkiler.
  • Üçüncü taraf ve API iş ortağı gereksinimleri: Pek çok ödeme işlemcisi, bulut sağlayıcısı ve API tüketicisi TLS 1.0/1.1 bağlantılarını resmen reddeder; geçişi tamamlamamış kuruluşlar entegrasyon hatalarıyla karşılaşır.

Nasıl düzeltilir

  1. Sunucu veya yük dengeleyici düzeyinde TLS 1.0 ve TLS 1.1'i devre dışı bırakın. Kabul edilen minimum protokolü TLS 1.2 olarak ayarlayın; platform destekliyorsa TLS 1.3'ü de etkinleştirin. Yapılandırma söz dizimi yazılıma göre değişir:
    • Nginx: ssl_protocols TLSv1.2 TLSv1.3;
    • Apache: SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
    • IIS: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols altındaki kayıt defteri anahtarları ya da IIS Crypto / Grup İlkesi aracılığıyla devre dışı bırakın.
    • HAProxy: ssl-min-ver TLSv1.2
  2. Yapılandırmayı uyguladıktan sonra protokol düzeyinde tarama yaparak değişikliği doğrulayın; TLS 1.0 ve TLS 1.1 el sıkışmalarının reddedildiğini teyit edin.
  3. Güçlü bir şifre takımı politikasıyla destekleyin. TLS 1.2'de bile zayıf şifre takımlarını (RC4, 3DES, dışa aktarım sınıfı şifreler, anonim DH) devre dışı bırakın. ECDHE tabanlı AEAD takımlarını tercih edin (örn. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256).
  4. Desteklendiği her yerde TLS 1.3'ü etkinleştirin. TLS 1.3, önceki sürümlerdeki savunmasız el sıkışma modlarını ortadan kaldırır, ileri gizliliği zorunlu kılar ve yalnızca AEAD şifre takımlarını destekler.
  5. Ortamdaki tüm TLS sonlandıran uç noktaları kontrol edin: Yalnızca kamuya açık HTTPS değil; CDN kenar düğümleri, API ağ geçitleri, dahili mikro hizmetler, posta sunucuları ve veritabanı bağlantıları da dahil olmak üzere.
  6. Devre dışı bırakmadan önce istemci uyumluluğunu değerlendirin. Kalan TLS 1.0/1.1 istemcilerini belirlemek için erişim günlüklerini inceleyin; desteği kesmeden önce bu istemcileri bilgilendirin veya geçişlerini sağlayın. Çok eski cihazlar (örn. Android < 5.0, IE 10) güncelleme yapılmadan TLS 1.2 üzerinde anlaşma yapamaz.
  7. Mozilla'nın TLS yapılandırma oluşturucusuna başvurun (ssl-config.mozilla.org); güncel en iyi uygulamalarla uyumlu, sunucuya özgü önerilen yapılandırmaları sunar.

Kaynaklar

Sıkça sorulan sorular

TLS 1.1, CBC modunda açık IV kullanımına geçerek BEAST saldırısının istismar ettiği öngörülebilir IV açığını gidermiş ve bu açıdan TLS 1.0'dan biraz daha güvenli hâle gelmiştir. Ancak TLS 1.1 aynı zayıf MD5/SHA-1 PRF'yi korumakta, AEAD şifre desteğinden yoksun kalmakta ve RFC 8996 ile TLS 1.0'ın yanı sıra resmen kullanımdan kaldırılmaktadır. Modern dağıtımlar için her iki sürüm de kabul edilebilir sayılmamalıdır.

Çok eski istemciler için evet. Android 5.0 altı sürümler, Internet Explorer 10 ve öncesi, Java 6/7 çalışma zamanları (manuel yapılandırma yapılmadıkça) ve bazı eski gömülü cihazlar, güncelleme yapılmadan TLS 1.2 üzerinde anlaşma yapamaz. Kullanımdan kaldırılmış protokolleri devre dışı bırakmadan önce bu istemcileri belirlemek için sunucu erişim günlüklerini incelemeniz ve kullanıcıları platformlarını güncellemeleri için bilgilendirmeniz önerilir.

Modern şifre takımlarıyla (ECDHE + AEAD) düzgün yapılandırıldığında TLS 1.2'nin pratikte istismar edilebilir bilinen bir açığı yoktur. Ancak RC4, 3DES, dışa aktarım sınıfı şifreler veya Encrypt-then-MAC uzantısı olmayan CBC modlu takımların kullanımına izin veren TLS 1.2 dağıtımları SWEET32 ya da Lucky13 gibi saldırılara karşı savunmasız olabilir. TLS 1.3, yalnızca AEAD şifre takımlarını zorunlu kılarak ve ileri gizliliği şart koşarak bu endişelerin tamamını ortadan kaldırır.

Evet. PCI DSS v3.2.1, 'erken TLS' olarak tanımlanan TLS 1.0'dan Haziran 2018'den itibaren geçiş yapılmasını zorunlu kılmaktadır. TLS 1.1 de benzer biçimde önerilmemekte ve pek çok QSA tarafından uyumsuz olarak değerlendirilmektedir. PCI DSS v4.0, kart sahibi veri ortamları için minimum kabul edilebilir sürümün TLS 1.2 olduğunu pekiştirmektedir.

OpenSSL gibi komut satırı araçlarıyla doğrulayabilirsiniz (örn. 'openssl s_client -tls1 -connect example.com:443') ya da 'curl --tlsv1.0 --tls-max 1.0 https://example.com' komutunu kullanabilirsiniz. Başarılı bir el sıkışma, protokolün hâlâ etkin olduğuna işaret eder. SSL Labs'ın SSL Server Test gibi kamuya açık araçlar da hangi protokol sürümlerinin kabul edildiğini raporlayarak buna göre puan verir.