HSTS (HTTP Strict Transport Security) Nasıl Kurulur

HSTS ne yapar ve neden önemlidir

HTTP Strict Transport Security (HSTS), RFC 6797’de tanımlanan bir güvenlik politikasıdır. Web sitesi bunu HTTPS üzerinden bir yanıt başlığı olarak gönderir ve tarayıcı bu bilgiyi hatırlar. Sitenin belirttiği süre boyunca tarayıcı, istek göndermeden önce her http:// bağlantısını otomatik olarak https:// olarak yeniden yazar ve kullanıcının o sunucu için sertifika hatalarını geçmesine izin vermez.

HSTS olmadan, adres çubuğuna example.com yazan bir ziyaretçi genellikle ilk isteği düz HTTP üzerinden yapar, ardından HTTPS’e yönlendirilir. Şifrelenmemiş bu ilk istek, kötü niyetli bir Wi-Fi erişim noktası gibi aynı ağdaki bir saldırgana bağlantıyı yakalayıp kullanıcıyı HTTP’de tutma fırsatı verir (bu teknik çoğu zaman SSL stripping olarak adlandırılır). HSTS, tarayıcı başlığı bir kez gördükten sonraki her ziyaret için bu açığı kapatır; preload listesi ise ilk ziyaret için bile kapatır.

HSTS, HTTPS’in yerine geçmez. Doğru yapılandırılmış bir TLS kurulumunun üzerine eklenen ve tarayıcılara asla geri düşmemelerini söyleyen bir katmandır.

Başlık söz dizimi

Başlığın bir zorunlu ve iki isteğe bağlı yönergesi vardır:

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

Gözden kaçması kolay birkaç kural vardır:

• Tarayıcılar, düz HTTP üzerinden gelen başlığı yok sayar. Başlık yalnızca geçerli bir HTTPS bağlantısıyla iletildiğinde dikkate alınır.
• Tarayıcı başlığı her aldığında geri sayım yeniden başlar; düzenli ziyaret edilen bir site böylece fiilen süresiz korunur.
• Yalnızca bir Strict-Transport-Security başlığı gönderin. Çoğu zaman hem uygulamada hem web sunucusunda ayarlanmasından kaynaklanan yinelenen başlıklar, politikanın yok sayılmasına yol açabilir.

Etkinleştirmeden önceki ön koşullar

HSTS, HTTP’ye geri dönme seçeneğini ortadan kaldırdığı için dikkatli hazırlanın. Önce bu kontrol listesini tamamlayın:

1. Her yerde geçerli sertifikalar. Kapsama girecek her ana bilgisayar adı, adla eşleşen, güvenilir ve süresi dolmamış bir sertifika sunmalıdır.
2. Çalışan bir HTTP’den HTTPS’e yönlendirme. 80 numaralı porttaki istekler, aynı URL’nin HTTPS sürümüne 301 döndürmelidir.
3. Karışık içerik olmaması. Betikler, görseller, yazı tipleri ve API çağrıları HTTPS üzerinden yüklenmelidir. HSTS kendi sunucunuza giden bağlantıları yükseltir, ancak HTTP üzerindeki üçüncü taraf kaynaklar yine engellenir veya işaretlenir.
4. Bir alt alan adı envanteri. Eski test sunucuları, webmail portalları, iç araçlar ve CNAME ile tedarikçide barındırılan sayfalar dahil DNS bölgenizdeki her alt alan adını listeleyin. Bunlardan HTTPS kullanamayan herhangi biri includeSubDomains eklediğiniz anda bozulur.
5. Güvendiğiniz bir sertifika yenileme süreci. Otomatik yenileme (örneğin ACME ile) ve buna ek olarak bağımsız süre takibi.

Envanter ve izleme adımları için bir yenileme takipçisi işinizi kolaylaştırır: her sertifikayı ve alan adını TLDix alan adı takibine kaydedip herhangi bir şeyin süresi dolmadan çok önce uyarı alabilirsiniz.

Güvenli ve kademeli geçiş

