Kendinizi dışarıda bırakmadan HSTS nasıl kurulur

HSTS basittir; ta ki basit olmayana kadar

Genellikle HSTS olarak kısaltılan HTTP Strict Transport Security, tarayıcılara şunu söyler: “bu site için her zaman HTTPS kullan.” Bir tarayıcı bu başlığı geçerli bir HTTPS bağlantısı üzerinden aldıktan sonra, belirttiğiniz süre boyunca kuralı hatırlar.

Bu faydalıdır. Protokol düşürme saldırılarını önler, yanlışlıkla yapılan güvensiz istekleri azaltır ve bir kullanıcının example.com yazıp yönlendirilmeden önce kısa bir süre düz HTTP’ye temas ettiği o garip anı ortadan kaldırır.

Aynı zamanda kalıcıdır. Yanlış HSTS politikasını yayımlarsanız, başlığı sunucunuzdan kaldırdıktan çok sonra bile tarayıcılar bunu uygulamaya devam edebilir. Ekiplerin kendilerini dışarıda bırakması böyle olur: tam olarak kendi yönetim panellerinden değil, kullanıcıların tarayıcılarından, alt alan adlarından, staging sistemlerinden, eski uç noktalardan ve zorunlu HTTPS’ye hazır olmayan unutulmuş servislerden.

Amaç HSTS’den kaçınmak değildir. Amaç onu bir anahtar gibi değil, bir geçiş süreci gibi dağıtmaktır.

HSTS başlığı gerçekte ne yapar

Tipik bir HSTS başlığı şöyle görünür:

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

Üç önemli bölümü vardır:

• max-age: tarayıcının bu host için HTTPS’yi kaç saniye boyunca zorunlu kılacağı.
• includeSubDomains: kuralın tüm alt alan adlarına da uygulanıp uygulanmayacağı.
• preload: alan adının tarayıcı preload listelerine eklenmesini istediğinizi belirten bir sinyal.

Tarayıcı bu başlığa yalnızca geçerli HTTPS üzerinden aldığında güvenir. Sertifika geçersizse, süresi dolmuşsa veya eşleşmiyorsa, tarayıcı bu yanıttan yeni bir HSTS politikasını kabul etmemelidir.

Politika saklandıktan sonra, gelecekte http://example.com adresini ziyaret etme girişimleri, istek gönderilmeden önce tarayıcı tarafından https://example.com adresine yükseltilir. Gizlilik kazancı budur: güvensiz istek cihazdan hiç çıkmaz.

Kaçınılması gereken kilitlenme senaryoları

Çoğu HSTS hatası ana web sitesinden kaynaklanmaz. Kenarlarda ortaya çıkar.

1. Unutulmuş bir alt alan adı HTTPS’ye hazır değildir

includeSubDomains düzenli görünür, ancak mutlaktır. Bunu example.com üzerinde ayarlarsanız, şunlara uygulanır:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• bu alan adının altındaki diğer her şey

Bu host’lardan herhangi biri geçerli HTTPS sunamıyorsa, HSTS politikasını önbelleğe almış kullanıcılar onlara HTTP üzerinden ulaşamaz.

2. Bir sertifikanın süresi dolar

HSTS olmadan kullanıcılar bazen sertifika uyarılarını geçer. Bu iyi bir güvenlik uygulaması değildir, ama olur.

HSTS ile modern tarayıcılar bu host için sertifika hatalarının kolayca aşılmasına izin vermez. Zaten amaç budur. Bu aynı zamanda sertifika yenilemenin sıradan, izlenen ve test edilen bir süreç olması gerektiği anlamına gelir.

3. Staging veya dahili araçlar production alan adının altında yaşar

Dahili araçları *.example.com altında tutmak, üst alan adı includeSubDomains kullandığında acı verici hale gelebilir. Bu araçlar self-signed sertifikalar, özel sertifika otoriteleri, eski TLS yapılandırmaları kullanıyorsa veya hiç HTTPS kullanmıyorsa, HSTS bu kestirmeyi görünür kılar.

Bu, birçok ekibin dahili ve deneysel sistemleri kendi güvenlik politikasına sahip ayrı bir alan adı altında tutmasının nedenlerinden biridir.

4. Preload sıradan bir onay kutusu gibi ele alınır

HSTS preload sadece başka bir yönerge değildir. Alan adınızın, herhangi bir kullanıcı sitenizi ziyaret etmeden önce tarayıcıların içine yalnızca HTTPS olarak gönderilebileceği anlamına gelir.

Bu, “ilk ziyaret” boşluğunu kapatır, ancak geri almak çok daha zordur. Preload listelerinden kaldırmanın kullanıcılara ulaşması, tarayıcı yayın döngülerine bağlı olarak haftalar veya aylar sürebilir. Preload istikrarlı, olgun alan adları için uygundur. Alt alan adı envanterini hâlâ keşfeden bir site için uygun değildir.

Güvenli bir yayına alma planı

