HSTS preload: gönderim gereksinimleri, riskler ve başlığınızla liste durumunuzu kontrol etme

1. HSTS preload listesi nedir?

HTTP Strict Transport Security, RFC 6797 ile tanımlanır. Sunucu HTTPS üzerinden Strict-Transport-Security: max-age=… gönderir; tarayıcı da max-age saniye boyunca bu ana makineye yalnızca HTTPS ile erişilebileceğini hatırlar. Ziyaretçinin tarayıcısı bu başlığı bir kez alana kadar, ilk düz http:// isteğini hiçbir şey korumaz ve aynı ağdaki bir saldırgan onu araya girerek yakalayabilir. RFC bu ilk bağlantı zayıflığını anlatır ve çözümlerden biri olarak önceden yapılandırılmış politikaları önerir.

Preload listesi bu çözümün uygulamadaki hâlidir. Listeyi Chromium projesi yönetir ve yeni girdiler Chrome’un kaynak koduna doğrudan yazılır. Chromium HSTS sayfasına ve hstspreload.org’a göre Firefox, Safari ve Edge, Chrome’unkine dayanan kendi listelerini tutar. Girdiyi içeren her tarayıcı sürümünde preload edilmiş bir alan adı ilk açılıştan itibaren yalnızca HTTPS’tir; gönderimler includeSubDomains içermek zorunda olduğundan altındaki her ad da öyledir.

Üç ayrıntı sık yanlış anlaşılır:

• preload yönergesi tarayıcıda hiçbir şey yapmaz. RFC 6797’nin parçası değildir ve tarayıcılar tanımadıkları yönergeleri yok sayar. Liste yöneticilerine alan adı sahibinin eklenmeyi kabul ettiğini bildirir. Başlığınız bunu taşıdığı anda herkes alan adınızı formdan gönderebilir.
• Listeye yalnızca kayıtlı alan adının tamamı girer. www.example.com veya shop.example.com değil, example.com gönderirsiniz; girdi, herkese açık olmayan iç alt alan adları dahil tüm alt alan adlarını kapsar.
• Bazı üst düzey alan adları bütünüyle preload edilmiştir. Örneğin .app veya .dev altındaki her alan adı, sahibi bir şey göndermemiş olsa bile listeyi kullanan tarayıcılarda zaten yalnızca HTTPS’tir.

2. Hâlâ preload’a ihtiyacınız var mı?

Çoğu site için muhtemelen hayır. Gönderim sitesi artık HSTS’nin önerildiğini, HSTS preload’un önerilmediğini söylüyor. Chrome ve Safari, HSTS politikası ne olursa olsun http:// ile başlayan gezintilerde otomatik olarak HTTPS’i dener; dolayısıyla preload’un kapatmak için tasarlandığı ilk ziyaret boşluğu daralmıştır. hstspreload.org’a göre preload, yalnızca bu otomatik yükseltmeler etkin bir saldırgan yüzünden başarısız olduğunda ek koruma sağlar ve faydası HSTS’nin kendisine kıyasla asgaridir.

Aşağıdakilerin hepsi doğruysa preload yine de anlamlı olabilir:

• ilk ziyarette sürüm düşürme sizin için önemlidir; örneğin insanlar herkese açık ağlardan giriş yapıyor veya ödeme yapıyordur;
• iç ve satıcı barındırmalı olanlar dahil mevcut ve gelecekteki her alt alan adı geçerli sertifikayla HTTPS sunabilir;
• alan adını ve üzerindeki HTTPS’i yıllarca tutmayı planlıyorsunuzdur.

Tam kontrol etmediğiniz alt alan adlarını ekipler veya satıcılar işletiyorsa, iç ana makineler herkese açık alan adının altındaysa, alan adı kısa ömürlü bir kampanyaya aitse ya da alan adını satma veya devretme ihtimaliniz varsa preload’u atlayın ya da erteleyin: girdi, biri kaldırma talep edene kadar alan adıyla birlikte sonraki sahibine geçer. preload içermeyen iyi yapılandırılmış bir HSTS başlığı zaten geri dönen her ziyaretçiyi korur.

3. Tam gönderim gereksinimleri

hstspreload.org bu koşulları gönderim sırasında denetler ve sonrasında da karşılamaya devam etmeniz gerekir: koşulları karşılamayan alan adları listeden çıkarılabilir; başlıktan preload çıkarmak ise alan adını hemen kaldırılmaya uygun hâle getirir.

Yönlendirme kuralı birçok siteyi yakalar. https://example.com/, https://www.example.com/ adresine yönleniyorsa bu yönlendirme yanıtının kendisi tam başlığı taşımalıdır. www sayfasındaki başlık sayılmaz, çünkü www.example.com tarafından belirlenen politika ana alan adına asla uygulanmaz. Geçen bir başlık şöyle görünür:

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

4. Riskler: preload’u geri almak neden zor?