En büyük HSTS hatası, doğrudan includeSubDomains içeren bir yıllık bir politikaya atlamaktır. Bir şey bozulursa, başlığı zaten almış ziyaretçiler max-age dolana kadar HTTPS’e kilitli kalır ve bunu tarayıcılarından geri çağıramazsınız. Kademeli bir yaklaşım hasarın etki alanını sınırlar:

Süreler kural değil, yol göstericidir. Bir sonraki aşamaya ancak günlükleri ve kullanıcı bildirimlerini çalışmayı bırakan bir şey olup olmadığına dair inceledikten sonra geçin.

Her aşamada neye bakmalı

Her aşamanın sonunda kısa bir değerlendirme yapın. Web sunucusu ve CDN günlüklerinde artan bağlantı hatalarını, destek kanallarında “siteye giremiyorum” şikâyetlerini ve iç ekiplerin kullandığı araçlardaki erişim sorunlarını kontrol edin. Özellikle includeSubDomains aşamasında, nadiren kullanılan ve yalnızca belirli dönemlerde açılan hizmetler (raporlama panelleri, yıllık kampanya sayfaları gibi) gözden kaçabilir. Bu tür hizmetlerin sahiplerine önceden haber vermek, sorunları erkenden duymanızı sağlar.

Yaygın sunucularda HSTS yapılandırması

Nginx

Başlığı HTTPS server bloğunun içine ekleyin. always parametresi, Nginx’in başlığı hata yanıtlarında da göndermesini sağlar.

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    # ssl_certificate ve diğer yönergeler burada
}

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

Nginx’te iç içe bir location bloğundaki add_header yönergesinin, server seviyesinden devralınan başlıkların yerini aldığını unutmayın; gerekli yerlerde tekrarlayın veya bir include dosyası kullanın.

Apache

mod_headers modülünü etkinleştirin ve yönergeyi SSL sanal sunucusuna ekleyin:

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

<VirtualHost *:80>
    ServerName example.com
    Redirect permanent / https://example.com/
</VirtualHost>

CDN’ler ve uygulama çatıları

Birçok CDN ve ters proxy, panelinde bir HSTS anahtarı sunar; web çatılarının çoğunda da bunun için ara katman (middleware) bulunur. Başlığı ayarlamak için tek bir yer seçin. Hem CDN hem de ana sunucunuz başlığı eklerse, yinelenen veya çelişen değerlerle karşılaşabilirsiniz.

HSTS preload listesi

Büyük tarayıcılar, ilk istekten itibaren yalnızca HTTPS kullanılan alan adlarından oluşan yerleşik bir listeyle gelir. Bu listede yer almak, ilk kullanımda güven (trust-on-first-use) açığını ortadan kaldırır. Liste hstspreload.org adresindeki başvuru sitesi üzerinden yönetilir ve gereksinimleri (güncel sürüm için siteyi kontrol edin) genellikle şunları içerir:

• Geçerli bir sertifika ve aynı sunucuda HTTP’den HTTPS’e yönlendirme.
• Tüm alt alan adlarının HTTPS üzerinden sunulması.
• Ana alan adında uzun bir max-age (bu yazının yazıldığı tarihte en az bir yıl), includeSubDomains ve preload içeren başlık.

Preload uzun vadeli bir taahhüttür. Listeden çıkmak mümkündür, ancak değişiklik kullanıcılara ancak tarayıcı güncellemeleriyle ulaşır ve bu aylar sürebilir. Bazı TLD’ler bütünüyle preload listesindedir; yani altlarındaki her alan adı, destekleyen tarayıcılarda varsayılan olarak yalnızca HTTPS ile çalışır. Yeni bir ad seçiyorsanız seçenekleri alan adı arama aracıyla inceleyip bunu da hesaba katabilirsiniz.

HSTS ve ilgili güvenlik başlıkları

HSTS çoğu zaman diğer yanıt başlıklarıyla birlikte kullanılır ve aralarındaki farkı anlamak faydalıdır. upgrade-insecure-requests yönergesine sahip Content-Security-Policy, tarayıcılara sayfalarınızdaki alt kaynakları HTTPS üzerinden almalarını söyler; eski içerik hâlâ üçüncü taraflara HTTP bağlantıları barındırıyorsa bu, HSTS’i tamamlar. HSTS ise tarayıcının doğrudan sizin sunucunuza nasıl bağlandığını yönetir. Biri diğerinin yerini tutmaz ve olgun sitelerde ikisinin birlikte ayarlanması yaygındır. Bir yapılandırma yeniden oluşturulduğunda birkaç başlık birden kaybolabileceği için CDN’inizi veya ters proxy’nizi her değiştirdiğinizde bunları birlikte gözden geçirin.