Step 1: Kontrolünüzdeki her hostname’i denetleyin

includeSubDomains ayarlamadan önce, alan adının altındaki her hostname’i listeleyin. DNS kayıtları bir başlangıçtır, ama hikâyenin tamamı değildir. CDN yapılandırmalarını, hosting panellerini, e-posta ile ilişkili hostname’leri, eski pazarlama araçlarını, storage bucket’larını ve dahili dokümantasyonu kontrol edin.

Her hostname için şu soruları yanıtlayın:

• HTTP, HTTPS veya ikisini birden sunuyor mu?
• HTTPS sertifikası geçerli mi ve otomatik olarak yenileniyor mu?
• HTTP’yi temiz biçimde HTTPS’ye yönlendiriyor mu?
• Herkese açık olması mı gerekiyor?
• Hâlâ gerekli mi?

Ekibinizde production başlıklarını hata ayıklama alışkanlıkları zaten varsa, bu çalışma redirect ve header kontrollerinin yanına doğal biçimde oturur. Bu iş akışını production’da redirect ve HTTP header’larını hata ayıklamak için küçük bir araç seti içinde ele almıştık.

Step 2: HSTS eklemeden önce HTTPS’yi düzeltin

HSTS bozuk bir HTTPS kurulumunu güvenli hale getirmez. Yalnızca HTTPS’yi zorunlu kılar.

Etkinleştirmeden önce şunları doğrulayın:

• TLS sertifikaları doğru hostname’leri kapsıyor.
• Sertifikalar otomatik olarak yenileniyor.
• HTTP, mümkün olduğunda tek ve temiz bir sıçramayla HTTPS’ye yönleniyor.
• Canonical host yönlendirmeleri tutarlı; örneğin www olmayan adresten www adresine veya tersi.
• Uygulama varlıkları güvensiz http:// URL’lerine bağlı değil.

Mixed content eskisi kadar yaygın değil, ancak hâlâ eski CMS temalarında, analytics snippet’larında, gömülü medyada ve hard-coded görsel yollarında ortaya çıkar.

Step 3: Çok kısa bir max-age ile başlayın

Bir yıl ile başlamayın. Beş dakika ile başlayın:

Strict-Transport-Security: max-age=300

Bunu yalnızca test ettiğiniz hostname üzerinde dağıtın; genellikle canonical production web sitesi. Şimdilik includeSubDomains eklemeyin.

Ardından gerçek tarayıcılarda ve komut satırı istekleriyle test edin:

curl -I https://example.com

Tam olarak bir adet Strict-Transport-Security başlığı görmelisiniz. Bir app server ve CDN’den gelen yinelenen HSTS başlıkları yaygın bir kafa karışıklığı kaynağıdır. Tarayıcılar genellikle etkili politikayı uygular, ancak bir olayı hata ayıklayan insanların belirsizliğe ihtiyacı yoktur.

Step 4: Kademeli olarak artırın

Hiçbir şey bozulmazsa, süreyi aşamalar halinde artırın:

Strict-Transport-Security: max-age=86400

Sonra:

Strict-Transport-Security: max-age=604800

Sonra belki:

Strict-Transport-Security: max-age=2592000

Pratik bir takvim şudur:

• 5 dakika
• 1 gün
• 1 hafta
• 1 ay
• 6 ay veya 1 yıl

Acele etmenin ödülü yoktur. Aşamalı yayına almanın tüm amacı; izleme sistemlerinize, destek kutunuza ve edge case’lere, kontrol listenizin neleri kaçırdığını söylemeleri için zaman tanımaktır.

Step 5: includeSubDomains’i yalnızca denetim gerçekten tamamlandıktan sonra ekleyin

Herkese açık her alt alan adı HTTPS’ye hazır olduğunda şunu değerlendirebilirsiniz:

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

Bu, temkinli olmanız gereken andır. Eski bir servis hâlâ HTTP’ye ihtiyaç duyuyorsa, üst alan adına includeSubDomains eklemeyin. Ya o servisi taşıyın, ya başka bir alan adına alın ya da HSTS politikanızın şimdilik daha dar kalması gerektiğini kabul edin.

Güvenlik başlıkları gerçeği yansıtmalıdır. Daha sonra sahip olmayı umduğunuz altyapı için motivasyon afişi olarak kullanılmamalıdır.

Step 6: Preload’u ayrı bir proje olarak ele alın

Preload’u yalnızca aşağıdakilerin tümü doğruysa değerlendirin:

• Alan adı ve tüm alt alan adları geçerli HTTPS destekliyor.
• HTTP, HTTPS’ye yönleniyor.
• HSTS başlığı en az 31536000 saniyelik max-age kullanıyor.
• Başlık includeSubDomains içeriyor.
• Başlık preload içeriyor.
• Alan adının altında herhangi bir yerde düz HTTP’ye ihtiyaç duymayacağınızdan eminsiniz.

Preload’a hazır bir başlık şöyle görünür:

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

