Sitenize geçerli bir SSL sertifikası kurdunuz, HTTP'den HTTPS'e yönlendirme yaptınız ve adres çubuğunda kilit simgesini gördünüz. Çoğu site sahibi işi burada bitmiş sayar. Oysa bu kurulumda hâlâ ince bir açık vardır: kullanıcı adres çubuğuna sadece siteadi.com yazdığında veya bir bağlantıya tıkladığında, tarayıcının kurduğu ilk bağlantı çoğu zaman şifresiz http:// üzerinden başlar. Sunucunuz "sen HTTPS'e geç" diye bir yönlendirme (301) döndürene kadar geçen o birkaç yüz milisaniyelik pencere, aradaki bir saldırganın trafiği ele geçirmesi için yeterlidir. İşte HSTS tam olarak bu boşluğu kapatmak için tasarlanmış bir mekanizmadır.
HSTS, açılımıyla HTTP Strict Transport Security, sunucunun tarayıcıya gönderdiği tek satırlık bir HTTP başlığıdır. Bu başlığı bir kez alan tarayıcı, belirlenen süre boyunca o alan adına yalnızca HTTPS ile bağlanmayı bir kural olarak hafızasına yazar. Kullanıcı http:// yazsa bile tarayıcı istek sunucuya gitmeden, kendi içinde bunu https:// olarak yeniden yazar. Yani şifreleme kararını artık sunucunun yönlendirmesine bırakmaz; tarayıcının kendisi zorunlu kılar. Bu yazıda HSTS'in hangi saldırıları engellediğini, max-age, includeSubDomains ve preload parametrelerinin ne işe yaradığını, preload listesine girmenin neden geri dönüşü zor bir karar olduğunu ve tüm bunları hatasız devreye almak için izlenmesi gereken test sürecini anlatacağız.
HTTPS'in İlk İstek Açığı ve SSL Stripping#
Standart bir HTTP'den HTTPS'e yönlendirme şöyle çalışır: kullanıcı http://siteadi.com adresine gider, sunucu 301 Moved Permanently ve Location: https://siteadi.com yanıtını döner, tarayıcı yeni adrese güvenli bağlantı kurar. Bu akış çalışır ama kritik bir varsayıma dayanır: o ilk şifresiz isteğin bozulmadan sunucuya ulaşacağına ve dönen yönlendirmenin bozulmadan tarayıcıya geleceğine güvenir.
Ortadaki adam (man-in-the-middle) konumundaki bir saldırgan bu güveni kırar. Halka açık bir kafenin WiFi'ında, kötü niyetli bir modem/router'da veya ele geçirilmiş bir ağ ekipmanında saldırgan, o şifresiz ilk isteği yakalar. Sunucudan gelen https:// yönlendirmesini siler veya değiştirir; kullanıcıyla kendi arasında sitenin şifresiz bir kopyasını sunar, kendisiyle gerçek sunucu arasında ise HTTPS konuşur. Kullanıcı hiçbir şeyin farkında olmadan siteyi kullanmaya devam eder; ama arada geçen tüm parolalar, oturum çerezleri ve form verileri saldırgana açık gider. Bu tekniğe SSL stripping (SSL soyma) denir ve 2009'da Moxie Marlinspike'ın sslstrip aracıyla popülerleştiği günden beri en yaygın downgrade saldırısıdır.
Buradaki temel sorun şudur: yönlendirmenin kendisi şifresiz kanaldan geldiği için güvenilmezdir. Tarayıcı, sunucunun "HTTPS'e geç" demesini beklerken, o mesajı taşıyan kanal zaten saldırganın kontrolündedir. HSTS bu döngüyü kırar çünkü kuralı tarayıcının belleğine yazar; tarayıcı bir sonraki sefer sunucuya hiç sormadan doğrudan HTTPS ister ve saldırganın araya sıkışacağı o şifresiz ilk istek hiç oluşmaz. Konuyu daha derinlemesine ele aldığımız HTTPS yönlendirme rehberimizde bu akışın altyapısını da inceleyebilirsiniz.
HSTS Tam Olarak Nasıl Çalışır?#
HSTS'in mantığı "ilk temasta güven, sonrasında zorunlu kıl" (trust on first use) modeline dayanır. Kullanıcı siteye ilk kez HTTPS üzerinden ulaştığında, sunucu yanıtına şu başlığı ekler:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Tarayıcı bu başlığı okur ve şu kaydı kendi HSTS deposuna yazar: "siteadi.com alan adına önümüzdeki 31.536.000 saniye (1 yıl) boyunca yalnızca HTTPS ile bağlan." Bu andan sonra kullanıcı ne yaparsa yapsın, ister adres çubuğuna http:// yazsın, ister başka bir sitedeki http:// bağlantıya tıklasın, tarayıcı isteği ağa çıkmadan önce kendi içinde https:// olarak dönüştürür. Bu işleme internal redirect denir ve 307 Internal Redirect olarak tarayıcının geliştirici araçlarında görünür; ağ üzerinde gerçek bir istek oluşmadığı için araya girilecek bir şifresiz paket de kalmaz.
Bu yaklaşımın bilinen bir zayıflığı vardır: ilk ziyaret. Tarayıcı siteyi hiç görmediyse elinde HSTS kaydı da yoktur, dolayısıyla ilk istek yine şifresiz gidebilir. Bu boşluğu kapatan mekanizma preload listesidir; birazdan detaylandıracağız. Bir diğer önemli davranış ise sertifika hatalarıyla ilgilidir: HSTS aktifken tarayıcı, sertifika uyarılarını "tıkla ve devam et" ile geçilebilir olmaktan çıkarır. Normalde kullanıcı "güvenli değil, yine de devam et" diyebilirken, HSTS'li bir sitede tarayıcı bağlantıyı tamamen reddeder. Bu, güvenlik açısından istenen bir davranıştır ama sertifikanızın süresi biterse veya yanlış sertifika sunarsanız kullanıcıların siteye hiç giremeyeceği anlamına gelir; bu yüzden sertifika yönetiminiz kusursuz olmalıdır. SSL sertifikasının ne olduğunu ve yenileme süreçlerini ayrı bir rehberde ele aldık.
Başlık Parametreleri: max-age, includeSubDomains ve preload#
HSTS başlığı üç parametreyle yapılandırılır. Bunların ne yaptığını doğru anlamak, hem güvenliği sağlamak hem de kendi ayağınıza sıkmamak için kritiktir.
| Parametre | Zorunlu mu? | Ne yapar? | Tipik değer |
|---|---|---|---|
max-age | Evet | Kuralın kaç saniye geçerli olacağını belirler. Her ziyarette yenilenir. | 31536000 (1 yıl) |
includeSubDomains | Hayır | Kuralı tüm alt alan adlarına da uygular (blog., mail., api.) | — |
preload | Hayır | Alan adının tarayıcı preload listesine dahil edilmeye aday olduğunu belirtir | — |
max-age, saniye cinsinden sürenin ne kadar olacağını söyler. Tarayıcı, siteyi her HTTPS ziyaretinde bu sayacı yeniden başlatır; yani düzenli ziyaret edilen bir sitede kural pratik olarak hiç sonlanmaz. Değeri 0 yaparsanız kuralı iptal edersiniz, bu da HSTS'i geri almanın tek yoludur. Test aşamasında kısa bir süreyle (örneğin 300 yani 5 dakika) başlamak, bir sorun çıkarsa kuralın kendini hızla temizlemesini sağlar.
includeSubDomains, tek başına başrol oynayan ama en sık gözden kaçan parametredir. Bunu eklediğinizde kural sadece ana alan adı için değil, siteadi.com altındaki tüm alt alan adları için de geçerli olur. Bu çok güçlüdür ama tehlikelidir: eğer henüz HTTPS'e taşımadığınız bir eski.siteadi.com veya sadece iç ağda çalışan test.siteadi.com gibi bir alt alan adınız varsa, includeSubDomains eklediğiniz anda tarayıcılar bu alt alan adlarına da HTTPS zorlar ve HTTPS desteklemeyen o alt alan adları erişilemez hale gelir. Bu yüzden bu parametreyi eklemeden önce bütün alt alan adlarının HTTPS sunduğundan emin olun.
preload, tek başına teknik bir etki yapmaz; asıl işlevi, alan adınızın Google'ın yönettiği preload listesine başvuru yapabilmesi için bir "onay bayrağı" olmasıdır. Preload listesine kayıt kurallarının gereği olarak başlıkta preload anahtar kelimesi, en az max-age=31536000 değeri ve includeSubDomains birlikte bulunmalıdır. Bu üçü aynı anda olmadan başvurunuz reddedilir. Bir sonraki bölümde bunun neden bu kadar dikkat gerektirdiğini açıklıyoruz.
Preload Listesi ve Geri Dönülmez Riski#
HSTS'in "ilk ziyaret açığı"nı kapatmanın yolu, kuralı tarayıcının siteyi hiç görmeden bilmesini sağlamaktır. Bunu, alan adınızı HSTS preload listesine ekleyerek yaparsınız. Bu liste hstspreload.org üzerinden yönetilir, Chromium'un kaynak koduna gömülüdür ve Chrome, Firefox, Edge, Safari, Opera gibi büyük tarayıcıların hepsi bu listeyi kullanır. Listede yer alan bir alan adına tarayıcı, kullanıcının o siteyi ömründe hiç ziyaret etmemiş olsa bile ilk istekten itibaren yalnızca HTTPS ile bağlanır. Böylece SSL stripping için gereken o "ilk şifresiz istek" penceresi tümden ortadan kalkar.
Kulağa mükemmel geliyor ama burada dikkat edilmesi gereken çok kritik bir nokta var: preload listesine girmek pratik olarak geri dönülmezdir. Listeye eklenmek birkaç hafta sürebilir; ama listeden çıkmak (removal) çok daha uzun sürer ve çıktıktan sonra bile o kural, kullanıcıların tarayıcılarına gömülü tarayıcı sürümleri güncellenene kadar aylarca yaşamaya devam eder. Yani bir gün HTTPS'i kaldırmak zorunda kalırsanız veya HTTPS'te ciddi bir sorun yaşarsanız, "geçici olarak HTTP'ye dönelim" diyemezsiniz; kullanıcıların büyük kısmı sitenize aylarca hiç erişemez. Bu yüzden preload adımı, geri alınması en zor karardır ve ancak HTTPS altyapınızın uzun vadede kalıcı olduğundan tam emin olduğunuzda atılmalıdır.
Preload başvurusu yapmadan önce şu koşulları sağlamanız gerekir:
- Alan adının kök sayfası (
https://siteadi.com) geçerli bir sertifikayla açılmalı. - Tüm HTTP trafiği aynı ana bilgisayarda HTTPS'e yönlendirilmeli (301/308).
- Başlık
max-age'i en az bir yıl (31536000) olmalı,includeSubDomainsvepreloadiçermeli. - Tüm alt alan adları — kullanılıyorsa
wwwdahil — HTTPS destekli olmalı.
Bu koşullar sağlandıktan sonra hstspreload.org üzerinden başvurunuzu yaparsınız. Ama şunu tekrar vurgulamak gerekir: preload, HSTS'in son ve en radikal adımıdır. Önce başlığı devreye alın, haftalarca sorunsuz çalıştığından emin olun, ancak ondan sonra preload'u düşünün.
Web Sunucularında HSTS Yapılandırması#
HSTS'i devreye almak tek bir başlık eklemekten ibarettir; zor olan doğru değerleri ve doğru sırayı seçmektir. Aşağıda yaygın sunucular için örnek yapılandırmaları bulacaksınız. Ortak kural şudur: HSTS başlığını yalnızca HTTPS yanıtlarında gönderin, HTTP yanıtlarında değil. HTTP üzerinden gönderilen HSTS başlığını tarayıcılar zaten yok sayar, dahası HTTP'de gönderilen başlığa güvenmek mantıksızdır.
Nginx için, SSL dinleyen sunucu bloğunuza always bayrağıyla ekleyin (bu bayrak, hata sayfaları dahil tüm yanıtlarda başlığın gönderilmesini garantiler):
server {
listen 443 ssl;
server_name siteadi.com;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# ... SSL sertifika ve diğer ayarlar ...
}
server {
listen 80;
server_name siteadi.com;
return 301 https://$host$request_uri;
}
Apache için, mod_headers etkinken sanal ana bilgisayarın SSL bloğuna ekleyin:
<VirtualHost *:443>
ServerName siteadi.com
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
# ... SSL sertifika ve diğer ayarlar ...
</VirtualHost>
cPanel/WHM kullanıyorsanız, .htaccess dosyasına aynı satırı ekleyebilir veya bazı sürümlerde EasyApache üzerinden yönetebilirsiniz:
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>
Test aşaması için çok daha temkinli bir değerle başlamanızı öneririm. Kısa bir max-age ile başlayıp, her şeyin yolunda gittiğini gördükçe kademeli olarak artırın:
# 1. Aşama: 5 dakika — bir sorun çıkarsa hızla temizlenir
add_header Strict-Transport-Security "max-age=300" always;
# 2. Aşama: 1 gün — birkaç gün gözlemleyin
add_header Strict-Transport-Security "max-age=86400; includeSubDomains" always;
# 3. Aşama: 1 yıl — kalıcı yapılandırma
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
Yapılandırmayı uyguladıktan sonra başlığın gerçekten gittiğini komut satırından doğrulayabilirsiniz:
curl -sI https://siteadi.com | grep -i strict-transport-security
Çıktıda strict-transport-security: max-age=31536000; includeSubDomains satırını görüyorsanız başlık doğru sunuluyor demektir. Sunucu yönetimini kendiniz üstlenmek istemiyorsanız, sunucu yönetimi hizmetimiz kapsamında güvenlik başlıklarının kurulumunu ve yenilenmesini bizim ekibimiz üstlenebilir.
Doğru Test ve Kademeli Devreye Alma Süreci#
HSTS'te acele etmek, kendi sitenizi kendi elinizle erişilemez kılabileceğiniz nadir güvenlik yapılandırmalarından biridir. Bu yüzden süreci mutlaka kademeli yürütmek gerekir. İzlenmesi gereken sağlıklı akış şudur.
İlk olarak, HSTS'i açmadan önce HTTPS altyapınızın tamamen sağlam olduğundan emin olun. Bütün sayfalar HTTPS ile açılmalı, karışık içerik (mixed content) uyarısı olmamalı, tüm HTTP istekleri HTTPS'e yönlendirilmeli ve sertifikanız otomatik yenilenmeli. HSTS, HTTPS'in üzerine konulan bir kilittir; altyapı sağlam değilse kilidi taktığınız anda kapıyı kendinize kapatırsınız.
İkinci olarak, includeSubDomains eklemeden önce tüm alt alan adlarını tek tek gözden geçirin. www, blog, mail, api, panel, cdn gibi kullandığınız her alt alan adının HTTPS sunduğundan emin olun. Sadece iç kullanımda olan, dış dünyaya kapalı ama yine de siteadi.com altında duran bir alt alan adı varsa, includeSubDomains onu da HTTPS'e zorlar ve HTTP-only servisiniz erişilemez olur.
Üçüncü olarak, max-age değerini merdiven basamağı gibi yükseltin. 5 dakika ile başlayın, sorun görmezseniz 1 güne, sonra 1 haftaya, en sonunda 1 yıla çıkın. Böyle yaptığınızda, herhangi bir aşamada bir sorun fark ederseniz, kısa max-age sayesinde kural kullanıcıların tarayıcılarından hızla silinir. Doğrudan 1 yılla başlarsanız ve bir hata yaparsanız, o hatayı düzeltseniz bile kullanıcıların tarayıcıları 1 yıl boyunca eski kuralı hatırlar.
Son olarak, sadece preload bayrağını başlığa eklemenin sizi otomatik olarak listeye koymadığını unutmayın. Bayrağı eklemek başvuru için ön koşuldur; asıl kayıt hstspreload.org üzerinden yapılır. Bayrağı ekleyip başvuru yapmadan aylarca çalıştırmak tamamen güvenlidir ve bu aşamayı acele etmemek en doğrusudur. SSL ve güvenlik başlıklarını bütünüyle sizin için yapılandırmamızı isterseniz SSL çözümlerimiz ve WAF hizmetimiz ile bu katmanı uçtan uca kurarız.
Yaygın Hatalar ve Dikkat Edilmesi Gerekenler#
Sahada en sık karşılaştığımız hataları ve bunlardan nasıl kaçınacağınızı toparlayalım.
Sertifika süresini kaçırmak. HSTS aktifken sertifikanızın süresi biterse, tarayıcı "güvenli değil ama devam et" seçeneği sunmaz; siteyi tümden reddeder. Normalde bir sertifika hatası irrite edici ama geçilebilirken, HSTS'li sitede tam bir erişim kaybına dönüşür. Bu yüzden Let's Encrypt gibi otomatik yenilenen sertifikalar kullanın ve yenileme işini izleyin. Yedekleme ve izleme süreçlerinizle birlikte sertifika son kullanma tarihini de takip listenize alın.
Başlığı HTTP yanıtında sunmak. HSTS başlığı yalnızca HTTPS üzerinden anlamlıdır. HTTP yanıtına eklerseniz tarayıcı onu yok sayar. Yapılandırmayı HTTPS sunucu bloğuna koyun.
always bayrağını unutmak (Nginx). Nginx'te add_header bayrafsız kullanılırsa, başlık yalnızca belirli durum kodlarında gönderilir ve 4xx/5xx hata sayfalarında düşebilir. always bayrağı başlığın her yanıtta gitmesini garantiler.
Alt alan adı sürprizleri. includeSubDomains eklendikten sonra, ileride açacağınız yeni bir alt alan adı da otomatik olarak HTTPS zorunluluğuna tabi olur. Yani gelecekte HTTP-only bir servis açmayı planlıyorsanız bunu baştan hesaba katın.
Preload'a erken atlamak. En pahalı hata budur. Preload listesine girmek kolay, çıkmak neredeyse imkânsızdır. Sitenizi bir başkasına devretme, alan adını farklı bir altyapıya taşıma veya kısa süreli bakım için HTTP'ye dönme ihtimaliniz varsa, preload adımını atlamadan önce iki kez düşünün. Alan adı ve barındırma tarafını topluca planlıyorsanız alan adı ve hosting paketleri sayfalarımızdan başlayarak sağlam bir temel kurabilirsiniz.
Sıkça Sorulan Sorular#
HSTS SSL sertifikasının yerine geçer mi?#
Hayır, HSTS bir sertifikanın yerine geçmez; onun üzerine kurulur. Önce geçerli bir SSL/TLS sertifikanız ve çalışan bir HTTPS yapılandırmanız olmalı, HSTS ise tarayıcıya "bu siteye artık sadece HTTPS ile bağlan" talimatını veren ek bir katmandır. Sertifika olmadan HSTS'in hiçbir işlevi olmaz; hatta sertifikanız sorunluysa HSTS durumu daha da kötüleştirir çünkü tarayıcı hatayı geçilebilir olmaktan çıkarır.
max-age değerini kaç yapmalıyım?#
Kalıcı yapılandırmada yaygın ve önerilen değer bir yıldır, yani 31536000 saniye. Ancak ilk kurulumda doğrudan bu değere atlamak risklidir. Test aşamasında 5 dakika (300) gibi kısa bir değerle başlayın, birkaç gün sorunsuz çalıştığını gördükten sonra 1 güne, ardından kademeli olarak 1 yıla çıkın. Böylece bir hata yaparsanız kural kullanıcıların tarayıcılarından hızla temizlenir; doğrudan 1 yılla başlayıp hata yaparsanız o hatayı çözseniz bile etkisi aylarca sürer.
HSTS'i açtıktan sonra nasıl geri alabilirim?#
Başlığı sunucudan kaldırmak yeterli değildir çünkü kural zaten tarayıcıların belleğine yazılmıştır ve max-age süresi dolana kadar orada kalır. Kuralı aktif olarak iptal etmek için max-age=0 değerini içeren bir HSTS başlığı göndermeniz gerekir; kullanıcı siteyi HTTPS üzerinden bir kez daha ziyaret ettiğinde tarayıcı kaydı temizler. Preload listesindeyseniz durum daha zordur, çünkü listeden çıkmak haftalar sürer ve gömülü tarayıcı sürümleri güncellenene kadar etkisi devam eder.
includeSubDomains parametresi zorunlu mu?#
Teknik olarak zorunlu değildir, ancak güvenlik açısından güçlü bir korumadır çünkü tüm alt alan adlarınızı da zorunlu HTTPS kapsamına alır. Yalnız burada bir uyarı gerekir: bu parametreyi eklemeden önce www, mail, blog, api gibi kullandığınız her alt alan adının HTTPS sunduğundan emin olmalısınız. HTTPS desteklemeyen bir alt alan adınız varsa, includeSubDomains onu da erişilemez kılar. Ayrıca preload listesine başvuracaksanız bu parametre zorunludur.
HSTS SEO'ya zarar verir mi?#
Doğru kurulduğunda HSTS SEO'ya zarar vermez, aksine olumlu etkisi olabilir. Arama motorları HTTPS'i bir sıralama sinyali olarak değerlendirir ve HSTS, sitenizin güvenlik duruşunu güçlendirir. Dikkat edilmesi gereken tek nokta, HTTP'den HTTPS'e yönlendirmelerin kalıcı (301) olması ve karışık içerik sorunlarının çözülmüş olmasıdır; bunlar zaten HTTPS geçişinin standart gerekleridir. Konuyu bütünsel ele almak isterseniz SEO hizmetimiz teknik altyapı denetimini de kapsar.
HSTS başlığının gerçekten çalıştığını nasıl doğrularım?#
En hızlı yöntem komut satırından curl -sI https://siteadi.com çalıştırıp yanıt başlıkları arasında strict-transport-security satırını aramaktır. Tarayıcı tarafında ise geliştirici araçlarının Network sekmesinde ilgili yanıtın Response Headers bölümünde başlığı görebilir, sonraki isteklerde 307 Internal Redirect girişleriyle tarayıcının HTTP'yi otomatik HTTPS'e çevirdiğini teyit edebilirsiniz. Ayrıca çevrimiçi güvenlik başlığı test araçları da başlığın varlığını ve değerlerini raporlar.
Kapanış#
HSTS, çok küçük bir yapılandırma değişikliğiyle sitenizi SSL stripping ve ilk-istek downgrade saldırılarına karşı sağlamlaştıran, olgun bir güvenlik uygulamasıdır. Tek bir başlık satırıyla, HTTPS'e geçiş kararını sunucunun yönlendirmesine bırakmak yerine tarayıcının kendisine zorunlu kılarsınız. Ancak gücü kadar sorumluluğu da vardır: max-age değerini kademeli yükseltmek, includeSubDomains eklemeden önce tüm alt alan adlarını kontrol etmek ve preload adımını ancak HTTPS altyapınızdan tam emin olduğunuzda atmak, kendi ayağınıza sıkmamanın anahtarıdır.
Bu katmanı sağlam bir zemin üzerine kurmak isterseniz Clou.TR olarak yanınızdayız. Ücretsiz SSL destekli hosting paketlerimiz, yüksek performanslı sanal ve VDS sunucularımız, uçtan uca yönetimli SSL çözümlerimiz ve tüm güvenlik başlıklarını sizin için yapılandıran sunucu yönetimi hizmetimiz ile HTTPS ve HSTS kurulumunu hatasız tamamlamanıza yardımcı oluruz. Sitenizin güvenliğini bir sonraki seviyeye taşımak için ekibimizle iletişime geçmeniz yeterli.