Politikanızı test etmek ve doğrulamak

Başlığı komut satırından doğrulayın:

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

Ardından yalnızca varlığını değil, davranışı da kontrol edin:

• http://example.com adresini isteyin ve 301 ile HTTPS’e yönlendirildiğini doğrulayın.
• Chromium tabanlı tarayıcılarda dahili net-internals/#hsts sayfası, bir alan adı için kayıtlı politika olup olmadığını sorgulamanızı ve test sırasında silmenizi sağlar.
• includeSubDomains eklemeden önce, nadiren kullanılanlar dahil her alt alan adını HTTPS üzerinden test edin.
• Yapılandırma yeniden oluşturulduğunda başlıklar sık sık kaybolduğu için dağıtımlardan, CDN değişikliklerinden veya sunucu taşımalarından sonra yeniden test edin.

Yaygın hatalar ve bunlardan kaçınma

• Unutulan alt alan adları. Sertifikası olmayan eski bir intranet sunucusu veya CNAME üzerindeki bir tedarikçi sayfası, includeSubDomains devreye girdiğinde çalışmaz. Önce DNS’i denetleyin.
• Sertifika süresinin dolması. HSTS etkinken, sertifika geçersiz olduğunda tarayıcılar erişimi tamamen engeller. Süresi dolmuş bir sertifika, uyarıdan tam bir kesintiye dönüşür. Son kullanma tarihlerini yenileme otomasyonunuzdan bağımsız olarak izleyin.
• Başlığı HTTP yanıtlarında göndermek. Orada yok sayılır; koruma sağlamaz ve denetimlerde kafa karıştırabilir.
• Geliştirme alan adları. HTTPS desteklemedikleri sürece, üretimle aynı üst alan adını paylaşan yerel veya test sunucularından HSTS göndermekten kaçının.
• Geri almak. Bir politikayı geri çekmek için HTTPS üzerinden max-age=0 gönderin. Bunu gören tarayıcılar kuralı unutur, ancak siteyi bir daha ziyaret etmeyenler süre dolana kadar kuralı korur.

HSTS, daha kapsamlı bir sıkılaştırma planının parçası olduğunda en iyi sonucu verir. Hangi otoritelerin sertifika düzenleyebileceğini kontrol etmek için CAA kayıtlarıyla birlikte kullanın, hesap ve DNS tarafı için de daha geniş kapsamlı alan adı güvenliği en iyi uygulamalarını inceleyin.

HSTS’i zaman içinde sağlıklı tutmak

Bir kez devreye alındıktan sonra, HTTPS sağlıklı kaldığı sürece HSTS çok az ilgi gerektirir. Operasyonlarınıza birkaç alışkanlık ekleyin: alt alan adı envanterini güncel tutun, başlık kontrolünü dağıtım testlerine dahil edin ve her sertifikanın ve alan adının yenileme tarihini takip edin. Eski mülkleri denetlerken bir sitenin nerede barındırıldığını hosting sorgulama aracıyla bulup ayrıntıları doğrulayabilirsiniz. Politika, altındaki sertifikalar ve alan adı kayıtları kadar güvenilirdir; bu yüzden yenilemeleri aynı güvenlik kontrolünün bir parçası olarak ele alın.

Ekip içinde sorumluluğu netleştirin

HSTS ayarı çoğu zaman bir kez yapılıp unutulur ve yıllar sonra kimin sorumlu olduğu belirsizleşir. Başlığın nerede ayarlandığını (CDN, web sunucusu veya uygulama), mevcut max-age değerini, preload başvurusu yapılıp yapılmadığını ve sertifika yenilemelerinden kimin sorumlu olduğunu kısa bir iç belgeye yazın. Ekip değiştiğinde veya altyapı taşındığında bu belge, politikanın sessizce kaybolmasını ya da yanlışlıkla bozulmasını önler.