HSTS ve HSTS preload listesi

Neden tek başına HTTPS yetmez

Ziyaretçilerin çoğu bir siteye adını yazarak ya da http:// ile başlayan eski bir bağlantıyı izleyerek ulaşır. Sunucu bu isteği HTTPS'e yönlendirir, ama düşman bir ağda o ilk şifresiz istek araya girilerek yakalanabilir. Aradaki saldırgan kurbanı HTTP üzerinde tutup gerçek siteyi kendi üzerinden aktarabilir; SSL stripping adı verilen bu teknik, kullanıcı adres çubuğundaki kilidin eksikliğini fark etmediği sürece sessizce çalışır. Yönlendirmenin kendisi bu boşluğu kapatmaz, çünkü saldırgan yönlendirmeyi kullanıcıya hiç göstermeden düşürebilir.

HTTP Strict Transport Security (RFC 6797) bu boşluğu geri dönen ziyaretçiler için kapatır. Bir tarayıcı geçerli bir HTTPS bağlantısı üzerinden Strict-Transport-Security başlığını bir kez gördükten sonra, o ana bilgisayara giden sonraki her isteği daha ağa çıkmadan, kendi içinde HTTPS'e çevirir. Ayrıca o ana bilgisayar için sertifika hatalarında kullanıcının uyarıyı tıklayıp geçmesine izin vermez. Politika yalnızca başlığı gönderen adı kapsar ve max-age süresi boyunca hatırlanır; başlığı taşıyan her yeni yanıt bu süreyi baştan başlatır.

Başlık

Strict-Transport-Security: max-age=31536000; includeSubDomains

Tarayıcılar başlık düz HTTP üzerinden geldiğinde onu yok sayar, çünkü saldırgan orada kendi başlığını enjekte edebilir. Bu yüzden başlığı yalnızca HTTPS yanıtlarında gönderin ve yönlendirmeler ile hata sayfaları dâhil her yanıta ekleyin; böylece ziyaretçi hangi sayfaya düşerse düşsün politika tazelenir. Direktifleri noktalı virgülle ayırın ve aynı yanıtta başlığı yalnızca bir kez gönderin, çünkü tarayıcılar geçerli olan ilk başlığı kullanıp gerisini yok sayar. Değerin etrafına tırnak koymak da gerekmez; nginx ve Apache örneklerindeki tırnaklar yapılandırma söz dizimine aittir, başlığın kendisine değil.