Preload listesine göndermek uzun vadeli bir taahhüttür. Site bir kampanya microsite’ı, geçici bir ürün alan adı veya sahiplik sınırları belirsiz bir alan adıysa, bunu atlayın.

Yapılandırma örnekleri

Nginx

Başlığın hata yanıtlarında da gönderilmesi için always kullanın:

add_header Strict-Transport-Security "max-age=300" always;

Yayına alma süreci kararlı hale geldikten sonra:

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

Apache

mod_headers etkinleştirildiğinde:

Header always set Strict-Transport-Security "max-age=300"

Daha sonra:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

CDN veya edge platformu

CDN’iniz yanıt başlıklarını ayarlıyorsa, HSTS’yi tek bir yerde yönetmeyi tercih edin. Çok net bir nedeniniz yoksa origin’de bir politika, edge’de başka bir politika ayarlamayın.

Ayrıca CDN’in başlıkları yönlendirmelere, önbelleğe alınmış hatalara ve özel hata sayfalarına uygulayıp uygulamadığını kontrol edin. Bir production sitesi yalnızca 200 OK yanıtından ibaret değildir.

HSTS güvenli biçimde nasıl geri alınır

HSTS’yi devre dışı bırakmanız gerekiyorsa şunu gönderin:

Strict-Transport-Security: max-age=0

Ancak bir püf noktası vardır: tarayıcının bu başlığı almak için siteye geçerli HTTPS üzerinden başarıyla ulaşması gerekir. HTTPS’nin kendisi bozuksa, önbelleğe alınmış HSTS politikası olan kullanıcılar bunu temizleyecek talimatı alamaz.

Bu yüzden olağan kurtarma sırası şöyledir:

1. Geçerli HTTPS’yi geri yükleyin.
2. Strict-Transport-Security: max-age=0 sunun.
3. Geri dönen kullanıcıların bunu almasına yetecek kadar süre yerinde tutun.
4. Olay çözüldükten sonra başlığı kaldırın veya değiştirin.

Alan adı preloaded ise, max-age=0 sunmak yeni tarayıcı profilleri için yeterli değildir. Ayrıca preload listesinden kaldırma talep etmeniz ve bu değişikliğin tarayıcı güncellemeleriyle dağıtılmasını beklemeniz gerekir.

Yayına almadan önce test kontrol listesi

max-age değerini artırmadan veya includeSubDomains eklemeden önce bu kontrol listesini kullanın:

• Canonical HTTPS URL geçerli bir sertifika döndürüyor.
• HTTP, HTTPS’ye yönleniyor.
• Yalnızca bir HSTS başlığı var.
• Başlık, uygun olduğu yerlerde yönlendirmelerde ve hata yanıtlarında görünüyor.
• Tüm herkese açık alt alan adlarında geçerli HTTPS var.
• Sertifika yenileme izleniyor.
• Aynı üst alan adı altında HTTP’ye bağımlı kritik bir dahili sistem yok.
• Preload alışkanlıkla eklenmedi; açıkça tartışıldı.

Lighthouse bazı bağlamlarda eksik veya zayıf güvenlik başlıklarını da işaretleyebilir, ancak tek doğrulama yönteminiz olmamalıdır. Daha geniş bir incelemenin parçası olarak kullanıyorsanız, bulguları hüküm değil sinyal olarak okuyun; aynı yaklaşım paniklemeden bir Lighthouse raporu okurken de geçerlidir.

<!-- tool-cta:start -->

💡 Bunu deneyin: Her HSTS değişikliğinden önce ve sonra, max-age, includeSubDomains ve preload değerlerinin beklediğiniz gibi olduğunu doğrulamak için Strict-Transport-Security yanıtını Get Headers ile inceleyin.

<!-- tool-cta:end -->

HSTS için gizlilik gerekçesi

HSTS genellikle bir güvenlik başlığı olarak çerçevelenir; öyledir de. Ayrıca bir gizlilik faydası vardır: kullanıcının ilk isteğinin güvenilmeyen bir ağda düz HTTP üzerinden sızma olasılığını azaltır.

Bu, havaalanı Wi-Fi ağlarında, otel ağlarında, kurumsal misafir ağlarında ve kullanıcının trafiğinin gözlemlenebileceği veya değiştirilebileceği her yerde önemlidir. Düz bir HTTP isteği hostname’i, path’i, Secure bayrağı olmayan cookie’leri ve diğer istek ayrıntılarını açığa çıkarabilir. HTTPS sihir değildir, ancak onu tutarlı biçimde zorunlu kılmak, önlenebilir sızıntılardan oluşan bütün bir sınıfı ortadan kaldırır.

En iyi HSTS dağıtımları dikkat çekmez. Yavaşça yayına alınır, güvenilir sertifikalarla desteklenir ve kimsenin fark etmeyeceği kadar sıradandır. Hata modu dramatik olabilen bir başlıktan tam olarak istediğiniz şey budur.