• Kaldırma aylar sürer. Kaldırma, tarayıcı güncellemeleriyle kullanıcılara ulaşan bir kaynak değişikliğidir. Kaldırma sayfası, çoğu Chrome kullanıcısına ulaşmanın 6 ila 12 hafta sürebileceğini, diğer tarayıcılarda daha uzun olabileceğini söyler. Hiç güncellenmeyen bir tarayıcı eski girdiyi korur.
• HTTPS sunamayan alt alan adları çalışmaz. Tipik örnekler: yalnızca iç DNS’te çözülen intranet ana makineleri, kendinden imzalı sertifika kullanan yazıcı, yönlendirici ve depolama aygıtı yönetim sayfaları, unutulmuş test sunucuları ve yalnızca HTTP ile yanıt veren, CNAME üzerindeki satıcı hizmetleri; örneğin yardım masası, durum sayfası veya e-posta tıklama izleme bağlantıları. Alan adınızın preload edildiği bir tarayıcıda bunlar, hatayı geçmenin yolu olmadan başarısız olur.
• Sertifika hataları kesin hataya dönüşür. HSTS’li bir ana makinede RFC 6797, tarayıcının herhangi bir sertifika hatasında ziyaretçiye tıklayıp geçme izni vermeden bağlantıyı sonlandırmasını şart koşar. Herhangi bir alt alan adındaki süresi dolmuş bir sertifika, yenilenene kadar herkesi dışarıda bırakır; bu yüzden göndermeden önce yenilemeyi otomatikleştirin ve son kullanma tarihlerini izleyin.
• Geri dönen ziyaretçiler kayıtlı politikalarını korur. Listeden çıkmak, tarayıcıların başlığınızdan öğrendiği politikayı silmez. İki yıllık bir max-age ile bu kopya, ziyaretçi dönüp HTTPS üzerinden max-age=0 almadıkça iki yıl sürer.
• Yanlışlıkla gönderim. İçinde zaten preload bulunan bir şablondan kopyalanan başlık, herkesin alan adınızı göndermesi için yeterlidir. Bir sonraki bölümdeki plan bitene kadar yönergeyi eklemeyin.

5. Göndermeden önce aşamalı bir max-age planı

hstspreload.org, max-age değerini ilk aşamadan itibaren includeSubDomains ile birlikte aşamalı olarak artırmayı önerir. Her aşamada bozuk sayfalara bakın, trafik, girişler ve gelir gibi rakamlarınızı izleyin, çıkanı düzeltin, sonra ilerlemeden önce o aşamanın tam max-age süresi kadar en az bekleyin. Aşamaları önce bir test grubuyla yürütebilirsiniz, ancak sonrasında herkes için yürütün.

nginx’te başlığı HTTPS server bloğundan always parametresiyle gönderin; böylece hata sayfaları da taşır. HTTP yönlendirmesini de aynı ana makinede tutun. Bir location bloğu içindeki add_header satırı, orada sunucu düzeyindeki başlıkların yerini alır (nginx headers modülü).

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # stage 1: change the value at each stage
    add_header Strict-Transport-Security "max-age=300; includeSubDomains" always;
}

Yalnızca kademeli artış beş haftadan uzun sürer. Gönderdikten sonra, hstspreload.org yeni bir girdinin kararlı Chrome’a ulaşmasının birkaç ay alabileceğini söyler; yani preload, bir yayın tarihi için asla hızlı çözüm değildir.

6. HSTS başlığınızı nasıl kontrol edersiniz?

Önemli üç yanıtı terminalden kontrol edin:

curl -sS -D - -o /dev/null http://example.com/
curl -sS -D - -o /dev/null https://example.com/
curl -sS -D - -o /dev/null https://www.example.com/

İlki Location: https://example.com/ ile 301 veya 308 döndürmelidir; HSTS başlığı gerekmez, çünkü tarayıcılar düz HTTP üzerinden gelen HSTS’yi yok sayar. İkincisi, kendisi www’ye yönlendirme olsa bile üç yönergenin tamamını içeren strict-transport-security taşımalıdır. Üçüncüsü de başlığı göndermelidir; çünkü yalnızca www’yi açan bir ziyaretçi ana alan adının politikasını hiç almaz. Windows’ta curl.exe çağırın ve -o NUL kullanın.

Şu hatalara dikkat edin:

• İki HSTS başlığı. CDN ve kaynak sunucu ikisi de ekliyorsa RFC 6797 tarayıcılara yalnızca ilkini işlemelerini söyler ve hstspreload.org denetimi “Multiple HSTS headers” ifadesini hata olarak bildirir. Başlığın hangi katmana ait olduğuna karar verin.
• Yanlış yazılmış yönerge. Tarayıcılar tanımadıkları yönergeleri uyarı vermeden atar; bu yüzden sonunda s olmayan includeSubdomain, alt alan adlarını sessizce kapsam dışı bırakır.
• Bazı yanıtlarda eksik olması. Ana sayfada başlık vardır, ancak hata sayfalarında, API’de veya başka bir katmanın sunduğu statik dosyalarda yoktur.