server {
    listen 443 ssl;
    server_name example.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

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

<VirtualHost *:443>
    ServerName example.com
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</VirtualHost>

HSTS'i güvenle yayına almak

HSTS'in riski başlığın kendisi değil, hafızasıdır. Bir yıllık bir politika yayımlar ve sonra o ana bilgisayarda düz HTTP'ye ihtiyaç duyarsanız ya da sertifikanın süresi dolarsa, başlığı görmüş tarayıcılar politika sona erene kadar bağlanmayı reddeder. Aşamalı bir yayına alma bu sorunları max-age hâlâ kısayken ortaya çıkarır ve geri dönüşü birkaç dakikalık bir işe indirir.

Üçüncü adımdan önce DNS'te var olan bütün alt alan adlarını listeleyin ve her birinin geçerli bir sertifikayla HTTPS üzerinden çalıştığını doğrulayın. DNS Sorgulama aracı ve DNS bölge dışa aktarımınız iyi bir başlangıç noktasıdır; yazıcıları, eski intranet adlarını ve yalnızca şirket içindeki insanların kullandığı hazırlık sunucularını unutmayın. Listeyi yalnızca bölge dosyasından çıkarmak çoğu zaman yetmez: joker kayıtların arkasında duran adlar ve başka ekiplerin kendi panellerinden açtığı alt alan adları orada görünmez.

Her aşamayı alt alan adlarını işleten ekiplere duyurun. Tarihi ve planlanan max-age değerini içeren kısa bir not, onlara yalnızca HTTP ile çalışan bir hizmeti bozulmadan önce HTTPS'e taşıma fırsatı verir. Bu duyuruyu yazılı bir yerde saklamak, aylar sonra bunu kimin ne zaman açtığı sorusunu da ortadan kaldırır.

Başlığın gerçek yanıtlarınızda göründüğünü HTTP Başlık Denetleyicisi ile kontrol edin. Araç max-age değerini gün cinsinden gösterir, includeSubDomains ve preload direktiflerinin var olup olmadığını da söyler. Kontrolü ana sayfanın yanı sıra bir alt sayfada, bir 404 yanıtında ve yönlendirme yapan çıplak alan adında da yineleyin; eksik başlıklar genellikle tam olarak bu üç yerde ortaya çıkar.

includeSubDomains neyi bozabilir

example.com üzerinde ayarlanan includeSubDomains, başka ekiplerin ya da tedarikçilerin sunduğu adlar dâhil altındaki her ada uygulanır. Hâlâ düz HTTP üzerinden erişilmesi gereken her alt alan adı, politikayı almış tarayıcılar için erişilemez hale gelir. Tipik kurbanlar iç araçlar, kendinden imzalı sertifikaya sahip ağ cihazları ve eski pazarlama mikro siteleridir. Bu adların çoğu sizin envanterinizde görünmediği için sorun genellikle yayına aldıktan günler sonra ortaya çıkar.

• Ofis ağı içinde HTTP üzerinden sunulan intranet.example.com gibi iç sunucular.
• Kendinden imzalı sertifikaya sahip cihazlar; çünkü HSTS uyarıyı tıklayıp geçme seçeneğini kaldırır.
• Sertifikasını sizin denetlemediğiniz, tedarikçide barındırılan alt alan adları (yardım merkezleri, durum sayfaları).
• Eski istemcilerin kullandığı alt alan adlarındaki captive portal'lar veya yalnızca HTTP ile çalışan API'ler.

Başlık yalnızca onu gönderen ana bilgisayar ve o adın alt alan adları için geçerlidir. www.example.com tarafından includeSubDomains ile gönderilen bir politika *.www.example.com adlarını kapsar, api.example.com adresini kapsamaz. Alan adının tamamını kapsamak için başlığın example.com adresinin kendisi tarafından gönderilmesi gerekir; bu da kullanıcıların çıplak alan adını en az bir kez ziyaret etmesini ya da alan adının preload listesinde olmasını gerektirir. Çıplak alan adı yalnızca www adresine yönlendirme yapıyor olsa bile, o yönlendirme yanıtının başlığı taşıması bu yüzden önemlidir.

Preload listesi

HSTS bir tarayıcıyı ancak ilk başarılı HTTPS ziyaretinden sonra korur. Preload listesi bu ilk ziyaret boşluğunu ortadan kaldırır: Chromium'un içine derlenen ve Firefox, Safari ile Edge tarafından da kullanılan bu liste, üzerindeki alan adlarını en baştan HSTS kapsamındaymış gibi ele alır. Alan adları hstspreload.org üzerinden gönderilir; site gereksinimleri otomatik olarak kontrol eder ve eksik varsa başvuruyu kabul etmez. Kabul edilen bir alan adının kullanıcılara ulaşması yine de haftalar alır, çünkü liste ancak yeni tarayıcı sürümleriyle birlikte dağıtılır.

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

Bazı üst seviye alan adları bütünüyle preload listesindedir; bu yüzden altlarında kayıtlı her alan adı tarayıcılarda daha ilk ziyaretten itibaren HTTPS ister. Böyle bir TLD kullanıyorsanız HSTS davranışı sizin başlığınızdan bağımsız olarak zaten yürürlüktedir ve düz HTTP ile çalışan alt alan adları hiç açılmaz. Bu durumda başlığı yine de gönderin: kendi politikanız, TLD kuralını uygulamayan eski tarayıcıları da kapsar.

HSTS ile uyumlu yönlendirmeler

Temiz bir yönlendirme zinciri hem HSTS hem de preload için önemlidir. Önerilen sıra şudur: http://example.com → https://example.com (çıplak alan adı için HSTS'i ayarlar) → www kullanıyorsanız https://www.example.com. http://example.com adresinden doğrudan https://www.example.com adresine yönlendirmek, çıplak alan adının HTTPS yanıtını atlar; dolayısıyla o ad kendi politikasını hiçbir zaman göndermez.

http://example.com/        301 → https://example.com/
https://example.com/       301 → https://www.example.com/   (with Strict-Transport-Security)
http://www.example.com/    301 → https://www.example.com/
https://www.example.com/   200                               (with Strict-Transport-Security)

Yönlendirme Denetleyicisi zinciri http:// adresinden başlayarak izler ve her adımı listeler; böylece ilk adımın aynı ana bilgisayarda kaldığını doğrulamak kolaylaşır. Her adımda başlığın da göründüğünü kontrol edin; yönlendirme yanıtlarına başlık eklemeyi unutmak, preload başvurularının en sık reddedilme nedenlerinden biridir. Yönlendirme rehberi döngüleri ve gereksiz adımları ayrıntılı anlatır.

Sık yapılan hatalar

Son satır CDN ve ters proxy arkasında sık görülür: uygulama bir değer gönderir, kenar sunucusu başka bir değer ekler. Güvenlik başlıklarının hangi katmana ait olduğuna karar verin, diğerini kaldırın ve nihai yanıtı dışarıdan HTTP Başlık Denetleyicisi ile doğrulayın. Kararı altyapı deposunda kısa bir notla belgeleyin; aksi halde aynı çift başlık, bir sonraki CDN yapılandırmasında geri gelir.

HSTS ve ilgili mekanizmalar

Tarayıcıları HTTPS'e yönelten başka ve daha yeni özellikler de var; bunların HSTS ile ilişkisini bilmek işinizi kolaylaştırır. Hiçbiri sizin yönettiğiniz bir sitede HSTS'in yerini tutmaz, ama HSTS kullanmayan sitelerde ziyaretçilerin gördüğü davranışı değiştirirler. Aralarındaki en önemli fark kimin karar verdiğidir: bazılarını siz ayarlarsınız, bazıları ise kullanıcının tarayıcı tercihine bağlıdır ve sizin denetiminizde hiç değildir.

HSTS, sertifika hatalarını atlanamaz hale getiren ve geri dönen ziyaretçileri onu uygulayan her tarayıcıda koruyan, sizin denetiminizdeki mekanizma olmayı sürdürüyor. Diğerleri yararlı eklerdir; özellikle upgrade-insecure-requests, eski içeriği temizlerken HSTS ile iyi bir ikili oluşturur.

HSTS ile yaşamak

HSTS, sertifika sorunlarını kesintiye dönüştürür. Yenilemeyi otomatikleştirin, süre bitimini ayrıca izleyin ve yenilemeleri hazırlık sunucularında test edin. HSTS kullanmayan bir sitede süresi dolmuş sertifika yalnızca bir uyarı gösterir; HSTS kullanan bir sitede ziyaretçiler siteye hiç giremez.

• Politikanın kapsadığı her ana bilgisayarın, alt alan adları dâhil, sertifika süresini izleyin.
• Yeni alt alan adlarını yalnızca ilk günden HTTPS ile açın.
• Başlığı, CDN kenar yanıtları dâhil her HTTPS yanıtında tutun.
• Alan adının HSTS kullandığını veya preload listesinde olduğunu belgeleyin; böylece gelecekteki ekipler onun üzerinde yalnızca HTTP ile çalışan hizmetler planlamaz.
• HSTS'i diğer güvenlik başlıklarıyla birlikte kullanın; en karmaşığını CSP rehberi anlatıyor.

Büyük kurumların çoğu zaman çok sayıda alan adı vardır ve HSTS kararları alan adından alan adına değişir. Tek bir web uygulaması barındıran bir ürün alan adı, uzun bir max-age ve preload için kolay bir adaydır; onlarca iç alt alan adı taşıyan bir kurumsal alan adı ise yalnızca belirli ana bilgisayarlarda ve includeSubDomains olmadan HSTS'e hazır olabilir. Kararı ve gerekçesini alan adı bazında kayda geçirin ki bir sonraki ekip neyin güvenli olduğunu bilsin.

Bir alan adını satın aldığınızda ya da devraldığınızda, üzerinde hizmet planlamadan önce preload listesinde olup olmadığına ve HSTS gönderip göndermediğine bakın. HTTP Başlık Denetleyicisi mevcut başlığı gösterir, preload sitesi de alan adının listedeki durumunu gösterir. Alt alan adlarından birinde yalnızca HTTP ile çalışan bir hizmeti kurduktan sonra alan adının preload listesinde olduğunu keşfetmek, önlenebilir bir sürprizdir.

Geri adım atmanız gerekirse HTTPS üzerinden max-age=0 gönderin. Bunu alan tarayıcılar o ana bilgisayar için politikayı unutur. Kayıtlı max-age süresi dolmadan geri gelmeyen ziyaretçiler ise o ana kadar eski politikayı taşımayı sürdürür; bu da max-age değerini kademeli artırmanın bir başka gerekçesidir.

SSS

Kaynaklar

• RFC 6797: HTTP Strict Transport Security (HSTS)
• HSTS preload listesi: başvuru ve gereksinimler
• MDN: Strict-Transport-Security
• nginx belgeleri: add_header