HSTS ve Preload Nedir? Web Sitenizi SSL Stripping'e Karşı Nasıl Korursunuz?

Web sitenizde geçerli bir SSL/TLS sertifikası olsa bile, bir kullanıcı adres çubuğuna http://siteniz.com yazdığında ilk istek şifresiz gider. Bu kısa an, saldırganın araya girip trafiği ele geçirmesine (Man-in-the-Middle) veya HTTPS’e yükseltmeyi engelleyip bağlantıyı HTTP’de tutmasına (SSL Stripping) olanak tanır. HSTS, tam olarak bu boşluğu kapatan bir HTTP yanıt başlığıdır. Bu yazıda HSTS’in ne yaptığını, direktiflerini, preload listesinin nasıl çalıştığını ve sitenizi erişilemez kılmadan nasıl kademeli devreye alacağınızı ele alıyoruz.

Sorun: HTTPS’iniz var ama ilk istek şifresiz

Diyelim ki siteniz HTTPS sunuyor ve HTTP’yi HTTPS’e yönlendiriyorsunuz. Kullanıcı http://siteniz.com yazdığında olaylar şöyle gelişir: tarayıcı önce şifresiz bir HTTP isteği yapar, sunucu 301 ile HTTPS’e yönlendirir, tarayıcı sonra HTTPS ile bağlanır. Sorun ilk adımdadır: o ilk şifresiz istek ağda görünür. Aynı Wi-Fi’daki bir saldırgan, bu isteği yakalayıp yönlendirmeyi kendisi yanıtlar ve kullanıcıyı HTTPS’e hiç geçirmeden trafiği şifresiz tutar (SSL Stripping). Kullanıcı adres çubuğunda kilit simgesi görmez ama çoğu kişi bunu fark etmez.

HSTS bu ilk şifresiz isteği ortadan kaldırır: tarayıcıya “bu alan adına bundan sonra yalnızca HTTPS ile bağlan, HTTP’yi hiç deneme” der.

HSTS başlığı ve direktifleri

Başlık şu biçimdedir:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

• max-age (zorunlu): Tarayıcının bu kuralı kaç saniye hatırlayacağı. Üretim için yaygın değer 2 yıldır (63072000). Süre boyunca tarayıcı, kullanıcı http:// yazsa bile isteği ağa çıkmadan HTTPS’e çevirir.
• includeSubDomains: Kural tüm alt alan adlarını da kapsar. Eklemeden önce tüm alt alanlarınızın (blog., api., panel. vb.) HTTPS sunduğundan emin olun.
• preload: En güçlü seviye. Alan adınızı tarayıcıların gömülü HSTS listesine ekletir; böylece tarayıcı sitenizi ilk ziyarette bile doğrudan HTTPS ile açar.

Önemli bir kural: HSTS başlığı yalnız HTTPS yanıtlarında geçerlidir. HTTP yanıtında gönderilirse tarayıcı yok sayar. Bu yüzden başlığı, yönlendirmeden sonra HTTPS tarafında göndermelisiniz.

Preload nasıl çalışır ve neden dikkatli olunmalı?

Normal HSTS’te koruma, kullanıcı siteyi en az bir kez HTTPS üzerinden ziyaret ettikten sonra başlar; ilk ziyaret hâlâ savunmasızdır. Preload bunu çözer. hstspreload.org üzerinden başvurduğunuzda alan adınız Chrome, Firefox, Safari gibi tarayıcılara gömülü gelir ve ilk ziyaret dahil her istek HTTPS’e zorlanır.

Ancak preload bir taahhüttür: listeden çıkmak aylar sürebilir ve bu süre boyunca HTTPS’i bozulmuş bir site erişilemez kalır. Bu yüzden başvuru öncesi şu koşullar sağlanmalıdır:

1. Geçerli bir sertifikanız var ve tüm HTTP trafiğini HTTPS’e yönlendiriyorsunuz.
2. Kök alan adı ve tüm alt alan adları HTTPS sunuyor.
3. max-age en az 1 yıl (31536000) ve hem includeSubDomains hem preload var.

Güvenli kurulum sırası (adım adım)

Aceleyle güçlü değerlerle başlamak, HTTPS’i eksik bir alt alanı erişilemez kılabilir. Önerilen kademe:

1. HTTP → HTTPS yönlendirmesini kurun (301). HSTS, HTTP’yi kapatmanın yerine geçmez; ikisi birlikte çalışır.
2. Kısa max-age ile başlayın: Strict-Transport-Security: max-age=300. Bu, bir yanlışlık olursa 5 dakikada geri dönebilmenizi sağlar.
3. Alt alanları doğrulayın, sonra max-age’i büyütüp includeSubDomains ekleyin.
4. Her şey stabil olduğunda preload ekleyip hstspreload.org’a başvurun.

Örnek Nginx yapılandırması (HTTPS sunucu bloğunda):

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

always parametresi, başlığın hata sayfalarında da gönderilmesini sağlar.

Nasıl doğrularsınız?

Kurduktan sonra başlığın gerçekten gittiğini kontrol edin:

curl -sI https://siteniz.com | grep -i strict-transport-security

Yanıtta strict-transport-security: max-age=... görmelisiniz. Tarayıcıda geliştirici araçlarının “Network” sekmesinde de yanıt başlıklarını inceleyebilirsiniz. Preload uygunluğunu hstspreload.org üzerinden test edebilirsiniz; site, eksik koşulları (yönlendirme, alt alan, direktifler) açıkça listeler.

Sık yapılan hatalar

• HTTP üzerinden HSTS göndermek: Yönlendirmeden önce HTTP tarafında göndermek etkisizdir; HTTPS tarafında gönderin.
• includeSubDomains’i erken eklemek: HTTPS’i olmayan bir alt alan (ör. eski bir blog.siteniz.com) varsa, kullanıcılar ona erişemez hale gelir. Önce envanter çıkarın.
• Preload’ı geri alınabilir sanmak: Listeden çıkmak yavaştır; tüm alt alanların HTTPS’i kesinleşmeden başvurmayın.
• Kısa max-age’de kalmak: Test için iyidir ama kalıcı koruma için uzun süre gerekir.

Özet

HSTS, “sertifikam var” ile “bağlantım gerçekten hep şifreli” arasındaki boşluğu kapatır ve SSL Stripping’i engeller. Doğru sıra: HTTPS yönlendirmesi → kısa max-age → uzun max-age → includeSubDomains → preload. Bu kademe hem saldırıyı önler hem de sitenizi erişilemez kılma riskini ortadan kaldırır. Kurduktan sonra curl ile başlığı doğrulamayı unutmayın.

Kaynaklar: MDN: Strict-Transport-Security, hstspreload.org, OWASP HSTS Cheat Sheet.

Sitenizin HSTS, sertifika ve HTTPS yönlendirme yapılandırmasının doğru olup olmadığını görmek ister misiniz? CyberTestify’ın dış yüzey taraması bu başlıkları ve yaygın TLS yanlış yapılandırmalarını yakaladığı gerçek yanıtlardan kontrol eder.