Chrome DevTools’ta Network panelini açın, ardından tarayıcı politikayı sakladıktan sonra adres çubuğuna http://example.com/ yazın. İlk girdi, Non-Authoritative-Reason: HSTS ile 307 Internal Redirect gösterir: tarayıcı, sunucuya herhangi bir istek ulaşmadan kendiliğinden HTTPS’e geçmiştir. MDN başvurusu başlık sözdizimini listeler.

7. Preload listesi durumunuzu nasıl kontrol edersiniz?

• hstspreload.org. Alan adını forma girin. Alan adının preload edilmiş mi, beklemede mi yoksa listede değil mi olduğunu, güncel gereksinimlere göre hata ve uyarılarla birlikte gösterir. Beklemedeki bir alan adı henüz korunmaz: hâlâ bir tarayıcı sürümüyle yayımlanması gerekir.
• chrome://net-internals/#hsts. Chrome’da alan adını “Query HSTS/PKP domain” altına girin. static_ ile başlayan alanlar o tarayıcı sürümüne gömülü listeden, dynamic_ ile başlayanlar tarayıcının aldığı başlıklardan gelir. “Delete domain security policies” yalnızca dinamik kısmı temizler; preload edilmiş girdi, bir tarayıcı güncellemesi onu kaldırana kadar durur.
• Diğer tarayıcılar. Firefox, Safari ve Edge, Chrome’un listesinden türetilmiş kendi kopyalarını kendi takvimleriyle yayımlar; bu yüzden bir ekleme veya kaldırma onlara farklı zamanlarda ulaşabilir.

DNS, CDN veya sertifikalarınızda değişiklik yaptıktan sonra kontrolü yineleyin. hstspreload.org, gereksinimleri karşılamayan alan adlarının gelecekte otomatik olarak kaldırılabileceğini belirtir.

8. Listeden çıkmak: kaldırma adımları ve süre

1. Ana alan adında geçerli sertifikayla HTTPS sunmaya devam edin; kaldırma formu bunu denetler.
2. preload içermeyen bir HSTS başlığı gönderin. hstspreload.org bu başlığı kaldırma talebi sayar. HSTS’yi hâlâ istiyorsanız includeSubDomains ve uzun bir max-age tutun; HSTS’yi tümüyle kapatmak için max-age=0 gönderin.
3. Alan adını kaldırma formundan gönderin.
4. Beklerken kararı zorunlu kılan alt alan adına geçerli bir sertifika verin veya onu başka bir alan adına taşıyın: kaldırmanın çoğu Chrome kullanıcısına ulaşması 6 ila 12 hafta, diğer tarayıcılara ulaşması daha uzun sürebilir.
5. Yeniden eklenmek istemiyorsanız preload değerini bir daha göndermeyin.

max-age=0 yalnızca HTTPS üzerinden ve yalnızca geri dönüp onu alan ziyaretçiler için işe yarar. En yavaş yola göre planlayın: gömülü girdiyi hâlâ taşıyan güncel olmayan bir tarayıcı ya da saklanmış iki yıllık bir politika, siz yön değiştirdikten çok sonra bile HTTPS’i zorlamaya devam edebilir.

9. Ücretsiz Yayına Hazırlık Snapshot’ı neyi gösterir?

Ücretsiz Yayına Hazırlık Snapshot’ı, kayıt gerektirmeden tek bir herkese açık alan adında sekiz pasif kontrol çalıştırır ve her kontrolün sonucuyla birlikte bir puan döndürür. Bunlardan ikisi HSTS’ye bakar:

• HTTP güvenlik başlıkları kontrolü, girdiğiniz alan adının ana sayfasını en fazla beş yönlendirmeden sonra okur. HTTPS hedefte eksik Strict-Transport-Security başlığını orta olarak derecelendirir ve gözlemlediği değeri gösterir.
• HTTPS yönlendirme kontrolü, yalın alan adı veya https:// adresi girdiğinizde 180 günün (15.552.000 saniye) altındaki bir max-age değerini düşük olarak işaretler. Planın 1 ila 3. aşamalarında bu sonuç beklenendir.

includeSubDomains yönergesini, preload yönergesini, alt alan adlarınızı veya liste durumunuzu denetlemez; bunlar için hstspreload.org’u ve yukarıdaki curl komutlarını kullanın. Başlık sonucunu önce açmak için aynı snapshot’ı çalıştıran ücretsiz güvenlik başlıkları kontrolünü kullanın. Sertifika tarafı için TLS sertifikaları ve HSTS rehberini okuyun; web sitesi yayın kontrol listesi ise HSTS’yi yönlendirmeler, DNS ve diğer yayın öncesi kontrollerle yan yana koyar.